Accesso senza chiavi legato alla prenotazione: cosa deve essere vero prima di fidarsi di una porta
Collegare una serratura smart è il lavoro di un pomeriggio. Fidarsene all'una di notte, con un ospite fuori dalla porta e nessuno alla reception, è un problema diverso — e lo decide il posto in cui vive la decisione di accesso.
La decisione deve vivere dove vivono le prenotazioni
Ogni progetto di accesso senza chiavi inizia con la stessa scorciatoia: creare la credenziale direttamente nella dashboard del produttore della serratura, o via la sua API, e tirare avanti. Funziona finché la prenotazione non cambia.
Una prenotazione viene cancellata, accorciata, spostata di una settimana, trasferita su un'altra stanza. Se la decisione di accesso esiste solo dentro il provider, ognuno di questi casi è una pulizia manuale che qualcuno deve ricordarsi di fare, e l'errore tipico è una credenziale valida per un soggiorno che non esiste più.
Per questo Boris conserva l'intenzione — quale persona può aprire quale porta, da quando a quando — come un proprio record, e tratta il provider come ciò che la fa rispettare. Il provider si può sostituire, può essere giù, possono essere due provider in due edifici. L'intenzione resta della prenotazione.
Una porta non deve mai bloccare una prenotazione
È una piccola scelta architetturale con conseguenze sproporzionate. Se creare l'accesso fa parte del salvataggio della prenotazione, allora un provider con un brutto pomeriggio significa che lo staff non può più accettare prenotazioni.
Il provisioning dell'accesso sta a valle della prenotazione, parte dall'evento e il suo fallimento viene registrato, non propagato. La prenotazione si salva. Il permesso resta in attesa. Qualcuno lo vede.
"In attesa" è la risposta giusta; "fallito" no
Quando il provider non risponde ci sono tre comportamenti possibili e uno solo accettabile.
- Far fallire il permesso. L'ospite arriva davanti a una porta che non si apre, e nel sistema nessuno sta provando a rimediare.
- Dichiararlo riuscito per ottimismo. Peggio: il record dice che l'accesso è stato concesso e nessuno ricontrolla.
- Restare in attesa e ritentare. L'intenzione persiste, un job programmato continua a spingere e lo staff vede i soggiorni il cui accesso non è ancora arrivato.
Ritentare funziona solo se ogni push è idempotente. Spingere due volte lo stesso permesso non deve produrre due credenziali, altrimenti il meccanismo che serve a sopravvivere a un disservizio diventa una perdita lenta di chiavi valide.
Una prenotazione spostata è una revoca più una nuova push
L'istinto è modificare la finestra di validità della credenziale. L'implementazione sicura revoca il vecchio permesso e ne spinge uno nuovo, perché la cosa che non deve mai accadere è che una credenziale valida per la finestra della settimana scorsa sopravviva a questa.
La cancellazione è lo stesso meccanismo senza la seconda metà. Entrambe partono dall'evento della prenotazione: non da una pulizia notturna e sicuramente non da una persona che se ne accorge.
Quando inizia l'accesso è una decisione commerciale, non tecnica
Alcuni gestori vogliono che la porta funzioni appena la prenotazione è confermata. Altri solo dopo il check-in completato, o dopo il pagamento. Sono attività davvero diverse, e la differenza non è qualcosa che il software debba decidere al loro posto.
In Boris il trigger si configura per connessione, e questo rende disponibile anche la versione più delicata sul piano normativo: in una struttura ricettiva può servire che i dati identificativi siano già registrati prima che un ospite apra qualcosa, e legare l'accesso al check-in completato lo rende strutturale invece che una questione di disciplina del personale.
Solo un evento della porta dimostra qualcosa
L'esagerazione più comune nelle integrazioni di accesso è trattare una risposta 200 come una prova. Prova che il provider ha accettato l'istruzione. Non prova che una credenziale sia arrivata a una persona, né che una persona abbia aperto una porta.
Rileggere gli eventi dal provider e associarli alla finestra del permesso è ciò che chiude il cerchio. Trasforma "abbiamo inviato l'accesso" in "la porta si è aperta alle 23:41", che è l'unica versione utile davanti a un reclamo e l'unica che vale la pena mettere in un registro operativo.
Cosa verificare prima di scegliere un provider
Boris si collega a diversi provider di accesso — fra cui Kisi, Salto, Akiles, Tapkey, Brivo, Doordeck e Nuki — e le loro differenze contano più dell'elenco delle funzioni:
- La concessione è idempotente, o un ritentativo crea una seconda credenziale?
- Un permesso può portare una finestra di validità, o solo uno stato acceso/spento da gestire a mano?
- Gli eventi delle porte sono rileggibili dall'API, con orari associabili?
- La revoca ha effetto subito o alla prossima sincronizzazione della serratura — e tu sai quale delle due?
- Cosa accade alla credenziale se la serratura è offline nel momento della revoca?
Per correttezza: queste connessioni in Boris sono marcate beta e funzionano sulle API documentate di ciascun provider, con una modalità di simulazione per configurazione e test. La parte solida è lo strato sotto — il record del permesso, la push idempotente, il ritentativo, la revoca alla cancellazione e la verifica dagli eventi. È quella parte a decidere se una porta è affidabile, ed è quella che non si può comprare da un produttore di serrature.
Domande frequenti
L'accesso deve vivere nel sistema di serrature o in quello di prenotazione?
L'intenzione — chi può aprire quale porta, da quando a quando — appartiene al sistema di prenotazione, perché è lì che nasce e cambia. La serratura la fa rispettare. Se l'intenzione sta solo nel provider, una prenotazione cancellata in Boris lascia in giro una credenziale funzionante e nessun riferimento con cui riconciliarla.
Cosa succede se il provider di accessi non risponde?
Il permesso deve restare in attesa e venire ritentato, non fallire. Una push fallita è una porta che non si aprirà a un ospite che ha già pagato: la cosa giusta è conservare l'intenzione, ritentare in modo programmato e tenere visibile allo staff lo stato in attesa. Ogni push deve inoltre essere idempotente, altrimenti un ritentativo consegna una seconda credenziale.
Cosa deve avvenire se la prenotazione viene cancellata o spostata?
La cancellazione revoca il permesso. Lo spostamento è una revoca più una nuova push, non una modifica: una credenziale valida per la vecchia finestra deve smettere di funzionare prima che inizi la nuova. In Boris entrambe partono dall'evento della prenotazione, non dalla memoria di qualcuno.
Come si sa che un ospite è entrato davvero?
Solo da un evento della porta. Una chiamata API riuscita dimostra che il provider ha accettato l'istruzione, non che una persona ha aperto una porta. Rileggere gli eventi e associarli alla finestra del permesso è ciò che trasforma "abbiamo inviato il codice" in "è entrato alle 23:41".