title: "Cómo montamos un bot de WhatsApp para reservas de restaurante (y por qué dejamos de usar formularios)" slug: chatbot-whatsapp-reservas-restaurante excerpt: "Un restaurante con formulario web que nadie usaba, un teléfono que sonaba sin parar y un equipo de sala desbordado. Así fue el proceso de montar un bot de reservas por WhatsApp que terminó gestionando el 62% de las reservas." category: casos-de-uso tags: [whatsapp, restaurante, reservas, n8n, chatbot, google-sheets] author: Flexum date: 2026-06-08

Cómo montamos un bot de WhatsApp para reservas de restaurante (y por qué dejamos de usar formularios)

El restaurante tenía un formulario de reservas en la web. Lo habían pagado, lo habían integrado con su sistema de gestión y lo habían puesto bien visible en la página de inicio. El problema es que casi nadie lo usaba.

Los datos del CMS mostraban que la mayoría de las personas que llegaban a la página de reservas rebotaban. Las que completaban el formulario eran una minoría. El resto llamaba por teléfono. El teléfono del restaurante sonaba constantemente durante el servicio, la persona de sala tenía que interrumpir lo que estaba haciendo para coger reservas, y los errores (fecha mal apuntada, número de comensales confuso) eran frecuentes.

El motivo es sencillo: la gente ya no quiere rellenar formularios web. Quiere escribir por WhatsApp. Así que dejamos de intentar convencerles de lo contrario y construimos el bot donde ellos ya estaban.

La arquitectura del sistema

El stack que usamos:

• WhatsApp Business API vía Meta Cloud API directa (con número dedicado)
• n8n como motor de automatización y lógica conversacional
• Google Sheets como base de datos ligera (configuración, sesiones, reservas)
• Google Calendar para bloquear huecos y gestionar disponibilidad real
• Signaturit (opcional): para enviar confirmación con firma digital en reservas de grupos grandes (más de 12 personas) con anticipo

No usamos un CRM complejo ni una base de datos SQL porque el restaurante no tiene personal técnico interno. Google Sheets les permite ver, editar y añadir reservas desde el móvil sin necesidad de entrar a ningún sistema.

El flujo conversacional como máquina de estados

La clave para que un bot de WhatsApp funcione en la práctica es tratarlo como una máquina de estados: el bot sabe exactamente en qué punto del proceso está cada usuario y qué tiene que preguntar a continuación.

Diseñamos 7 estados para este bot:

Estado 0 - Inicio: El usuario escribe cualquier cosa o "reserva". El bot saluda, presenta el restaurante brevemente y pregunta la fecha.

Estado 1 - Fecha: El bot pide la fecha. El usuario puede responder "el viernes", "mañana", "20 de junio" o "para el sábado que viene". El bot parsea la fecha y confirma en formato claro ("¿El viernes 21 de junio?").

Estado 2 - Hora: Confirmada la fecha, el bot pregunta la hora. Comprueba si esa hora está dentro del horario de servicio y si hay disponibilidad. Si no hay hueco, ofrece alternativas.

Estado 3 - Comensales: El bot pregunta el número de personas. Si es más de 12, activa el flujo de grupos con condiciones especiales.

Estado 4 - Nombre: El bot pide el nombre para la reserva.

Estado 5 - Alergias/intolerancias: Pregunta si algún comensal tiene alergia o intolerancia alimentaria. Si el usuario dice "no" o "ninguna", continúa. Si menciona algo, lo registra en la reserva.

Estado 6 - Confirmación: El bot muestra un resumen completo y envía botones de respuesta rápida: "Confirmar" y "Modificar". Si el usuario confirma, la reserva se escribe en Sheets y en Calendar, y se envía una confirmación con número de reserva.

Todo el estado de la conversación (en qué paso está el usuario, qué datos ha dado) se almacena en una tabla de sesiones en Google Sheets con un timeout de 30 minutos.

Los cuatro problemas que encontramos (y cómo los resolvimos)

Problema 1: fechas relativas

Los usuarios no escriben "el 21 de junio de 2026". Escriben "mañana", "el viernes", "la semana que viene el sábado", "para pascua" o "el 3 de julio a las 9 de la noche".

En la primera versión del bot, usamos expresiones regulares para parsear fechas. Era un desastre. Había decenas de formatos posibles y siempre aparecía uno nuevo.

La solución fue integrar chrono-node, una librería de JavaScript especializada en parseo de lenguaje natural para fechas. En n8n, la llamamos desde un nodo Code:

const chrono = require('chrono-node');
const userText = $json.text; // "para mañana a las 21"

const parsedDate = chrono.es.parseDate(userText, new Date(), {
  forwardDate: true  // siempre interpreta hacia el futuro
});

if (!parsedDate) {
  return { error: true, message: "No he entendido la fecha. ¿Puedes escribirla así: viernes 20 de junio?" };
}

return {
  date: parsedDate.toISOString(),
  formatted: parsedDate.toLocaleDateString('es-ES', { weekday: 'long', day: 'numeric', month: 'long' })
};

Con chrono-node en español, el 90% de los formatos de fecha que usan los clientes reales se parsean correctamente. Para los casos raros que no funcionan, el bot pide confirmación mostrando la fecha interpretada ("¿Quieres decir el martes 17 de junio?") antes de continuar.

Problema 2: horas fuera del horario de servicio

Durante la primera semana, el bot empezó a confirmar reservas para las 16:00 de un miércoles. El restaurante solo abre de 13:00 a 16:00 y de 20:00 a 23:30. A mediodía los lunes, cerrado.

La solución fue crear una tabla de configuración en Google Sheets con el horario de apertura por día y franja. El bot consulta esta tabla antes de confirmar una hora. Si la hora pedida no es válida, responde:

"Lo sentimos, los martes solo servimos cenas a partir de las 20:00. ¿Te viene bien alguna hora entre las 20:00 y las 22:30?"

Además, añadimos una columna de "aforo disponible por franja" que el bot consulta antes de confirmar. Si en esa franja ya hay X reservas con Y comensales acumulados y el aforo está al límite, el bot ofrece las franjás disponibles más cercanas.

Toda la configuración es editable directamente por el restaurante desde su móvil sin tocar código. Cuando cierran por vacaciones o evento privado, simplemente marcan ese día como no disponible.

Problema 3: el idioma

El restaurante está en una zona costera con mucho turismo extranjero. En verano, entre el 30% y el 40% de los mensajes entrantes son en inglés, francés, alemán o italiano.

El bot original solo respondía en español. Recibíamos mensajes de clientes en inglés que no entendían las respuestas y abandonaban.

La solución fue añadir un paso de detección de idioma al inicio del flujo. Usamos GPT-4o-mini para detectar el idioma del primer mensaje y almacenar el código ISO en la sesión:

// Nodo Code en n8n - Detección de idioma con GPT-4o-mini
const response = await $helpers.httpRequest({
  method: 'POST',
  url: 'https://api.openai.com/v1/chat/completions',
  headers: { 'Authorization': `Bearer ${$env.OPENAI_KEY}` },
  body: {
    model: 'gpt-4o-mini',
    messages: [{
      role: 'user',
      content: `Detect the language of this message and respond ONLY with the ISO 639-1 code (es, en, fr, de, it, etc.): "${$json.text}"`
    }],
    max_tokens: 5
  }
});

const lang = response.choices[0].message.content.trim().toLowerCase();
return { language: ['es','en','fr','de','it'].includes(lang) ? lang : 'es' };

El bot gestiona respuestas en español, inglés y francés de forma nativa. Para alemán e italiano, usa GPT-4o-mini para generar la respuesta en el idioma correcto. El coste añadido es mínimo (unas pocas décimas de céntimo por conversación) y el impacto en conversión de turistas fue notable.

Problema 4: el estado de sesión

El problema más sutil: WhatsApp no tiene sesión nativa. Cada mensaje es una petición independiente. Si el bot no recuerda que el usuario ya dijo que quería reservar para el viernes y tiene que preguntar de nuevo, la experiencia es terrible.

Usamos una tabla de sesiones en Google Sheets con esta estructura:

| phone | state | date | time | pax | name | allergies | lang | last_activity | |---|---|---|---|---|---|---|---|---| | 34612345678 | 4 | 2026-06-20 | 21:00 | 4 | García | ninguna | es | 2026-06-15T18:32:00Z |

Al inicio de cada mensaje, el bot consulta esta tabla por número de teléfono. Si encuentra una sesión con last_activity de menos de 30 minutos, recupera el estado y continúa donde lo dejó. Si han pasado más de 30 minutos, la sesión expira y el bot empieza de cero.

El timeout de 30 minutos fue calibrado después de analizar los patrones reales: la mayoría de reservas se completaban en menos de 5 minutos, pero algunos usuarios tardaban 20-25 minutos entre mensajes (estaban en el trabajo, atendiendo a algo).

Recordatorios automáticos la noche antes

Una de las funcionalidades que más valora el restaurante: la noche anterior a cada reserva, el sistema envía automáticamente un recordatorio por WhatsApp.

Un cron job en n8n se ejecuta cada día a las 19:00 y consulta Google Sheets filtrando las reservas del día siguiente. Para cada una, envía un template de tipo UTILITY aprobado por Meta:

Recordatorio de reserva - Restaurante [Nombre]

Hola {{1}}, te recordamos tu reserva para mañana:
- Fecha: {{2}}
- Hora: {{3}}
- Personas: {{4}}

Si necesitas cancelar o modificar, escríbenos antes de las 12:00 del mediodía.
¿Nos confirmas que sigues viniendo?

El mensaje incluye botones de respuesta rápida: "Confirmamos" y "Necesito cancelar". Si el usuario cancela, el flujo actualiza la reserva en Sheets y Calendar, y el slot queda libre.

Esta funcionalidad redujo los no-shows en un 40% durante las primeras cuatro semanas de uso.

Traspaso a humano cuando hace falta

El bot no puede (ni debe) gestionar todo. Los casos que escalan automáticamente a un agente humano:

• Grupos de más de 12 personas
• Solicitudes de menú cerrado o degustación
• Quejas o comentarios negativos de clientes
• Cualquier mensaje que el bot no entienda después de dos intentos

Cuando se activa el traspaso, el bot avisa al usuario ("Voy a pasarte con el equipo del restaurante, que te atenderán en breve") y envía una notificación al Telegram del restaurante con el número de teléfono del cliente y el resumen de la conversación hasta ese punto.

El equipo del restaurante puede entonces continuar la conversación directamente desde WhatsApp, ya con el contexto.

Resultados después de 6 semanas

Los datos del restaurante tras 6 semanas con el bot activo:

• 62% de las reservas se gestionan ya completamente por WhatsApp sin intervención humana
• 35% de las reservas llegan después de las 21:00 (cuando el restaurante está en pleno servicio y no puede atender el teléfono)
• Reducción del 40% en no-shows gracias a los recordatorios automáticos
• Tiempo promedio de la conversación de reserva: 3 minutos 40 segundos
• Tasa de abandono del bot: 12% (principalmente cuando no hay disponibilidad)

El restaurante ha podido eliminar una de las dos líneas de teléfono que mantenía activas solo para reservas. El equipo de sala interrumpe mucho menos durante el servicio.

Lo que no funcionó al principio

El primer mensaje de bienvenida era demasiado largo. Lo habíamos redactado con mucho detalle (horarios, dirección, web, descripción del restaurante). Los usuarios no lo leían. Muchos respondían directamente "quiero reservar" al primer mensaje sin haber leído nada.

Lo simplificamos a dos líneas:

"Hola, soy el asistente de reservas de [Restaurante]. ¿Para qué fecha quieres reservar?"

Directo al grano. La tasa de abandono en el primer paso bajó a la mitad.

La otra cosa que no funcionó: intentar usar Google Sheets como base de datos para búsquedas complejas de disponibilidad. Con mucho volumen de reservas, las consultas por fecha y aforo empezaban a ser lentas. La solución fue pre-calcular los huecos disponibles en una hoja separada que el sistema actualiza cada vez que se añade o cancela una reserva, y que el bot consulta directamente.