Automatizar el Check-in de Huéspedes Leyendo el Pasaporte

El registro de un huésped extranjero es de los pocos procesos hoteleros que sigue siendo teclear a mano. El recepcionista toma el pasaporte, transcribe nombre, nacionalidad, número de documento y fechas al sistema, y devuelve el documento. Un par de minutos por huésped, con el cliente esperando de pie.

Es un caso casi ideal para automatizar: el dato de entrada está estandarizado internacionalmente y trae verificación matemática incorporada.

El problema real no es el tiempo

El tiempo importa, pero el problema de fondo es distinto: los errores de transcripción son invisibles.

Un 0 tecleado como O en un número de pasaporte no se nota en el momento. Aparece semanas después, cuando el registro no cuadra con un reporte, o cuando hay que localizar la reserva de un huésped y el número no coincide. Y aparece justo cuando más cuesta corregirlo.

A esto se suma la hora pico: tres autobuses llegando a la vez, cola en recepción, y la transcripción cuidadosa siendo lo primero que se sacrifica.

Qué se obtiene de una foto de la página de datos

{
  "passportNumber": "G12345678",
  "surname": "GOMEZ VELAZQUEZ",
  "givenNames": "MARGARITA",
  "nationality": "MEX",
  "issuingCountry": "MEX",
  "dateOfBirth": "05/07/1980",
  "dateOfExpiry": "05/07/2033",
  "sex": "F",
  "placeOfBirth": "CIUDAD DE MEXICO"
}

Que es, esencialmente, el formulario de registro completo. Y a diferencia de la transcripción manual, el número de pasaporte y las fechas llegan verificados contra los dígitos de la MRZ: si la lectura hubiera fallado, el sistema lo diría en vez de entregar un dato equivocado.

El flujo, de principio a fin

1. Captura. Una tableta o el teléfono de recepción fotografía la página de datos. Ojo con el reflejo sobre la laminación bajo la iluminación cálida y direccional típica de un lobby: es la causa número uno de lecturas fallidas. Luz difusa y sin flash. Los demás casos están en Errores comunes al escanear pasaportes.

2. Extracción. Una llamada a la API devuelve los campos estructurados en un par de segundos.

3. Prellenado, no autoguardado. Los campos aparecen ya llenos en la pantalla de registro, y el recepcionista confirma. Este detalle de diseño es el que decide si el sistema se adopta o se abandona: quien atiende conserva el control y puede corregir antes de guardar. Un sistema que escribe directo en el PMS sin confirmación asusta al personal y termina apagado.

4. Registro en el PMS. Los datos confirmados pasan al sistema de gestión con el resto de la reserva.

5. Excepciones. Cuando la lectura falla —pasaporte muy desgastado, foto imposible— el flujo cae en captura manual, exactamente como hoy. La automatización cubre la gran mayoría de los casos; el resto sigue funcionando como siempre.

Integrar con el PMS

Casi ningún PMS hotelero trae lectura de pasaporte incorporada, pero la mayoría expone alguna vía de entrada de datos. Tres patrones, de más a menos limpio:

API del PMS. Si tu sistema tiene API de reservas y huéspedes, es lo directo: extraes, confirmas, escribes.

Capa intermedia. Una pantalla web sencilla que hace la captura y la extracción, muestra los datos para confirmar y luego escribe al PMS. Es el patrón más habitual porque no depende de modificar el PMS.

Portapapeles asistido. Si el PMS es cerrado, una utilidad que extrae y deja los campos listos para pegar sigue eliminando la transcripción, que es donde estaban los errores. Menos elegante, y aun así resuelve el problema.

El pre-check-in: donde está la ganancia grande

El salto de verdad no es hacer el registro más rápido en el mostrador. Es hacerlo antes de que el huésped llegue.

Se manda un enlace con la confirmación de reserva, el huésped fotografía su pasaporte desde su propio teléfono, y al llegar el registro ya está hecho. La recepción pasa de teclear a entregar la llave.

Para esto conviene tener presentes dos cosas:

• La API key nunca va en el navegador del huésped. La foto se sube a tu servidor y es tu servidor quien llama a la API. Una key en el cliente es una key que cualquiera puede extraer y gastar.
• La instrucción de captura tiene que ser explícita. "Toma la foto de la página con tu foto, incluyendo las dos líneas de código al pie" — con un ejemplo visual. El huésped no sabe qué es una MRZ, pero sabe seguir un recuadro dibujado en pantalla.

Datos personales: guarda menos

Un hotel que digitaliza pasaportes acumula rápidamente una de las bases de datos personales más sensibles de su operación. Dos decisiones reducen mucho el riesgo:

No conserves la imagen una vez extraídos y confirmados los datos, salvo que una obligación específica lo exija. La foto del pasaporte es el activo de mayor riesgo y, ya extraídos los campos, de menor utilidad.

Verifica qué retiene tu proveedor. En nuestro caso, una extracción exitosa no deja almacenados los datos del documento: se procesan, se devuelven y no se conservan. Lo que no se guarda no se puede filtrar.

Qué esperar

Con un flujo de pre-check-in bien montado, el registro en mostrador de un huésped extranjero pasa de un par de minutos de transcripción a una confirmación de pantalla. Y, sobre todo, los números de pasaporte del sistema dejan de tener erratas silenciosas: cada uno llegó verificado contra los dígitos de control de su propia MRZ.

Empieza a probarlo

La demo gratuita lee un pasaporte sin registro — sirve para enseñarle el flujo a tu equipo en dos minutos. Al crear una cuenta tienes 20 extracciones para probar con documentos reales de tu operación, y los precios son por uso, sin mensualidad mínima.

La integración con código está en Cómo integrar una API de OCR de pasaporte.