Voice AI en hospitality: arquitectura de un callbot hotelero
Por qué 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, cómo llegar, precio de parking, horario de piscina, si admiten mascotas. Cada llamada tarda de media 3.5 minutos. En recepción, atender el teléfono compite con atender al huésped que tienes delante, y el huésped que tienes delante siempre gana.
El resultado: llamadas perdidas. Un hotel típico 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 recepción. Actúa como un primer filtro que resuelve el 60-70% de las llamadas sin intervención humana y transfiere el resto a un agente humano con el contexto ya capturado. Esto es lo que construimos y lo que está en producción.
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: telefonía e ingestión de audio
La llamada entra a través 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 crítico: la detección de actividad de voz (VAD). El sistema necesita saber cuándo el usuario está hablando y cuándo ha terminado. Esto parece trivial pero no lo es. Silabs WebRTC VAD funciona para la mayoría de los casos, pero los entornos hoteleros tienen ruido de fondo específico (lobby, música ambiental, conversaciones cercanas) que requirió un threshold de energía ajustado.
El timeout de silencio (cuánto espera el sistema antes de considerar que el usuario ha terminado de hablar) está en 700ms. Menos genera interrupciones constantes. Más genera pausas incómodas. Llegamos a 700ms después 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 después de una evaluación comparativa con 500 muestras de audio de llamadas hoteleras reales, en cuatro idiomas.
| Motor | WER español | WER inglés | WER francés | WER alemán | 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 más 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 más el tiempo de procesamiento más el tiempo de TTS significa que el usuario espera 3-4 segundos antes de recibir respuesta. Eso no funciona en una conversación telefónica.
Deepgram ofrece el mejor equilibrio entre precisión y latencia. Además, soporta streaming (transcribe mientras el usuario habla, en lugar de esperar a que termine), lo que reduce la latencia percibida.
Un problema específico del contexto hotelero: nombres propios. “Tengo una reserva a nombre de Pfeiffer” o “Quiero reservar la suite Alhambra”. Los STT genéricos fallan con nombres propios que no están en su vocabulario. Deepgram permite definir keywords boosting: una lista de términos (nombres de habitaciones, nombres frecuentes de huéspedes) que el modelo prioriza en el reconocimiento. Esto mejoró la precisión en nombres propios un 23%.
Capa 3: comprensión del lenguaje (NLU)
El texto transcrito llega al motor de comprensión. Aquí es donde el sistema decide qué quiere el usuario.
Usamos un approach híbrido. Un clasificador de intención basado en un modelo fine-tuned (DistilBERT para clasificación rápida) detecta la intención principal entre 24 intenciones definidas: reservar, consultar_disponibilidad, check_in, check_out, direcciones, servicios, precios, reclamación, hablar_con_humano, y 15 más.
Para intenciones simples (horarios, direcciones, servicios del hotel), la respuesta se genera directamente desde una base de conocimiento estructurada. No necesita un LLM. “A qué 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 separación es fundamental. El LLM es un motor de conversación, no una fuente de verdad. Los datos los proporciona el sistema de gestión hotelera. El LLM los presenta de forma natural.
Capa 4: integración con PMS
El PMS (Property Management System) es el sistema nervioso del hotel. Nuestro callbot se integra con Opera (Oracle), Mews, y Cloudbeds vía sus APIs respectivas. La integración cubre:
- Consulta de disponibilidad: tipos de habitación, fechas, precios en tiempo real
- Creación de reservas: con número de confirmación que se comunica al huésped por voz y por SMS
- Consulta de reservas existentes: el huésped da su apellido o número de reserva y el sistema recupera los detalles
- Modificaciones: cambio de fechas, upgrade de habitación (con confirmación de precio)
- Información de huésped: nombre, preferencias, historial (para personalizar la atención)
La latencia de la API del PMS es el cuello de botella más frecuente. Opera Cloud tiene tiempos de respuesta de 800ms-2s. Mews es más rápido (200-500ms). Cloudbeds está 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 después 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 razón: naturalidad. Las voces sintéticas de ElevenLabs son las más naturales que hemos evaluado, especialmente en español e inglés.
Cada hotel tiene una voz configurada: género, tono, velocidad. Un hotel boutique en Ibiza tiene una voz diferente que un hotel de negocios en Madrid. Esto parece un detalle estético pero impacta en la percepción del huésped. En nuestras encuestas post-llamada, la naturalidad de la voz es el factor que más correlaciona con la satisfacción general del callbot.
La latencia de TTS es crítica. 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 sílaba.
Capa 6: gestión del diálogo y contexto
El diálogo manager mantiene el estado de la conversación: qué ha dicho el usuario, qué ha respondido el sistema, en qué punto del flujo estamos, y qué información falta por recoger.
Para reservas, el flujo es: fechas -> tipo de habitación -> número de huéspedes -> datos de contacto -> confirmación. El sistema recoge estos datos a lo largo de la conversación 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 habitación que consultó antes, no al parking.
Multilingüe: el reto real
Un hotel en la costa española recibe llamadas en español, inglés, alemán, francés, y ocasionalmente italiano, holandés, o ruso. El sistema detecta el idioma automáticamente 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 tecnológico (los motores soportan múltiples idiomas). El reto es de contenido: cada respuesta tiene que sonar natural en cada idioma. “Le confirmo su reserva” en español no se traduce literalmente al alemán y suene bien. Cada idioma tiene sus expresiones hoteleras propias. Mantener la base de conocimiento actualizada en 4-5 idiomas es un trabajo continuo.
Métricas de producción
Después de 8 meses en producción en 12 hoteles:
| Métrica | Valor |
|---|---|
| Tasa de resolución sin humano | 64% |
| Satisfacción del llamante (encuesta) | 4.1/5 |
| Latencia media de respuesta | 1.8 segundos |
| Llamadas perdidas (reducción) | -78% |
| Reservas completadas por callbot | 23% del total |
| Coste por llamada | 0.12 EUR |
La tasa de resolución 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 qué llama el huésped, qué idioma habla, y qué 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 huésped 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 atención presencial, la resolución de problemas complejos, y la experiencia del huésped que tiene delante. El teléfono lo atiende la máquina. La experiencia la crea el equipo humano.
Para entender cómo el revenue management con IA complementa la estrategia tecnológica del hotel, consulta nuestro artículo sobre revenue management hotelero con IA. Y para una visión más amplia de cómo la IA transforma la atención al cliente, nuestro artículo sobre IA en atención al cliente, más allá del chatbot cubre los patrones de servicio automatizado.
