Chatbot de WhatsApp para restaurantes y delivery

Un chatbot de WhatsApp para un restaurante es un agente que atiende el número del negocio, entiende lo que pide el cliente escrito como le da la gana —«dos margaritas sin cebolla y una coca», no un menú numerado—, arma el pedido con sus extras, comprueba si estás abierto y si repartes en esa dirección, y lo deja cobrado y metido en el mismo sitio donde ya miras las comandas. Lo que lo diferencia de un bot de menú clásico es que no obliga al cliente a hablar como una máquina: interpreta el lenguaje, y el resto del flujo —precios, horarios, zonas, cobro— lo siguen ejecutando reglas normales, que es donde tiene que estar la certeza.

Y conviene decir la mitad incómoda antes de seguir: la mayoría de los restaurantes no necesita un chatbot para tomar pedidos. Si lo único que quieres es que la gente pida sin llamar por teléfono, una carta online con carrito es más barata, más rápida y se equivoca menos: el cliente ve la foto, marca los extras que existen de verdad y paga. Un chatbot que reproduce ese formulario en forma de conversación es un formulario peor. El chatbot se gana el sitio cuando la conversación es conversación: modificaciones raras, alergias, «lo de siempre», pedidos que se cambian a mitad, clientes que preguntan antes de decidir, y —sobre todo— el trabajo de traerte a ese cliente de vuelta a tu canal en lugar de dejarlo dentro de la plataforma de reparto.

Lo que de verdad está en juego: la comisión y el cliente

En un restaurante con reparto hay dos costes que no se ven en la carta. El primero es la comisión que se lleva cada pedido que entra por una plataforma de delivery. El segundo, más caro a largo plazo, es que el cliente no es tuyo: su teléfono, su historial y su relación viven en la aplicación, no en tu negocio. Puedes servir mil pedidos y seguir sin poder avisar a nadie de que hoy hay oferta.

Un canal propio de WhatsApp ataca las dos cosas a la vez. El pedido entra sin comisión de plataforma —con sus propios costes, que veremos abajo—, y la conversación queda en un número que sí es tuyo, con un historial que sí puedes usar. Por eso la métrica que hay que mirar en este proyecto no es «cuántos pedidos toma el bot», sino cuántos pedidos dejaron de entrar por la plataforma y entraron por tu número, y cuántos de esos clientes repitieron.

Esto no significa dejar las plataformas: significa dejar de depender solo de ellas. El movimiento realista es que la plataforma siga trayendo clientes nuevos y que tu canal se quede con los que repiten.

Los cinco puntos donde se rompe un chatbot de pedidos

Casi todos los proyectos que salen mal se rompen en el mismo puñado de sitios. Ninguno es «la IA no entiende».

1. El catálogo desactualizado. Es el fallo número uno. Si la carta del bot es una copia escrita a mano hace tres meses, va a vender un plato que ya no existe o al precio de antes. El catálogo tiene que salir del mismo sitio del que sale la carta real —tu web, tu TPV, tu hoja de precios— y actualizarse solo. Un bot con catálogo propio es una segunda carta que alguien tiene que recordar mantener, y nadie la mantiene.

2. Los extras y las modificaciones. «Sin cebolla», «doble de queso», «la mitad barbacoa», «una sin gluten». Aquí es donde un bot de botones se queda corto y donde un modelo de lenguaje aporta de verdad, pero también donde más caro sale equivocarse: hay que distinguir el extra que existe y tiene precio del capricho que la cocina no puede servir. La regla que funciona es que el modelo interpreta, pero solo puede elegir entre las opciones que el catálogo declara. Si el cliente pide algo que no está, el bot lo dice en lugar de inventarlo.

3. Horario y zona de reparto. Un pedido aceptado a las 23:50 cuando la cocina cierra a las 23:30, o a una dirección que queda fuera del radio, es peor que un pedido perdido: es un cliente enfadado y una devolución. Esto no se le pregunta a la IA, se comprueba con una regla, contra el horario real y contra el mapa de reparto, antes de cobrar nada.

4. El cobro. Es lo que separa un bot que «apunta» pedidos de uno que los cierra. En España lo normal es enlazar una pasarela que acepte tarjeta —con Redsys o similar según lo que ya use el negocio— y que el bot mande un enlace de pago único por pedido. Mientras el pago no confirma, el pedido no baja a cocina.

5. Lo que el bot no sabe. Siempre hay un caso raro: una reclamación, un pedido de sesenta personas, alguien que quiere hablar con el dueño. Un chatbot sin salida a un humano se convierte en un muro. La conversación tiene que poder pasar a una persona sin que el cliente tenga que repetir nada, y eso obliga a que exista una bandeja donde alguien vea el hilo entero.

Cómo lo he montado en un caso real

El proyecto donde tengo esto en producción es el agente de ventas de una pizzería con reparto. No es un demo: atiende, arma el pedido y cobra.

Por dentro tiene exactamente las piezas de arriba: catálogo dinámico —la carta y los precios salen del sistema, no de un texto pegado en el bot—, gestión de extras y modificadores con sus precios, memoria de sesión para que el cliente pueda cambiar de idea a mitad del pedido sin empezar de cero, y cobro con tarjeta integrado (Stripe y Redsys) antes de que la comanda entre. La orquestación está hecha sobre n8n, que es lo que permite que el flujo se toque sin reescribir el sistema entero cada vez que cambia una promoción.

La lección de ese proyecto no fue sobre el modelo de lenguaje. Fue que el 80 % del trabajo está en las reglas del negocio —qué extras existen, qué combinaciones son imposibles, hasta qué hora, hasta qué calle, qué pasa si el pago falla a medias— y el 20 % en que el bot entienda la frase. Cuando alguien vende esto como «conectamos una IA a tu WhatsApp», está cobrando por el 20 % y dejándote el 80 %.

En paralelo, en una plataforma del sector energético construí la otra mitad del problema: un chatbot de WhatsApp con bandeja omnicanal, donde las conversaciones que el agente no puede cerrar aterrizan en un panel y las contesta una persona, con todo el hilo delante. Es el mismo patrón, en otro sector: el agente resuelve lo repetitivo, y lo excepcional tiene una puerta clara.

Qué necesitas antes de empezar

Antes de escribir una línea de código hay cuatro cosas que decidir, y ninguna es técnica del todo:

• Un número con WhatsApp Business API. El WhatsApp Business normal, el de la aplicación del móvil, no permite que un sistema conteste solo de forma estable. Hay que dar de alta el número en la API oficial de Meta a través de un proveedor. Si el número que usas hoy ya está en la aplicación, hay que migrarlo, y durante la migración no se atiende: conviene hacerlo un lunes por la mañana, no un viernes a las nueve de la noche.
• La carta, en algún sitio que sea la fuente de verdad. Con precios, extras, alérgenos y disponibilidad. Si hoy vive en un PDF y en la cabeza del encargado, ese es el primer trabajo del proyecto.
• Dónde aterriza el pedido. En el TPV, en la impresora de comandas, en un panel, en un correo. Un pedido que llega a un chat que nadie mira en hora punta no está automatizado, está escondido.
• Quién atiende lo que el bot no sabe, y en qué horario. Aunque sea el móvil del encargado.

Qué cuesta, y por qué nadie serio te da una cifra por teléfono

El coste de un chatbot de WhatsApp tiene tres capas, y mezclarlas es lo que hace que los presupuestos no se parezcan entre sí:

1. Lo que cobra Meta por los mensajes. No es una tarifa plana: depende del tipo de mensaje y de si la conversación la abre el cliente o el negocio, y Meta ha cambiado ese modelo más de una vez. La tarifa vigente está publicada en la página de precios de WhatsApp de Meta — mírala ahí y no te fíes de la cifra que te diga nadie de memoria, incluido yo.
2. El proveedor de la API y el modelo de IA. Ambos se pagan por uso: cuanto más conversas, más cuesta. Es un gasto recurrente, pequeño por conversación, y hay que contarlo desde el principio porque no desaparece.
3. La construcción. Aquí es donde está la diferencia real de precio, y depende de lo mismo que en cualquier desarrollo a medida: en qué estado está tu catálogo, con qué sistemas hay que integrarse (TPV, pasarela, comandas) y cuántos casos raros tiene tu operativa. Un restaurante con carta fija y una zona de reparto no cuesta lo mismo que una cadena con tres locales, horarios distintos y promociones por zona.

Lo que sí se puede decir sin conocer el negocio es qué lo encarece: integraciones con sistemas cerrados, catálogos que no existen en formato utilizable y excepciones. Si alguien te da un precio cerrado sin haber preguntado por esas tres cosas, el precio no es un precio, es un número.

Errores que se repiten

• Empezar por el bot y no por el proceso. Antes de automatizar la toma de pedidos conviene mirar cómo se toman hoy, igual que en cualquier automatización de procesos: a veces el cuello no es tomar el pedido, es que la cocina se entera tarde.
• No poner límites al modelo. Un agente que puede inventar precios o aceptar cualquier cosa acabará regalando comida. Los precios, los horarios y las zonas se comprueban con reglas; el modelo interpreta, no decide.
• Ningún camino a un humano. Ya está dicho arriba, pero es el error que más clientes cuesta.
• Montarlo y no volver a tocarlo. Cambian la carta, los precios, las promociones y las reglas de Meta. Un canal de ventas necesita mantenimiento igual que una web, y este además factura.
• Medir mensajes en lugar de pedidos. «El bot atendió 400 conversaciones» no es un resultado. Pedidos cerrados, ticket medio y clientes que repiten, sí.

Por dónde empezar sin romper nada

Lo que mejor funciona es empezar por lo repetitivo y bajo riesgo, y ampliar cuando ya funciona: primero que el agente conteste horarios, zona de reparto y carta —lo que hoy contesta una persona veinte veces al día—, después que arme el pedido, y solo al final que cobre. Cada tramo se puede medir por separado, y si algo falla se sabe exactamente dónde.

Si tienes un restaurante con reparto y quieres una opinión honesta sobre si esto te conviene —incluida la respuesta «con una carta online te vale»—, escríbeme y lo miramos.

Preguntas frecuentes

¿Qué es un chatbot de WhatsApp para restaurantes?

Es un agente que atiende el número de WhatsApp del restaurante y gestiona la conversación completa de un pedido: entiende lo que pide el cliente escrito con sus palabras, aplica los extras y modificaciones sobre el catálogo real, comprueba horario y zona de reparto, cobra y deja la comanda en el sistema del local. Se diferencia de un bot de menú numerado en que interpreta lenguaje libre en lugar de obligar al cliente a elegir opciones.

¿Sirve para quitarme la comisión de las plataformas de delivery?

Sirve para reducir la dependencia, no para eliminarla de golpe. Lo realista es que la plataforma siga trayendo clientes nuevos y que tu canal propio se quede con los que repiten, que son los que más comisión te cuestan al cabo del año. El indicador a vigilar es qué porcentaje de pedidos entra por tu número, y cuántos de esos clientes vuelven.

¿Necesito la API oficial de WhatsApp o me vale la aplicación de WhatsApp Business?

Para que un sistema conteste solo de forma fiable hace falta dar de alta el número en la API oficial de Meta a través de un proveedor. La aplicación de WhatsApp Business está pensada para que conteste una persona desde el móvil y no ofrece una vía estable para automatizar. Si tu número actual está en la aplicación, se puede migrar, pero durante la migración el número no atiende: conviene hacerlo en horario de poca actividad.

¿Cuánto cuesta un chatbot de WhatsApp?

Tiene tres capas: lo que Meta cobra por los mensajes (tarifa publicada por Meta, cambia con el tiempo), el uso del proveedor de API y del modelo de IA —un gasto recurrente por conversación— y la construcción, que es donde está la diferencia entre presupuestos. Esa tercera capa depende del estado de tu catálogo, de con cuántos sistemas hay que integrarse y de cuántas excepciones tiene tu operativa. Un precio cerrado dado sin preguntar por esas tres cosas no es un presupuesto.

¿Y si el bot se equivoca con un pedido?

El diseño tiene que contar con que se equivoca. Por eso los precios, los horarios y las zonas de reparto no los decide el modelo sino reglas fijas del sistema, el pedido se confirma al cliente antes de cobrarlo, y siempre existe un camino a una persona sin que el cliente tenga que repetir nada. Durante las primeras semanas conviene que alguien revise los pedidos que entran antes de dar el canal por rodado.