Cómo automatizar reservas y atención pre-estancia en un hotel

El chatbot acaba de decir que queda una habitación. ¿Lo sabe o lo está suponiendo?

La diferencia parece pequeña hasta que afecta a una reserva real.

Una persona pregunta: «¿Tenéis una doble del 14 al 16 para dos adultos?» El asistente entiende perfectamente la intención. Puede reconocer fechas, ocupación y tipo de consulta.

Pero entender el lenguaje no responde todavía a la pregunta.

Para saber si puede ofrecer algo necesita acceder a la disponibilidad vigente. Para dar precio necesita la tarifa aplicable. Para confirmar necesita comprobar restricciones y ejecutar una operación en el sistema autorizado.

Si el chatbot responde utilizando una tabla antigua, una copia local o una tarifa guardada semanas antes, puede mantener una conversación impecable y una operación incorrecta.

Esta es la diferencia que desarrollamos de forma general en automatización para hoteles. Aquí vamos a profundizar únicamente en el tramo donde la conversación toca inventario, tarifa, reserva y preparación de llegada.

PMS, CRS y motor de reservas: tres conceptos que conviene separar

En hotelería aparecen constantemente estas siglas y es fácil tratarlas como si fueran intercambiables. No lo son.

Un hotel pequeño puede trabajar con una plataforma que concentra varias de estas funciones. Un grupo puede utilizar un CRS central conectado a PMS de distintas propiedades. Otro hotel puede integrar un motor de reservas externo con su PMS y su distribución.

Cloudbeds, por ejemplo, documenta una arquitectura en la que un motor de reservas puede obtener inventario, tarifas, políticas y restricciones desde su PMS o desde su channel manager. SiteMinder, por su parte, documenta intercambios de reservas entre canales, su plataforma y distintos PMS. Son dos ejemplos diferentes de una misma idea: las responsabilidades pueden estar repartidas de formas distintas según el stack del hotel.

Por eso no vamos a afirmar que siempre «manda el PMS» sobre absolutamente todo.

La regla útil es otra: para cada dato y operación debe estar definido qué sistema tiene autoridad. La disponibilidad puede estar gobernada por una capa central de distribución; la estancia y operación de la propiedad, por el PMS; la interfaz de compra, por el motor.

Cuando hablamos de automatizar «sin perder el control del PMS» nos referimos a evitar que chatbot, voz, CRM o una base auxiliar mantengan un estado paralelo que contradiga al sistema operativo real.

El modelo de tres puertas: una forma práctica de saber cuándo puede avanzar la automatización

“Modelo de tres puertas” no es un nombre estándar del sector hotelero. Es el marco que utilizamos en esta guía para ordenar tres decisiones distintas que una automatización debe superar antes de avanzar.

La metáfora es sencilla: cada puerta solo se abre cuando el sistema puede responder con suficiente certeza a una pregunta operativa.

Este modelo evita mezclar tres preguntas que requieren controles distintos.

Un asistente puede superar la primera puerta y ofrecer una habitación, pero no la segunda si el sistema no permite crear reservas desde esa integración. Puede superar las dos primeras y, aun así, fallar la tercera porque las peticiones previas a la llegada quedan en un email que recepción debe revisar manualmente.

El objetivo no es añadir burocracia. Es saber qué evidencia necesita el sistema antes de decir que una acción está realmente completada.

Puerta 1: disponibilidad, tarifa y restricciones

La pregunta «¿tenéis habitación?» parece sencilla, pero combina varias capas.

Disponibilidad no significa que exista físicamente una habitación

Un hotel puede tener una habitación construida y libre físicamente, pero no disponible para vender en unas fechas concretas.

Puede estar fuera de servicio, bloqueada, ya comprometida por inventario, sujeta a límites de venta o afectada por reglas de distribución.

Oracle OPERA Cloud muestra disponibilidad considerando habitaciones vendidas, inventario y situaciones operativas como habitaciones fuera de orden. Cloudbeds también diferencia el número total de unidades físicas de un tipo de habitación de las unidades realmente disponibles y expone disponibilidad, tarifas y restricciones a través de su integración de Booking Engine. La configuración cambia entre plataformas, pero el principio es estable: inventario físico y disponibilidad comercial no son sinónimos.

Tarifa no significa un precio guardado en una tabla

La tarifa puede depender de fechas, tipo de habitación, ocupación, código tarifario, promoción, paquete, segmento y reglas de venta. Cloudbeds documenta, por ejemplo, planes tarifarios con disponibilidad y restricciones diarias que el motor de reservas puede consultar mediante integración.

Un precio que fue correcto por la mañana puede no ser la oferta válida cuando el cliente retoma la conversación horas después.

Si la arquitectura trabaja con precios dinámicos, la automatización debe volver a consultar cuando corresponda, no tratar la primera respuesta como una promesa indefinida.

Y además existen restricciones

Los sistemas hoteleros pueden aplicar restricciones de venta. Por ejemplo, una fecha puede estar cerrada para nuevas llegadas, exigir una estancia mínima o tener otras condiciones.

Esto explica por qué puede existir inventario y, aun así, una combinación concreta de entrada y salida no ser reservable.

De consulta a oferta verificada: qué puede decir el asistente

Una vez consultado el sistema, el asistente puede presentar opciones que realmente existen en ese momento.

La respuesta puede incluir tipo de habitación, tarifa, régimen o paquete cuando aplique, condiciones relevantes y próximos pasos.

Conviene separar dos categorías de información:

Esta separación evita que una base de conocimiento se convierta accidentalmente en una copia obsoleta del sistema de reservas.

También obliga a definir la validez de la oferta. Si no existe una retención real de inventario, el asistente no debería insinuar que la habitación ha quedado bloqueada solo porque se mostró al cliente.

Puerta 2: oferta ≠ reserva confirmada

El huésped elige una de las opciones y dice: «Perfecto, resérvala».

En ese momento el canal tiene intención. Todavía no tiene una reserva.

La automatización debe ejecutar la operación correspondiente en el PMS, CRS o sistema autorizado y esperar el resultado.

Oracle documenta creación, actualización y cancelación de reservas y utiliza identificadores y estados propios para representar la operación. Cloudbeds ofrece igualmente APIs para gestionar reservas y exige a las integraciones de motor de reservas implementar flujos de creación, modificación y cancelación, lo que refuerza la misma regla: el canal necesita una respuesta transaccional del sistema antes de comunicar éxito.

Esta diferencia también protege frente a errores de integración. Si la API tarda, devuelve timeout o responde de forma ambigua, el asistente no debería deducir que todo salió bien.

Y tampoco debería repetir a ciegas la creación: un reintento mal diseñado puede terminar generando dos reservas para la misma intención.

Cambiar una reserva obliga a volver a comprobar lo que el cambio afecta

Un huésped con reserva confirmada pide llegar un día antes. O quiere cambiar de una a dos personas. O solicita otro tipo de habitación.

Modificar los campos no basta.

Ese cambio puede afectar disponibilidad, tarifa, restricciones, depósito, política de cancelación o condiciones de la reserva.

Por tanto, la automatización debería seguir un patrón parecido:

1. Recuperar la reserva correcta.
2. Aplicar el cambio propuesto de forma provisional.
3. Revalidar disponibilidad, tarifa y políticas afectadas.
4. Mostrar al huésped las consecuencias relevantes.
5. Solicitar confirmación cuando proceda.
6. Ejecutar la modificación.
7. Verificar el nuevo estado.

Si el nuevo precio es diferente, no debería descubrirse después de modificar. Si la fecha deja de cumplir una restricción, no debería prometerse antes de validar.

Los casos que requieren override, decisiones comerciales o excepciones relevantes pueden escalarse a una persona.

Cancelar también es una operación: la política debe ser la vigente de esa reserva

«Quiero cancelar» tampoco debería resolverse buscando una política genérica en un documento si la reserva concreta puede tener otras condiciones.

Según tarifa, fecha, depósito, garantía o condiciones, la cancelación puede ser gratuita, tener penalización o exigir revisión.

El flujo puede separar:

1. Identificar la reserva.
2. Consultar la política aplicable.
3. Explicar consecuencias relevantes.
4. Confirmar la voluntad de cancelar cuando sea necesario.
5. Ejecutar la cancelación.
6. Verificar estado y número de cancelación.
7. Detener automatizaciones futuras asociadas a esa estancia.

Lo mismo ocurre con depósitos y garantías. Una reserva puede requerir un importe antes de una fecha determinada o una forma de garantía concreta.

Automatizar no significa convertir el chatbot en un sistema improvisado para almacenar tarjetas. Si el hotel utiliza un enlace de pago seguro o una solución integrada, el asistente puede conducir al huésped hacia ese mecanismo y consultar después el estado correspondiente.

OTA, GDS y canal de origen: no todas las reservas nacen bajo el mismo control

Antes de automatizar cambios conviene saber de dónde procede la reserva.

Qué es una OTA

OTA significa Online Travel Agency, o agencia de viajes online. Son plataformas digitales que comercializan alojamiento y otros servicios de viaje y envían reservas al hotel mediante los sistemas de distribución correspondientes.

Qué es un GDS

GDS significa Global Distribution System, o sistema global de distribución. Es una infraestructura utilizada principalmente por el sector de viajes para consultar y reservar inventario de hoteles, vuelos, coches y otros servicios, históricamente muy vinculada a agencias de viajes y distribución profesional.

Un hotel también puede recibir reservas desde su motor directo, un CRS, un channel manager, teléfono o integraciones propias.

La diferencia importa porque no siempre el sistema local tiene exactamente la misma autoridad sobre una reserva.

SiteMinder documenta reservas procedentes de canales directos, PMS, CRS, GDS, mayoristas y otros sistemas, y conserva información sobre el origen y los identificadores asociados a cada reserva durante el intercambio con el PMS. Oracle documenta igualmente arquitecturas donde un CRS crea una reserva y posteriormente la comunica a OPERA Cloud.

Por eso un asistente no debería aplicar la misma lógica de modificación a cualquier reserva sin considerar su origen y las reglas del canal.

Esta guía no pretende explicar la arquitectura completa de OTA, GDS o channel managers. Solo fijar una regla: antes de cambiar una reserva hay que saber quién controla realmente esa operación.

Chatbot y voz son interfaces: no deberían convertirse en una base paralela de reservas

Un chatbot puede consultar herramientas. Un agente de voz puede identificar la reserva, recuperar opciones, solicitar un cambio o escalar una excepción.

Lo que no debería hacer ninguno es mantener su propia versión definitiva de la reserva.

El historial de conversación es útil para contexto: qué pidió el huésped, qué se explicó, qué dato falta. Pero el estado operativo debe recuperarse del sistema que tenga autoridad.

Si el huésped cambió la reserva en otro canal, el asistente debe ver la versión actual cuando vuelva a hablar con él.

Esto es especialmente importante en voz. La guía de agentes de voz para empresas desarrolla por qué una conversación fiable necesita herramientas, confirmación y transferencia humana, no solo reconocimiento del lenguaje.

Puerta 3: reserva confirmada ≠ llegada preparada

La reserva ya existe. Las fechas están confirmadas y el huésped tiene su número de reserva.

Sin embargo, todavía pueden quedar datos y acciones que condicionan su llegada.

Puede comunicar una hora estimada. Pedir una cuna. Solicitar una habitación accesible. Indicar que celebra un aniversario. Preguntar por transporte. Preferir una planta alta. Completar información antes del viaje.

Si esas interacciones se quedan en la bandeja de entrada, el proceso sigue dependiendo de alguien que las lea, interprete y copie manualmente.

Esto no significa que todas las peticiones puedan garantizarse. Precisamente por eso necesitamos distinguir tipos de información.

Preferencia, nota, solicitud y tarea: cuatro cosas diferentes

Oracle Pre-Arrivals permite revisar antes de la llegada preferencias, notas y traces. En OPERA, un trace es una instrucción o tarea operativa asociada a una reserva y dirigida a un departamento, con información temporal y estado de resolución.

En español conviene no usar el término sin explicar qué significa.

El diseño debería preguntar siempre: ¿esto es un dato, una preferencia, una solicitud confirmable o una acción que alguien debe ejecutar?

Responder «queda anotado» puede ser correcto para una preferencia. Responder «está confirmado» exige más.

Preregistro ≠ check-in completado

El preregistro permite recopilar antes de la llegada información necesaria para agilizar el proceso de recepción.

Según la solución, el huésped puede actualizar datos de contacto, información de la estancia, acompañantes, hora estimada de llegada y otros elementos necesarios.

Mews documenta el check-in online como un proceso previo a la llegada en el que el huésped completa información y formalidades desde su portal; el resultado puede dejar la reserva pre-registrada para que recepción complete después el check-in con menos trabajo. Oracle describe una lógica equivalente de preregistro previo a la llegada.

Eso no significa necesariamente que la estancia haya comenzado ni que la habitación esté ya entregada.

Esta distinción evita mensajes confusos y permite diseñar bien las automatizaciones.

Mews, por ejemplo, permite configurar comunicaciones de check-in online antes de la llegada y solo las envía bajo determinadas condiciones del estado de la reserva. El patrón es útil más allá de una plataforma concreta: la comunicación pre-estancia debe depender del estado real y no de una lista estática de reservas.

Por ejemplo, completar el preregistro puede activar una revisión de datos o una tarea pre-arrival. La llegada real puede depender todavía de disponibilidad de habitación, comprobaciones operativas o pasos presenciales/digitales adicionales.

Eventos de reserva: reaccionar cuando cambia el estado, no revisar una lista estática

Una reserva no permanece inmóvil desde que se crea hasta que llega el huésped.

Puede cambiar de fecha, añadir personas, cancelarse, completar un preregistro o recibir nuevas solicitudes.

Un evento de negocio es simplemente un cambio relevante que puede avisar a otras automatizaciones.

Oracle permite integrar Business Events para comunicar cambios entre sistemas. No hace falta entrar aquí en WebSockets, colas o polling para entender la idea.

El valor está en que la automatización trabaje sobre el estado vigente, no sobre un Excel exportado ayer.

Y si una integración falla

También hay que diseñar los reintentos.

Una llamada que falla temporalmente puede volver a ejecutarse, pero la repetición no debería crear dos reservas, dos cancelaciones o cinco mensajes.

Conservar identificadores, reconocer operaciones ya procesadas y verificar el resultado son controles menos visibles que un chatbot, pero mucho más importantes para llegar a producción.

Permisos y privacidad: preparar la llegada no significa repartir todos los datos por todos los sistemas

La pre-estancia puede acumular datos de contacto, acompañantes, horarios, preferencias, necesidades y pagos.

La AEPD recuerda que la protección de datos por defecto exige limitar cantidad, extensión del tratamiento, conservación y accesibilidad a lo necesario para la finalidad.

Traducido a diseño operativo:

• No pedir datos antes de necesitarlos.
• No replicar toda la reserva en chatbot, CRM, mensajería y herramientas de tareas por comodidad.
• No mostrar información sensible a departamentos que no la necesitan.
• Limitar permisos de integraciones a las operaciones que realmente deben ejecutar.
• Separar contexto conversacional de estado operativo.

La aplicación jurídica concreta depende del tratamiento y de la arquitectura del hotel. Aquí el principio es de diseño: mover menos datos y mantener mejor control.

Ejemplo práctico: una reserva atraviesa las tres puertas

Pensemos en un hotel urbano ficticio de unas cien habitaciones.

Una persona pregunta desde la web por dos noches para dos adultos. El asistente recoge fechas y ocupación y consulta el sistema autorizado.

Primera puerta: recibe dos tipos de habitación vendibles, con tarifas y condiciones vigentes. Presenta ambas opciones sin afirmar que están bloqueadas.

El huésped elige una.

Segunda puerta: la automatización revalida lo necesario, crea la reserva y recibe una confirmación válida. Solo entonces comunica que la reserva está confirmada.

Dos días después, el huésped solicita llegar una noche antes. El sistema recupera la reserva y comprueba cómo afecta el cambio a disponibilidad, precio y política. El huésped acepta la nueva condición y se actualiza la reserva.

Una semana antes de viajar, comunica que llegará a las 23:30 y necesita una cuna.

Tercera puerta: la hora actualiza el dato de llegada. La cuna se procesa como solicitud operativa y, según disponibilidad/proceso, genera la tarea necesaria. El huésped no recibe una confirmación de la cuna hasta que el sistema o el equipo pueda respaldarla.

Si finalmente cancela, la automatización consulta la política vigente, ejecuta la cancelación, obtiene el estado correspondiente y detiene todas las comunicaciones de pre-estancia.

El canal conversó durante todo el recorrido. Pero en ningún momento sustituyó al sistema que mantenía el estado real.

Qué medir para saber si la automatización de reservas funciona

El número de conversaciones atendidas es una métrica insuficiente.

Si el hotel utiliza preregistro, también puede medir invitaciones, procesos iniciados, completados y el efecto sobre el trabajo de llegada.

No hace falta publicar benchmarks universales. El objetivo es comparar la situación con la línea base real del hotel.

Cómo empezar con un piloto

1. Elegir un canal. Por ejemplo, webchat o llamadas de reservas.
2. Delimitar operaciones. Consulta, creación y recuperación antes de añadir cambios complejos.
3. Definir sistemas de referencia. Disponibilidad, tarifa, reserva, pago y tareas.
4. Documentar políticas. Qué puede automatizarse y qué requiere escalado.
5. Diseñar errores y reintentos. Antes de activar escrituras en producción.
6. Separar información general y transaccional.
7. Probar con estados reales. Incluyendo cancelaciones, cambios y reservas de distintos orígenes.
8. Añadir pre-estancia. Cuando la creación/modificación ya sea fiable.
9. Medir el ciclo completo.

Si el PMS, CRS y motor están desincronizados, añadir un chatbot no resolverá el problema. Primero hay que decidir si conviene configurar, integrar o construir una capa alrededor de las herramientas existentes; ese criterio está desarrollado en SaaS, integración o automatización a medida.

El canal puede conversar. El sistema autorizado confirma.

La automatización de reservas funciona cuando respeta esa frontera.

El chatbot o la voz pueden recoger intención, consultar opciones y acompañar al huésped. Las integraciones pueden crear, modificar, cancelar y preparar la llegada. Pero cada paso debe basarse en el estado que realmente controla la operación.

Eso evita dos problemas opuestos: canales muy inteligentes que prometen cosas que el hotel no puede cumplir y sistemas muy fiables que siguen obligando a recepción a copiar manualmente cada conversación.

Las tres puertas sirven precisamente para comprobar dónde está el límite:

¿Se puede ofrecer? ¿Se puede comprometer? ¿Está preparada la llegada?

Si la respuesta está respaldada por datos y una operación verificable, la automatización puede avanzar. Si no, debe pedir información, volver a consultar o escalar.