Check-in online: qué recoge, qué firma y qué devuelve al sistema

Un alojamiento sin recepción de noche funciona si, cuando el huésped llega a la puerta, ya ha pasado todo lo que tenía que pasar. Esta página va de eso: qué es «todo».

La regla: sin registro no hay código

Es la decisión de diseño más importante de un montaje sin recepción, y es la que más resistencia genera cuando la propones.

El código de la cerradura, o la matrícula habilitada en la barrera, no se generan hasta que el registro de viajeros está completo y la reserva pagada.

La objeción siempre es la misma: «¿y si alguien no lo hace y se queda fuera?». La respuesta, en los alojamientos donde lo hemos montado, es que casi nadie se queda fuera, porque el huésped tiene un motivo real para rellenar el formulario. En unos apartamentos de dieciséis unidades, el registro pasó de ser una persecución a completarse solo.

Y trae dos consecuencias que hay que aceptar enteras:

El código no viaja nunca en el correo de confirmación. Sale después, por su canal, cuando se cumplen las dos condiciones. Un correo de confirmación se reenvía y se queda en bandejas de entrada durante años.

Se pide dos veces. Al reservar y otra vez dos o tres días antes, junto al cobro. El segundo aviso es el que recupera a la mayoría.

Qué se recoge

Lo que exige el anexo del Real Decreto 933/2021 para el registro de viajeros, que tratamos en detalle en la guía de registro de viajeros: quince campos por viajero en el ejercicio profesional, de los que el documento solo trae unos cuantos. La dirección de residencia, el teléfono y el correo hay que preguntarlos siempre.

Y lo que no se recoge: copia del documento. La Agencia Española de Protección de Datos publicó en junio de 2025 que pedirla vulnera el principio de minimización. Muchas herramientas traen esa captura activada de fábrica. Se desactiva, y está contado en la guía de la copia del DNI.

Hay un campo más, que no exige ninguna norma y que es de los más útiles si recibes de madrugada: la hora estimada de llegada. Casi ningún motor de reservas lo trae de serie. En un hotel boutique lo dejamos anotado como carencia crítica, porque sin ese dato no puedes avisar a nadie ni saber si la llegada tardía es una excepción o tu normalidad.

Qué firma, y qué no

Tres documentos distintos que se mezclan constantemente:

1. El parte de entrada. Lo exige la norma de registro de viajeros y lo firman los mayores de catorce años. El modelo oficial no se ha publicado, así que hoy se firma en papel o en soporte digital sin que ninguna norma defina los requisitos técnicos de ese soporte.
2. El documento de admisión o de normas de la casa, si tu comunidad autónoma lo pide.
3. El contrato, cuando lo hay.

En un hotel urbano nos encontramos el documento de bienvenida, con las normas y la información de protección de datos, sin firmar por nadie: existía, se entregaba, y nadie había decidido dónde se firmaba. El requisito que fijamos para la herramienta definitiva fue que la firma del documento y el envío del parte fueran un solo flujo, y que valiera también para las altas presenciales y los acompañantes.

La pregunta que casi nadie hace: qué vuelve a tu programa

Aquí está el error que más caro sale, y lo hemos pagado.

Enviar los datos a la Administración y tener los datos en tu propio programa son dos cosas distintas. Hay herramientas de check-in que hacen la primera de maravilla y la segunda no la hacen en absoluto.

En un hotel urbano de treinta y tres habitaciones, al cambiar de sistema, el pre-check-in pasó del uno al ochenta por ciento de las llegadas. Un éxito rotundo. Pero los datos se quedaban en la herramienta de check-in: las facturas salían con los campos en blanco y recepción volvía a teclearlos. El beneficio se lo comía el doble trabajo.

Y no es un caso aislado: Chekin, por ejemplo, documenta abiertamente que con al menos un sistema de reservas no devuelve los datos de los huéspedes, solo el enlace de check-in y los estados.

La pregunta, por escrito y por correo, es esta: «¿Qué campos exactos devolvéis a mi sistema de reservas, y qué campos se quedan solo en vuestra herramienta?».

Si la respuesta tarda o es vaga, ya tienes tu respuesta.

La ventaja silenciosa de que el check-in sea del mismo sistema

No siempre es posible ni siempre es lo mejor, pero conviene saberlo: cuando el check-in es del propio sistema de reservas, el dato no tiene que volver de ninguna parte, porque nunca salió. Cloudbeds y Mews tienen el suyo, y en los dos casos ese problema sencillamente no existe.

La contrapartida es que los check-in independientes suelen ser mejores en la experiencia del huésped y cubrir más autoridades. La decisión honesta depende de dónde te duela más: si facturas mucho y persigues datos, pesa la integración; si lo que te falla es que la gente no completa el registro, pesa la experiencia.

Lo que hacemos nosotros en una implantación

Cuatro cosas, por orden:

1. Atar el acceso al registro y al cobro. Es la condición, y es lo primero.
2. Sacar el código del correo de confirmación y meterlo en su propio mensaje, condicionado.
3. Poner el segundo aviso dos o tres días antes, con el cobro.
4. Pedir por escrito la lista de campos que vuelven al sistema de reservas, y enseñársela al cliente antes de firmar nada.

Ninguna de las cuatro es técnica. Las cuatro son decisiones, y por eso se pueden tomar antes de comprar nada.