Voice AI en hospitality: arquitectura de un callbot hotelero

Por que un callbot hotelero

Un hotel de 150 habitaciones recibe entre 80 y 200 llamadas diarias. De esas, el 60-70% son preguntas repetitivas: horarios de check-in/check-out, disponibilidad, como llegar, precio de parking, horario de piscina, si admiten mascotas. Cada llamada tarda de media 3.5 minutos. En recepcion, atender el telefono compite con atender al huesped que tienes delante, y el huesped que tienes delante siempre gana.

El resultado: llamadas perdidas. Un hotel tipico pierde entre el 15% y el 35% de las llamadas entrantes. Cada llamada perdida de reserva potencial tiene un valor medio estimado de 180-320 EUR (coste medio por noche multiplicado por la estancia media). Las cuentas salen solas.

Un callbot bien implementado no reemplaza a recepcion. Actua como un primer filtro que resuelve el 60-70% de las llamadas sin intervencion humana y transfiere el resto a un agente humano con el contexto ya capturado. Esto es lo que construimos y lo que esta en produccion.

La arquitectura completa

El sistema tiene seis capas, cada una con decisiones de diseño que afectan directamente a la experiencia del usuario.

Capa 1: telefonia e ingestion de audio

La llamada entra a traves de un trunk SIP (usamos Twilio como proveedor principal, con Vonage como backup). El audio se captura en formato PCM 16-bit, 16kHz, mono. Este formato es el sweet spot entre calidad de reconocimiento y ancho de banda.

Un detalle critico: la deteccion de actividad de voz (VAD). El sistema necesita saber cuando el usuario esta hablando y cuando ha terminado. Esto parece trivial pero no lo es. Silabs WebRTC VAD funciona para la mayoria de los casos, pero los entornos hoteleros tienen ruido de fondo especifico (lobby, musica ambiental, conversaciones cercanas) que requirio un threshold de energia ajustado.

El timeout de silencio (cuanto espera el sistema antes de considerar que el usuario ha terminado de hablar) esta en 700ms. Menos genera interrupciones constantes. Mas genera pausas incomodas. Llegamos a 700ms despues de testear con 200 llamadas reales.

Capa 2: Speech-to-Text (STT)

El STT convierte el audio en texto. Usamos Deepgram como motor principal. Lo elegimos sobre Whisper (OpenAI) y Google Speech-to-Text despues de una evaluacion comparativa con 500 muestras de audio de llamadas hoteleras reales, en cuatro idiomas.

Motor	WER espanol	WER ingles	WER frances	WER aleman	Latencia p50
Deepgram Nova-2	6.2%	4.1%	7.8%	8.1%	280ms
Whisper Large V3	5.8%	3.9%	6.9%	7.4%	1.2s
Google V2	7.1%	4.5%	8.3%	8.9%	350ms

Whisper tiene el WER mas bajo (Word Error Rate, porcentaje de palabras mal transcritas), pero su latencia es inaceptable para un callbot en tiempo real. 1.2 segundos de STT mas el tiempo de procesamiento mas el tiempo de TTS significa que el usuario espera 3-4 segundos antes de recibir respuesta. Eso no funciona en una conversacion telefonica.

Deepgram ofrece el mejor equilibrio entre precision y latencia. Ademas, soporta streaming (transcribe mientras el usuario habla, en lugar de esperar a que termine), lo que reduce la latencia percibida.

Un problema especifico del contexto hotelero: nombres propios. “Tengo una reserva a nombre de Pfeiffer” o “Quiero reservar la suite Alhambra”. Los STT genericos fallan con nombres propios que no estan en su vocabulario. Deepgram permite definir keywords boosting: una lista de terminos (nombres de habitaciones, nombres frecuentes de huespedes) que el modelo prioriza en el reconocimiento. Esto mejoro la precision en nombres propios un 23%.

Capa 3: comprension del lenguaje (NLU)

El texto transcrito llega al motor de comprension. Aqui es donde el sistema decide que quiere el usuario.

Usamos un approach hibrido. Un clasificador de intencion basado en un modelo fine-tuned (DistilBERT para clasificacion rapida) detecta la intencion principal entre 24 intenciones definidas: reservar, consultar_disponibilidad, check_in, check_out, direcciones, servicios, precios, reclamacion, hablar_con_humano, y 15 mas.

Para intenciones simples (horarios, direcciones, servicios del hotel), la respuesta se genera directamente desde una base de conocimiento estructurada. No necesita un LLM. “A que hora es el checkout?” se responde con el dato del hotel, formateado en una respuesta natural pre-templated.

Para intenciones complejas (reservas, modificaciones, consultas que requieren razonamiento), el sistema invoca un LLM (Claude 3.5 Haiku por su balance de coste y velocidad) con el contexto del hotel como system prompt. El LLM genera la respuesta conversacional, pero los datos factuales (precios, disponibilidad) siempre vienen de la API del PMS, nunca del LLM.

Esta separacion es fundamental. El LLM es un motor de conversacion, no una fuente de verdad. Los datos los proporciona el sistema de gestion hotelera. El LLM los presenta de forma natural.

Capa 4: integracion con PMS

El PMS (Property Management System) es el sistema nervioso del hotel. Nuestro callbot se integra con Opera (Oracle), Mews, y Cloudbeds via sus APIs respectivas. La integracion cubre:

• Consulta de disponibilidad: tipos de habitacion, fechas, precios en tiempo real
• Creacion de reservas: con numero de confirmacion que se comunica al huesped por voz y por SMS
• Consulta de reservas existentes: el huesped da su apellido o numero de reserva y el sistema recupera los detalles
• Modificaciones: cambio de fechas, upgrade de habitacion (con confirmacion de precio)
• Informacion de huesped: nombre, preferencias, historial (para personalizar la atencion)

La latencia de la API del PMS es el cuello de botella mas frecuente. Opera Cloud tiene tiempos de respuesta de 800ms-2s. Mews es mas rapido (200-500ms). Cloudbeds esta en el medio. Para mitigar la latencia, usamos un cache con TTL de 5 minutos para disponibilidad y precios (que no cambian cada segundo) y llamadas directas para operaciones de escritura.

Cuando el PMS no responde en 3 segundos, el sistema dice “Permítame un momento, estoy consultando la disponibilidad” y reintenta. Si falla despues de dos reintentos, transfiere a un agente humano con el contexto capturado.

Capa 5: Text-to-Speech (TTS)

El TTS convierte la respuesta en audio. Usamos ElevenLabs para las voces principales. La razon: naturalidad. Las voces sinteticas de ElevenLabs son las mas naturales que hemos evaluado, especialmente en espanol e ingles.

Cada hotel tiene una voz configurada: genero, tono, velocidad. Un hotel boutique en Ibiza tiene una voz diferente que un hotel de negocios en Madrid. Esto parece un detalle estetico pero impacta en la percepcion del huesped. En nuestras encuestas post-llamada, la naturalidad de la voz es el factor que mas correlaciona con la satisfaccion general del callbot.

La latencia de TTS es critica. ElevenLabs ofrece streaming de audio: empieza a reproducir la respuesta antes de que el TTS complete toda la frase. Esto reduce la latencia percibida de 1.5 segundos a menos de 500ms para la primera silaba.

Capa 6: gestion del dialogo y contexto

El dialogo manager mantiene el estado de la conversacion: que ha dicho el usuario, que ha respondido el sistema, en que punto del flujo estamos, y que informacion falta por recoger.

Para reservas, el flujo es: fechas -> tipo de habitacion -> numero de huespedes -> datos de contacto -> confirmacion. El sistema recoge estos datos a lo largo de la conversacion de forma natural, no como un formulario. Si el usuario dice “Quiero una doble para el 15 al 17 de marzo, dos personas”, el sistema extrae todos los datos de una sola frase. Si dice solo “Quiero reservar”, el sistema pregunta los datos que faltan uno a uno.

El contexto se mantiene durante toda la llamada. Si el usuario pregunta por disponibilidad, luego por el precio del parking, y luego dice “vale, reservo”, el sistema sabe que se refiere a la habitacion que consulto antes, no al parking.

Multilingue: el reto real

Un hotel en la costa espanola recibe llamadas en espanol, ingles, aleman, frances, y ocasionalmente italiano, holandes, o ruso. El sistema detecta el idioma automaticamente en los primeros 3-5 segundos de habla (Deepgram hace esto nativamente) y conmuta todo el pipeline: STT, NLU, respuestas, TTS.

El reto no es tecnologico (los motores soportan multiples idiomas). El reto es de contenido: cada respuesta tiene que sonar natural en cada idioma. “Le confirmo su reserva” en espanol no se traduce literalmente al aleman y suene bien. Cada idioma tiene sus expresiones hoteleras propias. Mantener la base de conocimiento actualizada en 4-5 idiomas es un trabajo continuo.

Metricas de produccion

Despues de 8 meses en produccion en 12 hoteles:

Metrica	Valor
Tasa de resolucion sin humano	64%
Satisfaccion del llamante (encuesta)	4.1/5
Latencia media de respuesta	1.8 segundos
Llamadas perdidas (reduccion)	-78%
Reservas completadas por callbot	23% del total
Coste por llamada	0.12 EUR

La tasa de resolucion del 64% significa que 6 de cada 10 llamadas se resuelven completamente sin transferir a un humano. El 36% restante se transfiere, pero con contexto (el agente humano sabe por que llama el huesped, que idioma habla, y que datos ya se han recogido).

El coste de 0.12 EUR por llamada compara favorablemente con el coste de un recepcionista atendiendo la misma llamada (estimado en 1.50-2.50 EUR incluyendo coste laboral y coste de oportunidad por dejar de atender al huesped presencial).

Voice AI en hospitality no es un reemplazo de personas. Es una herramienta que permite a las personas concentrarse en lo que realmente importa: la atencion presencial, la resolucion de problemas complejos, y la experiencia del huesped que tiene delante. El telefono lo atiende la maquina. La experiencia la crea el equipo humano.

Para entender como el revenue management con IA complementa la estrategia tecnologica del hotel, consulta nuestro articulo sobre revenue management hotelero con IA. Y para una vision mas amplia de como la IA transforma la atencion al cliente, nuestro articulo sobre IA en atencion al cliente, mas alla del chatbot cubre los patrones de servicio automatizado.