Schlüsselloser Zutritt, der der Buchung folgt: was gelten muss, bevor man einer Tür vertraut
Ein smartes Schloss anzubinden ist die Arbeit eines Nachmittags. Ihm um ein Uhr nachts zu vertrauen, wenn ein Gast draußen steht und niemand am Empfang ist, ist ein anderes Problem — und es entscheidet sich daran, wo die Zutrittsentscheidung lebt.
Die Entscheidung muss dort leben, wo die Buchungen leben
Jedes Projekt für schlüssellosen Zutritt beginnt mit derselben Abkürzung: die Berechtigung direkt im Dashboard des Schlossherstellers oder über dessen API anlegen und weitermachen. Das funktioniert, bis sich die Buchung ändert.
Eine Reservierung wird storniert, verkürzt, um eine Woche verschoben, in ein anderes Zimmer umgebucht. Existiert die Zutrittsentscheidung nur beim Anbieter, ist jeder dieser Fälle eine manuelle Aufräumarbeit, an die jemand denken muss — und der typische Fehler ist eine gültige Berechtigung für einen Aufenthalt, den es nicht mehr gibt.
Deshalb hält Boris die Absicht — welche Person welche Tür von wann bis wann öffnen darf — als eigenen Datensatz und behandelt den Anbieter als das, was sie durchsetzt. Der Anbieter ist austauschbar, kann ausfallen, können zwei Anbieter in zwei Gebäuden sein. Die Absicht bleibt die der Buchung.
Eine Tür darf niemals eine Buchung blockieren
Eine kleine Architekturentscheidung mit überproportionalen Folgen. Ist das Anlegen des Zutritts Teil des Buchungs-Speicherns, dann bedeutet ein Anbieter mit einem schlechten Nachmittag, dass das Team keine Reservierungen mehr annehmen kann.
Die Zutrittsvergabe liegt hinter der Buchung, wird von ihrem Ereignis ausgelöst, und ihr Fehlschlag wird protokolliert statt weitergegeben. Die Reservierung speichert. Die Berechtigung bleibt offen. Jemand sieht sie.
"Offen" ist die richtige Antwort, "fehlgeschlagen" nicht
Ist der Anbieter nicht erreichbar, gibt es drei mögliche Verhaltensweisen und nur eine akzeptable.
- Die Berechtigung scheitern lassen. Der Gast steht vor einer Tür, die nicht aufgeht, und nichts im System versucht, das zu beheben.
- Optimistisch als Erfolg verbuchen. Schlimmer: der Datensatz sagt, der Zutritt sei gewährt, und niemand schaut nochmal hin.
- Offen bleiben und erneut senden. Die Absicht bleibt, ein geplanter Job sendet weiter, und das Team sieht die Aufenthalte, deren Zutritt noch nicht angekommen ist.
Wiederholen funktioniert nur, wenn jeder Push idempotent ist. Dieselbe Berechtigung zweimal zu senden darf keine zwei Credentials erzeugen — sonst wird der Mechanismus gegen Ausfälle zu einem langsamen Leck gültiger Schlüssel.
Eine verschobene Buchung heißt widerrufen und neu senden
Der Reflex ist, das Gültigkeitsfenster der Berechtigung zu bearbeiten. Die sichere Umsetzung widerruft die alte Berechtigung und sendet eine neue, denn was nie passieren darf, ist eine für das Fenster der Vorwoche gültige Berechtigung, die in diese Woche überlebt.
Die Stornierung ist derselbe Mechanismus ohne zweite Hälfte. Beides geht vom Buchungsereignis aus — nicht von einem nächtlichen Aufräumlauf und schon gar nicht davon, dass es jemandem auffällt.
Wann der Zutritt beginnt, ist eine kaufmännische Entscheidung
Manche Betreiber wollen, dass die Tür funktioniert, sobald die Buchung bestätigt ist. Andere erst nach abgeschlossenem Check-in oder nach Zahlung. Das sind wirklich unterschiedliche Geschäfte, und diesen Unterschied sollte Software nicht für sie entscheiden.
In Boris wird der Auslöser pro Verbindung konfiguriert, was auch die meldepflicht-sensible Variante möglich macht: in einer Unterkunft müssen womöglich Identitätsdaten erfasst sein, bevor ein Gast irgendetwas öffnet, und den Zutritt an den abgeschlossenen Check-in zu binden macht das strukturell statt zur Frage der Personaldisziplin.
Nur ein Türereignis beweist etwas
Die häufigste Übertreibung in Zutrittsintegrationen ist, eine 200er-Antwort als Beweis zu nehmen. Sie beweist, dass der Anbieter die Anweisung angenommen hat. Sie beweist nicht, dass eine Berechtigung bei einer Person ankam oder dass jemand eine Tür geöffnet hat.
Ereignisse vom Anbieter zurückzulesen und dem Berechtigungsfenster zuzuordnen schließt den Kreis. Es macht aus "wir haben den Zutritt gesendet" ein "die Tür ging um 23:41 auf" — die einzige Version, die auf eine Beschwerde antwortet, und die einzige, die in ein Betriebsprotokoll gehört.
Was man vor der Anbieterwahl prüft
Boris verbindet sich mit mehreren Zutrittsanbietern — darunter Kisi, Salto, Akiles, Tapkey, Brivo, Doordeck und Nuki — und ihre Unterschiede zählen mehr als ihre Funktionslisten:
- Ist das Gewähren idempotent, oder erzeugt ein Wiederholungsversuch eine zweite Berechtigung?
- Kann eine Berechtigung ein Gültigkeitsfenster tragen, oder nur einen Ein/Aus-Zustand, den man selbst verwaltet?
- Sind Türereignisse über die API zurücklesbar, mit zuordenbaren Zeitstempeln?
- Wirkt ein Widerruf sofort oder erst beim nächsten Sync des Schlosses — und weiß man, welches von beidem?
- Was passiert mit einer Berechtigung, wenn das Schloss beim Widerruf offline ist?
Der Fairness halber: diese Verbindungen sind in Boris als Beta markiert und arbeiten gegen die dokumentierte API des jeweiligen Anbieters, mit einem Simulationsmodus für Einrichtung und Tests. Belastbar ist die Schicht darunter — der Berechtigungsdatensatz, der idempotente Push, der Wiederholungsversuch, der Widerruf bei Storno und die Prüfung über Ereignisse. Diese Schicht entscheidet, ob eine Tür verlässlich ist, und sie ist der Teil, den man bei keinem Schlosshersteller kaufen kann.
Häufige Fragen
Soll der Zutritt im Schließsystem oder im Buchungssystem leben?
Die Absicht — wer welche Tür von wann bis wann öffnen darf — gehört ins Buchungssystem, denn dort entsteht und ändert sie sich. Das Schließsystem setzt sie durch. Liegt die Absicht nur beim Anbieter, hinterlässt eine in Boris stornierte Buchung eine funktionierende Berechtigung in der Welt, mit nichts, woran man sie abgleichen könnte.
Was passiert, wenn der Zutrittsanbieter nicht erreichbar ist?
Die Berechtigung muss offen bleiben und erneut versucht werden, nicht fehlschlagen. Ein fehlgeschlagener Push ist eine Tür, die sich für einen bereits zahlenden Gast nicht öffnet; richtig ist, die Absicht zu behalten, planmäßig erneut zu senden und den offenen Zustand für das Team sichtbar zu halten. Jeder Push muss zudem idempotent sein, sonst erzeugt ein Wiederholungsversuch eine zweite Berechtigung.
Was soll bei Storno oder Verschiebung geschehen?
Ein Storno widerruft die Berechtigung. Eine Verschiebung ist Widerruf plus neuer Push, keine Änderung: eine für das alte Fenster gültige Berechtigung muss aufhören zu funktionieren, bevor das neue beginnt. In Boris löst beides das Buchungsereignis aus, nicht jemandes Gedächtnis.
Woran erkennt man, dass ein Gast wirklich hereinkam?
Nur an einem Türereignis. Ein erfolgreicher API-Aufruf belegt, dass der Anbieter die Anweisung angenommen hat, nicht dass eine Person eine Tür geöffnet hat. Ereignisse zurückzulesen und dem Berechtigungsfenster zuzuordnen macht aus "wir haben den Code geschickt" ein "um 23:41 hereingekommen".