Caso en producción

Una reserva real con folio, dentro de un PMS de terceros

No es un piloto ni una demo con datos de ejemplo: una conversación terminó con una reserva creada en el sistema del hotel y su folio devuelto en el chat.

Actualizado el 8 de septiembre de 2026 · 5 min de lectura

Qué pasó el 20 de agosto de 2026

Ese día una conversación terminó con una reserva creada en el sistema de gestión de un hotel y un folio devuelto dentro del chat. Es la diferencia entre un asistente que promete que alguien te va a contactar y un agente que deja el trabajo hecho.

El agente no vive en una plataforma aparte: está embebido desde el propio backend del PMS. Cuando el huésped pregunta por disponibilidad, la consulta va al motor de reservas y la respuesta que ve es la que el sistema devolvió en ese momento — no una tabla cargada la semana pasada.

3 hoteles

Tres propiedades de la misma operación atendidas desde el mismo agente.

1 agente

Sin duplicar configuración ni conocimiento por propiedad.

0 cruces de datos

La separación entre propiedades es por diseño, no por configuración.

24/7 sin operador

La cotización y la reserva no dependen del horario de recepción.

Qué se conectó

  • Consulta de disponibilidad y tarifa por fecha y tipo de habitación, contra el motor de reservas.
  • Alta de la reserva en el PMS, con los datos del huésped, y devolución del folio real del sistema.
  • Generación del link de pago con la pasarela del propio hotel; la confirmación llega cuando el huésped paga.
  • Consulta posterior del estado de la reserva por folio, para el seguimiento días después.
  • Notificación firmada de cada evento hacia el backend del cliente, con reintentos y registro de fallidos.

Cada una de esas operaciones está registrada como una acción del agente, con sus credenciales guardadas en el servidor —el modelo de IA nunca las ve— y validada en un ambiente de pruebas antes de tocar producción.

Qué aprendimos

El folio es la prueba

Mientras el número no sea el del PMS, el trabajo manual sigue existiendo; sólo cambió de escritorio.

La separación por sede se diseña antes

Resolverla al final, con reglas de prompt, no aguanta la primera conversación ambigua de un huésped.

El «no lo sé» hay que construirlo

Que el agente prefiera escalar antes que inventar una política de cancelación es trabajo de guardrails, no del modelo.

Embeber vale más que integrar

Vivir dentro del backend del sistema hotelero acorta el camino entre la pregunta del huésped y el dato real.

Preguntas frecuentes

Seguir leyendo

Que tu PMS conteste a las 3 de la mañana.

Revisamos qué expone el API de tu sistema y qué operaciones valen la pena convertir en acciones del agente.