Casi ningún parte de viajeros se rechaza por culpa del anfitrión. Se rechaza porque, tres días antes, un huésped escribió mal el nombre de su municipio, eligió el código postal de al lado o dejó a medias un formulario que se le cerró en el aeropuerto. El error nace en el móvil del viajero y aparece semanas después, cuando ya no hay nadie a quien preguntar.
Por eso hemos reconstruido el check-in online de Regi entero: no para que sea más bonito, sino para que el dato llegue bien a la primera. Cada campo que el huésped duda es un parte que vuelve mal, así que el trabajo ha consistido en quitar dudas, validar lo que se puede validar contra datos oficiales y avisar antes de que el error se convierta en un envío fallido a SES.Hospedajes.
Este artículo cuenta qué ha cambiado en el flujo y por qué eso se traduce en un parte limpio. El marco legal del registro está en la guía del registro de viajeros y el RD 933/2021, y la experiencia de llegada en general, en el post sobre la app de check-in.
El error no está en el envío, está en el formulario
Un parte de viajeros es, en el fondo, un puñado de campos que tienen que ser exactos. El envío a SES.Hospedajes es la parte fácil: lo hace el sistema solo. Lo difícil es que esos campos lleguen correctos desde el móvil de alguien que está haciendo la maleta. Y cuando un dato entra mal, el coste no es un aviso rojo en pantalla: es un parte que hay que corregir o anular y rehacer, a veces con la estancia ya empezada. Los mensajes de rechazo más comunes y cómo se arreglan están en errores de SES.Hospedajes.
Con esa idea hemos tocado tres cosas: que el huésped pueda terminar el formulario aunque se interrumpa, que no tenga que adivinar nada que podamos saber nosotros, y que se le avise en el momento en el que se equivoca, no después.
Borradores que se guardan solos y se retoman donde los dejaste
El check-in ya no es un formulario de una sentada. Se guarda paso a paso y cada borrador tiene su propio enlace, /d/{token}, que el huésped puede abrir más tarde o en otro dispositivo y encontrar tal y como lo dejó.
El detalle que más cambia en la práctica es la caducidad: el borrador vive ligado a la estancia, no a la sesión de edición. Antes, cerrar la pestaña o quedarse sin cobertura significaba empezar de cero, que es justo el momento en el que un huésped con prisa rellena de cualquier manera para acabar cuanto antes. Ahora puede empezar en el avión, dejarlo a medias y terminarlo en el alojamiento sin perder nada. Menos formularios abandonados significa menos check-ins hechos a última hora en la puerta, que es donde se concentran los errores de transcripción.
Varias personas rellenando a la vez, sin pisarse
Una reserva de cuatro adultos son cuatro personas escribiendo a la vez si les mandas un enlace. Antes eso era un problema: dos huéspedes en la misma plaza podían sobrescribirse y quedarse con datos mezclados.
Ahora cada plaza de viajero tiene un bloqueo de edición blando y expirable. Mientras alguien está rellenando una plaza, el resto ve que está ocupada; y como el bloqueo expira solo, nadie se queda con una plaza atascada porque a otro se le acabó la batería. Es una salvaguarda, no una barrera.
Además, la pantalla se actualiza en vivo. Antes preguntábamos al servidor cada tres segundos; ahora los cambios llegan solos, y en un grupo grande ver quién ha terminado ya evita la ronda de mensajes de “¿lo has hecho?”.
Código postal y municipio: donde de verdad se decide si el parte entra
Este es el cambio menos vistoso y el que más partes salva. El domicilio del viajero no viaja al parte como texto libre: lo que viaja es un código de municipio. Si ese código está mal, el parte no es “un poco impreciso”, es un envío rechazado. Y un huésped extranjero (o español, seamos honestos) no tiene por qué saber si su pueblo es municipio propio o pedanía de otro.
Por eso el check-in incorpora una validación exhaustiva de código postal y municipio en España, con datos derivados del dataset público del INE:
- Selección por código postal primero. El huésped escribe los cinco dígitos, que es el dato que conoce de memoria, y desde ahí se ofrecen los municipios que le corresponden. No al revés.
- Autorrelleno cuando no hay ambigüedad. Si un municipio tiene un único código postal, se rellena solo. Un campo menos que tocar es un campo menos que equivocar.
- Nada de combinaciones imposibles. Las parejas código postal + municipio que no existen no se pueden elegir, así que no llegan al parte.
El resultado no es cosmético: el municipio que se envía es un código real, no una aproximación escrita a mano.
Campos que se rellenan sin pensar
El resto del formulario ha recibido el mismo tratamiento: quitar fricción en los sitios donde la fricción produce errores.
- Búsqueda difusa multilingüe de países y municipios: un huésped alemán escribe “Spanien” y un francés “Espagne”, y una tilde de más o de menos no bloquea a nadie.
- Bandera del país seleccionado, para ver de un vistazo que es el que se quería (Austria y Australia se confunden más de lo que parece en una lista larga).
- Selección de sexo en un toque, sin desplegables.
- Teclado móvil adaptado a cada campo: numérico para el documento y el código postal, el adecuado para el correo. Es la diferencia entre teclear un código postal en dos segundos o en diez con dos erratas.
Todo esto va acompañado de trabajo de accesibilidad y de rendimiento en la primera carga: el check-in lo abre gente con conexiones malas, en itinerancia y con lectores de pantalla.
Avisos antes de que el error llegue al parte
Validar campos sueltos no basta; hay errores que solo se ven mirando la reserva entera. El flujo ahora avisa en tres situaciones concretas:
- Conflicto de fechas, tanto al crear el check-in como al editar las fechas después. Si esas fechas chocan con otra estancia registrada en el mismo alojamiento, se avisa antes de seguir, no cuando el parte ya está emitido.
- Estancia inusualmente larga. No se bloquea (hay estancias largas legítimas), pero se pregunta: la mayoría de las veces es un año mal tecleado en la fecha de salida.
- Grupo compuesto solo por menores. En vez de dejar que se envíe un check-in sin ningún adulto, el flujo guía para añadir a un adulto responsable.
También hemos quitado preguntas que solo servían para generar respuestas inventadas:
- El método de pago solo se pide después de preguntar si la plataforma ya cobró. Si Airbnb o Booking ya cobraron la estancia, preguntarle al huésped cómo pagó es invitarle a elegir cualquier opción al azar.
- No se envía número de soporte para documentos que no son NIF ni NIE. Un pasaporte no tiene número de soporte, así que ni se pide ni se manda un valor de relleno que luego ensucia el parte.
El cierre: sello de confirmación y justificante en PDF
El check-in termina con una pantalla de confirmación con sello y un justificante descargable en PDF: el huésped sabe que ha terminado de verdad y tiene algo tangible que enseñar cuando alguien del grupo pregunta si “eso del registro” ya está hecho.
El check-in está disponible en siete idiomas: español, inglés, alemán, francés, neerlandés, checo y polaco. Un formulario legal en un idioma que no dominas es una fábrica de errores; en el idioma del viajero, es un trámite de dos minutos.
Cómo llega ese formulario al huésped (enlace corto, código QR y guía por canal) lo contamos en el post sobre el enlace de check-in y el código QR, y qué hacemos con los datos una vez enviados (se conservan tres años y se borran solos) lo explicamos en el post sobre la protección de datos de huéspedes.
Del lado del anfitrión: partes más limpios y más manejables
Un formulario mejor solo se nota si el otro extremo acompaña. La pantalla de partes también ha cambiado:
- Descarga del parte de viajeros en PDF desde la tabla de partes, para archivar o enseñar sin capturas de pantalla.
- Enviar y reintentar un parte desde la interfaz, sin depender de un reintento automático que no ves.
- Los partes anulados ya no disparan el aviso de conflicto de fechas: ahora el aviso solo salta cuando hay un conflicto real.
- El código de municipio se valida como código INE real también en el parte, así que la validación del formulario y la del envío dicen lo mismo.
- Fechas de estancia compactas en la tabla, para leer una lista larga sin ir campo por campo.
El detalle de qué se puede corregir y qué implica rehacer un envío está en el post sobre cómo anular partes; el contexto general del trámite, en la guía del registro de viajeros.
Preguntas frecuentes
¿Qué pasa si un huésped deja el check-in a medias?
No se pierde: el borrador se guarda paso a paso y tiene su propio enlace /d/{token} para retomarlo donde lo dejó, incluso desde otro dispositivo. La caducidad está ligada a la estancia, no a la sesión de edición.
¿Pueden varios huéspedes rellenar sus datos al mismo tiempo? Sí. Cada plaza de viajero tiene un bloqueo de edición blando y expirable, de forma que dos personas no se sobrescriben. Los cambios se ven en vivo, sin recargar la página.
¿Por qué importa tanto el código postal y el municipio? Porque el parte no lleva el nombre del pueblo escrito a mano: lleva un código de municipio, y si no es correcto el envío se rechaza. Por eso la selección va por código postal primero y se valida contra datos derivados del dataset público del INE.
¿En qué idiomas puede hacer el check-in un huésped extranjero? En siete: español, inglés, alemán, francés, neerlandés, checo y polaco.
¿Puedo descargar el parte de viajeros? Sí, en PDF desde la tabla de partes. Además puedes enviar o reintentar el envío de un parte desde la propia interfaz.