Acceso sin llaves ligado a la reserva: qué tiene que cumplirse antes de fiarse de una puerta
Conectar una cerradura inteligente es el trabajo de una tarde. Fiarse de ella a la una de la mañana, con un huésped en la puerta y nadie en recepción, es otro problema — y lo decide dónde vive la decisión de acceso.
La decisión tiene que vivir donde viven las reservas
Todo proyecto de acceso sin llaves empieza con el mismo atajo: crear la credencial directamente en el panel del fabricante de la cerradura, o por su API, y seguir adelante. Funciona hasta que la reserva cambia.
Una reserva se cancela, se acorta, se mueve una semana, se pasa a otra habitación. Si la decisión de acceso solo existe dentro del proveedor, cada uno de esos casos es una limpieza manual que alguien tiene que recordar, y el fallo típico es una credencial válida para una estancia que ya no existe.
Por eso Boris guarda la intención — qué persona puede abrir qué puerta, desde cuándo y hasta cuándo — como un registro propio, y trata al proveedor como lo que la hace cumplir. El proveedor se puede sustituir, puede estar caído, pueden ser dos proveedores en dos edificios. La intención sigue siendo de la reserva.
Una puerta nunca debe bloquear una reserva
Es una decisión de arquitectura pequeña con consecuencias desproporcionadas. Si crear el acceso forma parte de guardar la reserva, un proveedor con una mala tarde significa que tu personal no puede aceptar reservas.
El aprovisionamiento del acceso va después de la reserva, lo dispara su evento, y su fallo se registra en lugar de propagarse. La reserva se guarda. El permiso queda pendiente. Alguien lo ve.
"Pendiente" es la respuesta correcta; "fallido" no
Cuando el proveedor no responde hay tres comportamientos posibles y solo uno aceptable.
- Hacer fallar el permiso. El huésped llega a una puerta que no se abre, y nada en el sistema está intentando arreglarlo.
- Darlo por bueno. Peor: el registro dice que el acceso se concedió y nadie vuelve a mirar.
- Quedarse pendiente y reintentar. La intención persiste, un proceso programado sigue enviándola y el personal ve las estancias cuyo acceso aún no ha llegado.
Reintentar solo funciona si cada envío es idempotente. Enviar dos veces el mismo permiso no debe producir dos credenciales; si no, el mecanismo que sirve para sobrevivir a una caída se convierte en una fuga lenta de llaves válidas.
Mover una reserva es revocar y volver a enviar
El instinto es editar la ventana de validez de la credencial. La implementación segura revoca el permiso anterior y envía uno nuevo, porque lo que nunca puede pasar es que una credencial válida para la ventana de la semana pasada sobreviva a esta.
La cancelación es el mismo mecanismo sin la segunda mitad. Las dos salen del evento de la reserva: no de una limpieza nocturna y desde luego no de que una persona se dé cuenta.
Cuándo empieza el acceso es una decisión comercial, no técnica
Hay gestores que quieren que la puerta funcione en cuanto la reserva está confirmada. Otros, solo después del check-in completo, o del pago. Son negocios realmente distintos, y esa diferencia no es algo que el software deba decidir por ellos.
En Boris el disparador se configura por conexión, lo que además hace posible la versión sensible en cumplimiento: en un alojamiento puede hacer falta que los datos de identidad estén registrados antes de que un huésped abra nada, y atar el acceso al check-in completado convierte eso en algo estructural y no en una cuestión de disciplina del personal.
Solo un evento de la puerta demuestra algo
La exageración más común en las integraciones de acceso es tratar un 200 como una prueba. Prueba que el proveedor aceptó la instrucción. No prueba que una credencial llegara a una persona, ni que una persona abriera una puerta.
Releer los eventos del proveedor y cruzarlos con la ventana del permiso es lo que cierra el círculo. Convierte "enviamos el acceso" en "la puerta se abrió a las 23:41", que es la única versión que responde a una reclamación y la única que merece estar en un registro operativo.
Qué comprobar antes de elegir proveedor
Boris se conecta con varios proveedores de acceso — entre ellos Kisi, Salto, Akiles, Tapkey, Brivo, Doordeck y Nuki — y sus diferencias importan más que su lista de funciones:
- ¿La concesión es idempotente, o un reintento crea una segunda credencial?
- ¿Un permiso puede llevar una ventana de validez, o solo un estado encendido/apagado que gestionas tú?
- ¿Los eventos de las puertas se pueden releer por API, con horas cruzables?
- ¿La revocación tiene efecto inmediato o en la siguiente sincronización de la cerradura — y sabes cuál de las dos?
- ¿Qué le pasa a la credencial si la cerradura está sin conexión cuando revocas?
Por honestidad: en Boris estas conexiones están marcadas como beta y funcionan contra la API documentada de cada proveedor, con un modo de simulación para configuración y pruebas. La parte sólida es la capa de debajo — el registro del permiso, el envío idempotente, el reintento, la revocación al cancelar y la verificación desde los eventos. Es esa capa la que decide si una puerta es de fiar, y es la que no se le puede comprar a un fabricante de cerraduras.
Preguntas frecuentes
¿El acceso debe vivir en el sistema de cerraduras o en el de reservas?
La intención — quién puede abrir qué puerta y entre qué fechas — pertenece al sistema de reservas, porque es donde nace y donde cambia. La cerradura la hace cumplir. Si la intención solo está en el proveedor, una reserva cancelada en Boris deja por ahí una credencial que funciona y nada con lo que reconciliarla.
¿Qué pasa si el proveedor de accesos no responde?
El permiso debe quedarse pendiente y reintentarse, no fallar. Un envío fallido es una puerta que no se va a abrir para alguien que ya pagó, así que lo correcto es conservar la intención, reintentar de forma programada y dejar el estado pendiente visible para el personal. Además, cada envío tiene que ser idempotente, o un reintento entrega una segunda credencial.
¿Qué debe ocurrir si la reserva se cancela o se mueve?
La cancelación revoca el permiso. Mover la reserva es una revocación más un nuevo envío, no una edición: una credencial válida para la ventana antigua tiene que dejar de funcionar antes de que empiece la nueva. En Boris las dos salen del evento de la reserva, no de que alguien se acuerde.
¿Cómo se sabe que un huésped entró de verdad?
Solo por un evento de la puerta. Una llamada a la API con éxito demuestra que el proveedor aceptó la instrucción, no que una persona abriera una puerta. Releer los eventos y cruzarlos con la ventana del permiso es lo que convierte "enviamos el código" en "entró a las 23:41".