Hay un chatbot de WhatsApp para restaurantes que llevo meses manteniendo en producción para un restaurante de Madrid con el que trabajo. No es una demo ni un prototipo: atiende a clientes reales, consulta la disponibilidad real del comedor y crea reservas de verdad en el sistema de reservas del restaurante. El dueño paga 49€ al mes por tenerlo funcionando.
Este post es la versión sin marketing: qué hace exactamente, qué costó construirlo, qué se rompió por el camino (varias cosas) y en qué casos NO te recomendaría montar uno. Si estás valorando un bot de reservas por WhatsApp para tu restaurante, esto es lo que me habría gustado leer antes de empezar.
Qué hace el bot, exactamente
En el día a día, el bot cubre cuatro frentes:
- Preguntas frecuentes. Horarios, dirección, si hay terraza, si se puede venir con niños, cómo llegar desde el metro. El 60-70% de los mensajes entrantes son variantes de esto, y el bot los resuelve en segundos, a cualquier hora, también un domingo a las 23:40.
- Reservas de verdad. No un "te llamamos para confirmar": el bot consulta la disponibilidad en tiempo real en el sistema de reservas del restaurante (en este caso, Tableo) y crea la reserva directamente, con nombre, teléfono, personas y hora. El cliente recibe la confirmación en el mismo chat.
- Gestión de la reserva existente. Buscar tu reserva, cancelarla o modificarla — siempre limitado al número de teléfono desde el que escribes. Nadie puede tocar la reserva de otro, y antes de ejecutar cualquier cambio el bot confirma contigo lo que va a hacer.
- Pasar el testigo a una persona. Cuando la conversación se sale del guion — una queja, un grupo de 25 personas, un menú para alérgicos — el bot lo dice claramente, avisa al equipo y se aparta. De esto hablo más abajo, porque fue una de las lecciones caras.
Y una cosa que hace desde el primer mensaje: decir que es un asistente automático. No finge ser un camarero. Aparte de ser lo honesto, en la UE es obligatorio: cualquier sistema de IA que interactúa con personas tiene que revelarlo.
Lo que cuesta de verdad
Los números reales de este proyecto, sin adornos:
| Concepto | Coste |
|---|---|
| Cuota mensual que paga el restaurante | 49€/mes |
| Coste de la API de WhatsApp (Meta) | ~0€/mes a su volumen |
| Coste del modelo de IA | Céntimos al mes |
| Sistema de reservas (Tableo o similar) | Ya lo pagaba antes del bot |
¿Cómo puede ser que la API de WhatsApp salga a ~0€? Porque Meta cobra por conversación iniciada por la empresa con plantilla, pero responder dentro de la ventana de 24 horas desde que el cliente te escribe es gratis. Un bot de atención y reservas vive casi entero dentro de esa ventana. El modelo de IA (uso Gemini Flash) cuesta fracciones de céntimo por mensaje.
Es decir: el coste de funcionamiento es casi cero. Lo que cuesta dinero es construirlo y endurecerlo — semanas de trabajo de desarrollo, integración con el sistema de reservas, pruebas con el dueño, y los arreglos posteriores a cada fallo que apareció en producción. Los 49€/mes cubren mantenimiento, ajustes del comportamiento del bot y que haya alguien (yo) mirando cuando algo se tuerce.
Compáralo con las plataformas SaaS de chatbots, que van de 100€ a 300€+ al mes por planes con funciones que un restaurante no usa. La diferencia es que aquí el sistema es del restaurante, conectado a su sistema de reservas, con su forma de hablar.
Lo que salió mal (y lo que aprendí)
Esta es la parte que ningún proveedor te cuenta. Tres fallos reales de producción:
1. El bot se quedó mudo por una cuota de API. Durante las primeras semanas, la clave del modelo de IA estaba en el nivel gratuito. Un bot de reservas hace entre 3 y 5 llamadas al modelo por cada mensaje del cliente (entender, consultar disponibilidad, redactar), así que un día de pruebas intensas agotó el límite diario... y el bot dejó de responder sin avisar. El dueño escribiendo y el bot en silencio. Lección: un bot en producción necesita facturación de pago en la API del modelo y alertas cuando algo falla. Con el nivel gratuito no hay bot serio.
2. El lunes cerrado que el bot ignoraba. El restaurante cierra los lunes. Un cliente escribió un lunes pidiendo "mesa para hoy" y el bot, en vez de decir que estaba cerrado, empezó a preguntar para cuántas personas. ¿Por qué? Porque los modelos de lenguaje tienen inercia conversacional: si la conversación va de reservar, siguen reservando. La solución no fue "mejorar el prompt" (eso ayuda, pero no garantiza): fue añadir una barrera determinista — código normal y corriente que comprueba el día de la semana antes de dejar que el bot consulte disponibilidad. Si es día de cierre, no hay llamada al sistema de reservas, punto. Regla general: lo que no puede fallar nunca, no se le deja a la IA.
3. El bot que decía "te paso con una persona" sin pasar con nadie. El prompt le decía al bot que escalara a un humano cuando no supiera algo. Y el bot lo decía... pero no ocurría nada, porque decirlo no ejecuta nada. Un cliente se quedó esperando a una persona que nunca llegó. El arreglo: convertir la escalada en una herramienta real que el bot invoca — al llamarla, el sistema notifica al equipo, marca la conversación como "atendida por humano" y el bot se retira de verdad. Otra vez la misma lección: las promesas del bot tienen que estar respaldadas por código.
El humano sigue dentro del sistema
El bot no sustituye al equipo de sala; les quita el ruido. El diseño que funciona:
- El bot resuelve lo repetitivo (horarios, reservas estándar, cambios sencillos).
- Todo lo demás — quejas, grupos grandes, peticiones raras — se escala a una persona, con aviso explícito al cliente de que una persona le va a atender.
- El dueño tiene un panel donde ve todas las conversaciones y puede intervenir en cualquiera, en cualquier momento.
- El comportamiento del bot (tono, horarios, qué días cierra, qué hace con grupos grandes) se edita desde ese panel, sin tocar código. Cambias el texto y el siguiente mensaje ya sale con la nueva regla.
Ese último punto importa más de lo que parece: un restaurante cambia horarios en verano, cierra por vacaciones, ajusta el menú. Si cada cambio requiere un desarrollador, el bot muere de abandono en tres meses.
Cuándo NO montar un chatbot de WhatsApp
Siendo honesto, hay restaurantes a los que les diría que no:
- Si recibes pocos mensajes. Con 5-10 WhatsApps al día, el camarero de turno los contesta en los ratos muertos. La automatización compensa cuando el volumen molesta.
- Si no tienes un sistema de reservas con API. Sin él, el bot solo puede "tomar nota" y alguien tiene que pasar la reserva a mano — pierdes la mitad del valor. Primero el sistema de reservas, después el bot.
- Si nadie va a mantener la información al día. Un bot que da el horario de invierno en agosto hace más daño que no tener bot.
- Si tu número de WhatsApp actual es sagrado y no quieres tocarlo. Conectar un número a la API de Meta tiene implicaciones sobre cómo usas la app de WhatsApp Business en el móvil. Hay caminos para convivir, pero hay que planearlo antes, no descubrirlo después.
Lo que le diría a un dueño de restaurante
El valor de este sistema no es "tener IA". Es que el teléfono deja de sonar sin respuesta, las reservas entran solas también fuera de horario, y tu equipo atiende a los clientes que tiene delante en vez de al móvil. Y el coste de funcionamiento — 49€/mes en este caso real — es menos que una mesa de dos.
Pero solo funciona si se construye con las barreras deterministas, la escalada real a humanos y el mantenimiento que he descrito. Un bot a medio hacer contesta mal, y en hostelería contestar mal sale caro.
Si tienes un restaurante y quieres saber si esto tiene sentido para tu caso concreto — tu volumen de mensajes, tu sistema de reservas, tu equipo — reserva una llamada de 30 minutos conmigo. Sin compromiso: te digo honestamente si te compensa o si todavía no.
Lecturas relacionadas
Preguntas frecuentes
En el caso real que describo en este post, el restaurante paga 49€/mes de cuota de funcionamiento y mantenimiento. Los costes técnicos subyacentes son mínimos: la API de WhatsApp de Meta sale a ~0€ a volumen de restaurante (responder dentro de la ventana de 24 horas es gratis) y el modelo de IA cuesta céntimos al mes. El coste real está en la construcción inicial y la integración con el sistema de reservas, que es un proyecto de semanas.
Sí, si el restaurante usa un sistema de reservas con API (Tableo, CoverManager y similares). El bot consulta la disponibilidad real, crea la reserva con nombre, teléfono y personas, y confirma en el mismo chat. También puede buscar, cancelar o modificar reservas, limitado siempre al número de teléfono del cliente que escribe. Sin un sistema de reservas con API, el bot solo puede tomar nota y pierde la mitad de su valor.
No, y no debería intentarlo. El diseño correcto es que el bot resuelva lo repetitivo (horarios, reservas estándar, cambios sencillos) y escale a una persona todo lo demás: quejas, grupos grandes, peticiones especiales. El equipo ve todas las conversaciones en un panel y puede intervenir en cualquier momento. El bot además debe identificarse como asistente automático desde el primer mensaje — en la UE es obligatorio.
Según mi experiencia en producción: cuotas de API agotadas que dejan al bot mudo sin avisar, la "inercia conversacional" del modelo (seguir reservando un día que el restaurante cierra) y escaladas a humanos que el bot promete pero no ejecuta. Los tres se arreglan igual: con código determinista que respalda al modelo — facturación de pago con alertas, comprobación del día de cierre antes de consultar disponibilidad y una herramienta de escalada real que notifica al equipo.