Uno de nuestros clientes del sector hostelero —un hotel boutique de unas 50 habitaciones en zona turística alpina europea— llegó a MindRise con un problema que se nota poco pero que pesa mucho en el día a día: el personal de recepción dedicaba unas 2-3 horas diarias a contestar las mismas consultas una y otra vez. Horarios del spa, recomendaciones de restaurantes, cómo llegar al telesilla más cercano, qué hay de meteorología para los próximos días, cómo reservar mesa en el restaurante del hotel. Multiplicado por cuatro idiomas —español, inglés, francés y catalán— y por una temporada alta de cinco meses al año.
El cálculo neto, hecho con el director del hotel, salía a unas 42 horas al mes de tiempo real de personal cualificado dedicado a tareas repetitivas. Tiempo que no podía destinarse a check-ins, a atención presencial, a problemas reales de los huéspedes ni a coordinar equipos. La dirección lo había identificado como un punto claro de mejora pero no sabía por dónde empezar.
Este artículo explica el caso paso a paso: qué encontramos en el diagnóstico, por qué la solución obvia (un chatbot) no era suficiente, cómo diseñamos la solución que finalmente se implantó y qué resultados medimos a los tres meses de estar en producción.
El problema en concreto
Cuando analizamos un caso, siempre empezamos pidiendo una muestra del flujo real de una semana. En este hotel, la muestra incluía:
- 87 consultas por WhatsApp en una semana, en cuatro idiomas distintos
- 34 consultas en recepción presencial sobre temas que podían resolverse por mensaje
- 12 llamadas telefónicas de la misma naturaleza
- Una distribución del tiempo media de 8-12 minutos por consulta (incluyendo búsqueda de información, redacción de la respuesta, posible seguimiento)
El patrón era predecible: el 70% de las consultas se repetía semana tras semana. Recomendaciones de restaurantes a 10 minutos a pie. Horario del telesilla más cercano. Si el spa estaba abierto los domingos. Si había que reservar la cena en el restaurante del hotel. Qué previsión había de nieve para los próximos tres días.
Este perfil de consultas tiene dos características: son fácilmente automatizables (respuesta con información estructurada) y, al mismo tiempo, requieren contexto actualizado (meteorología de hoy, eventos locales de este fin de semana, horarios que cambian por temporada). No es el típico FAQ estático. Necesitábamos una solución que combinase base de conocimiento propia con acceso a datos en tiempo real.
Por qué un chatbot estándar no servía
Aquí entra una distinción que siempre intentamos explicar a los clientes antes de proponer nada. Un chatbot tradicional —del tipo que se despliega en una plataforma estándar con tres prompts— habría resuelto el 30-40% de las consultas. Habría sido capaz de responder horarios fijos y preguntas estáticas. Pero habría fallado en el 60% restante: las consultas que requieren acceso a sistemas externos (meteorología, eventos, disponibilidad), las que necesitan redacción multidioma fluida, y las que tienen que derivar a una persona cuando la cosa se complica.
La otra opción extrema —construir un agente complejo con arquitectura de planificación— habría sido sobreingeniería para este caso. No hacía falta que el sistema "razonase" sobre secuencias largas de acciones. Hacía falta que respondiese bien, en cuatro idiomas, con contexto fresco, y que supiese cuándo derivar a recepción.
La conclusión tras el diagnóstico fue clara: necesitábamos una arquitectura intermedia. Un sistema con capacidades de agente para hacer consultas externas en tiempo real, pero con un diseño más simple que un agente generalista. Lo que técnicamente llamamos un sistema híbrido, pero que al cliente le explicamos como "un asistente que sabe lo que sabe de tu hotel, busca lo que no sabe cuando lo necesita, y sabe cuándo callar y avisar a tu equipo".
La solución que diseñamos
La arquitectura final combinó siete componentes clave, cada uno con una función específica:
WhatsApp Business API como canal principal. Es donde los huéspedes ya escriben, así que no había que educarlos en una nueva interfaz. Se conectó mediante la API oficial de Meta, no a través de terceros, porque queríamos control completo sobre el flujo de datos y cumpliendo con requisitos de privacidad del hotel.
Kapso como capa de orquestación de la conversación. Se encarga de mantener el contexto de una conversación a lo largo del tiempo (un mismo huésped puede escribir el miércoles por la noche y continuar la conversación el jueves por la mañana), gestionar el flujo de turnos, y decidir cuándo derivar a un humano.
n8n self-hosted como motor de integraciones. Aquí es donde pasan todas las cosas: conexión con la base de conocimiento del hotel, consultas a servicios externos, lectura y escritura en Google Sheets para registro operativo, gestión de fallbacks. Self-hosted porque los datos de los huéspedes nunca salen de la infraestructura del cliente.
GPT-4.1-mini como modelo principal de generación. Era la mejor relación calidad-coste-velocidad para el caso. Modelos más potentes ofrecían marginalmente mejor respuesta a un coste muy superior; modelos más pequeños no mantenían la calidad multilingüe que requeríamos.
Perplexity como fuente de información actualizada en tiempo real. Cuando un huésped pregunta por la previsión meteorológica, los eventos de este fin de semana o el precio de los forfaits hoy, Perplexity responde con información al día, no con datos obsoletos del training del modelo.
Redis para la gestión de sesiones y memoria a corto plazo de cada conversación.
PostgreSQL para el registro persistente de todas las interacciones, sin incluir datos personales identificables. Imprescindible para auditoría, mejora continua y compliance.
Todo el sistema opera en cuatro idiomas con detección automática del primer mensaje. Si un huésped empieza en francés, toda la conversación sigue en francés salvo que cambie explícitamente. La detección fue uno de los puntos más delicados: los primeros mensajes cortos ("Hola") son ambiguos entre catalán y castellano, así que tuvimos que afinar el sistema con reglas de fallback inteligente.
Resultados medibles a los 3 meses
Tres meses después de la puesta en producción, hicimos la medición objetiva con el director del hotel. Los resultados:
Reducción de carga de personal: 42 horas/mes liberadas del personal de recepción en consultas repetitivas. Equivalente a unas 1,4 horas de personal cualificado por día.
Cobertura de consultas: el 73% de las consultas entrantes se resuelven completamente por el sistema sin intervención humana. El 27% restante se deriva a recepción con contexto completo, no como "mensaje nuevo": el equipo sabe qué se ha pedido, qué se ha respondido ya y por qué se está derivando.
Tiempo de respuesta: 4-8 segundos de media para el 73% automatizado. Antes, los mensajes fuera de horario podían quedar sin respuesta durante 2-6 horas. Ahora la primera respuesta es inmediata 24/7.
Multidioma efectivo: 4 idiomas en producción con detección automática. La distribución real fue un 38% castellano, 27% francés, 21% inglés, 14% catalán. Sin el sistema, el hotel solo garantizaba atención fluida en dos idiomas en recepción en horas diurnas.
Coste operativo: aproximadamente 80€/mes de costes de IA (modelos + Perplexity + infraestructura compartida). Comparado con el coste de personal liberado, el retorno de inversión fue positivo desde el primer mes.
Estos no son números teóricos: están medidos con datos reales durante tres meses de producción.
Qué aprendimos
Tres lecciones clave de este proyecto que aplicamos ahora a casos similares:
1. La detección de idioma vale la pena trabajarla bien. Los primeros mensajes son cortos y ambiguos. Tuvimos un bug inicial en el que el sistema caía por defecto a un idioma equivocado cuando la sesión de Redis aún no se había creado. Fue un día de debug, pero una vez arreglado, la fiabilidad del sistema multilingüe saltó significativamente.
2. La integración con el personal humano es tan importante como la automatización. El 27% de consultas que se derivan no son "fracasos" del sistema. Son exactamente lo que queríamos: el sistema sabe cuándo no está a la altura y lo pasa a humanos con contexto. Este diseño —el "saber callarse"— fue una de las decisiones de producto más importantes, no una concesión.
3. El modelo más caro no siempre es el mejor. Hicimos evaluaciones con GPT-4o, Claude Sonnet y GPT-4.1-mini. La diferencia de calidad percibida por los huéspedes fue mínima; la diferencia de coste era 3-5x. Para este caso concreto, mini era la decisión correcta. Para un caso de banca o legal, probablemente habría sido al revés.
Conclusión
Este proyecto es un caso relativamente típico de lo que hacemos en MindRise: un problema operativo real, un diseño acotado a la complejidad necesaria, una arquitectura agnóstica de cualquier herramienta concreta y resultados medibles. No es un piloto que nunca sale de pruebas; es un sistema en producción que sigue funcionando cada día.
Si tienes un caso similar —tareas operativas repetitivas, multidioma, integración con sistemas externos—, escríbenos. Te daremos una valoración honesta antes de plantear nada. A veces el caso justifica un sistema como este. Otras veces una solución más simple ya resuelve el problema. La diferencia entre las dos respuestas la sabemos después de mirar los datos reales, no antes.