El agente de voz con IA que atiende llamadas y toma pedidos por tu restaurante

El teléfono suena justo cuando tu equipo no puede atenderlo

En un restaurante el teléfono no suena repartido a lo largo del día. Suena en dos franjas muy concretas, y son exactamente las mismas en las que la sala está llena, la cocina va con el pase encima y no sobra ni una persona. Quien descuelga lo hace con una comanda en la mano y a medias de otra cosa.

Eso tiene tres consecuencias que cualquiera que haya trabajado en hostelería reconoce sin necesidad de que se las expliquen:

• <strong>Llamadas que no se cogen.</strong> No porque nadie quiera atenderlas, sino porque en ese momento no hay manos. Y la mayoría de esas llamadas no vuelven a intentarlo: se van al restaurante siguiente.
• <strong>Comandas tomadas a medias.</strong> Un nombre mal entendido, un extra que no se apunta, una dirección incompleta. El error no aparece en la llamada: aparece cuarenta minutos después, cuando el pedido ya está hecho.
• <strong>Servicio interrumpido.</strong> Cada llamada saca a alguien de lo que estaba haciendo. En sala eso es una mesa que espera; en cocina, un plato que se pasa.

Lo importante es que ninguna de las tres se arregla contratando a alguien para el teléfono: el problema no es de plantilla, es de simultaneidad. Dos llamadas a la vez a las 21:15 siguen siendo dos llamadas a la vez.

Qué es un agente de voz con IA para restaurantes

Un agente de voz con IA es un sistema que descuelga el teléfono, entiende lo que dice quien llama y resuelve la gestión hablando, en lenguaje normal. No es un menú de opciones ni una locución grabada: no hay que pulsar teclas ni memorizar un orden.

La diferencia con un asistente genérico está en de dónde saca la información. Un agente de voz para restaurantes solo sirve si conoce el negocio concreto: los platos que hay hoy, sus precios, sus tamaños y extras, los alérgenos declarados, el horario real de cada tipo de pedido y hasta dónde llega el reparto. Sin esos datos responde de forma plausible y equivocada, que en un restaurante es la peor combinación posible.

Lo que debería resolver, y lo que no

Un agente serio no intenta hacerlo todo. Resuelve bien lo repetitivo —el pedido de siempre, el horario, la dirección, la reserva de cuatro para el sábado— y se aparta rápido en lo que requiere criterio: una reclamación, un grupo grande con condiciones especiales, una alergia con matices. Saber dónde está esa frontera es la mitad del trabajo.

Qué llamadas resuelve

Pedidos para recoger

Es el caso más frecuente y el más agradecido. El cliente llama, dice lo que quiere, el agente lo repite para confirmar y le da una hora de recogida coherente con lo que la cocina ya tiene dentro. El pedido entra con su referencia, así que cuando el cliente aparece en el mostrador basta con ese código para localizarlo.

Pedidos a domicilio

Aquí hay un paso más que no se puede despachar deprisa: la dirección. Hay que recogerla completa, comprobar que cae dentro de la zona de reparto y decir el coste del envío antes de cerrar. Pedi2 ya gestiona las zonas de reparto por polígono en el mapa, por radio en kilómetros o por porcentaje, así que ese dato existe y se puede consultar en la propia llamada.

Reservas de mesa

Pedi2 ya tiene reservas con control de aforo real: la disponibilidad se calcula contra las mesas y la duración configurada, no contra una agenda a ojo. Una reserva tomada por teléfono debería entrar por ese mismo sitio, con su confirmación al cliente, y no en una libreta paralela que solo entiende quien la escribió.

Preguntas sobre carta, horarios y disponibilidad

Muchas llamadas no son un pedido: son «¿a qué hora abrís?», «¿tenéis mesa para seis?», «¿el arroz lleva marisco?» o «¿repartís en mi calle?». Son cortas, se repiten cien veces y aun así hay que atenderlas. Son justo las que mejor encaja resolver sin interrumpir a nadie, siempre que la respuesta salga de datos registrados y no de una suposición.

Varias llamadas a la vez

Es la diferencia estructural frente a una persona atendiendo el teléfono. En hora punta las llamadas no llegan de una en una, y la segunda que entra mientras se atiende la primera es la que hoy se pierde. Un agente no tiene ese límite: cada llamada es independiente.

La ventaja real de resolver el teléfono dentro de Pedi2 y no con una herramienta suelta es que el pedido telefónico no se convierte en una isla. Cae en la misma pantalla de cocina, cuenta en los mismos totales del día, usa las mismas zonas de reparto y respeta los mismos horarios. Si mañana cambias el precio de un plato, cambia para los cuatro canales a la vez porque solo hay un sitio donde cambiarlo.

Lo contrario —una solución de voz por un lado y el resto del negocio por otro— acaba siempre igual: dos cartas que se desincronizan, un canal cuyos pedidos no aparecen en los informes y alguien copiando datos de una pantalla a otra en plena hora punta.

Puedes ver el detalle de cada canal en todo lo que hace Pedi2, y cómo se monta el sistema en cómo funciona.

Cuándo tiene que entrar una persona

Esta sección es tan importante como la de lo que el sistema sabe hacer, y es la que casi nunca aparece en las webs de este tipo de producto. Un agente que insiste cuando no entiende hace más daño que uno que se aparta pronto: el cliente cuelga con la sensación de que el restaurante le ha puesto una máquina delante para no atenderle.

Casos en los que la llamada debe pasar al equipo:

• El cliente lo pide, con las palabras que sean.
• Una reclamación o un problema con un pedido anterior.
• Un grupo grande, un evento o una petición con condiciones particulares.
• Una consulta sobre alergias que no se resuelve con lo registrado en la ficha del plato.
• Cualquier momento en el que el sistema no esté razonablemente seguro de haber entendido.

El criterio no es nuevo en Pedi2: el agente de WhatsApp ya para y avisa al equipo cuando la conversación se sale de lo que puede resolver, y desde ese momento la persona toma el mando del chat. La versión telefónica tiene que comportarse igual.

Confirmación y seguridad del pedido

Tomar un pedido hablando tiene un riesgo que no tiene tomarlo por escrito: no queda nada a la vista que el cliente pueda repasar. Por eso un sistema de voz serio necesita, como mínimo:

• <strong>Confirmación verbal final.</strong> Repetir el pedido completo y esperar un sí antes de cerrarlo.
• <strong>Repaso de líneas.</strong> Productos, cantidades, tamaños, variantes y extras, uno a uno.
• <strong>Importe cuando corresponda</strong>, para que nadie se sorprenda al pagar.
• <strong>Comprobación de horario y disponibilidad</strong> antes de prometer una hora.
• <strong>Validación de la dirección</strong> en los envíos, contra la zona de reparto real.
• <strong>Derivación humana ante baja confianza</strong>, en vez de dar por buena una interpretación dudosa.
• <strong>Prudencia con las alergias.</strong> Se informa de lo registrado y se remite al equipo; no se certifica que un plato sea apto.
• <strong>Solo información verificada.</strong> Precios, ingredientes, disponibilidad y horarios salen de los datos del restaurante, nunca de una suposición del modelo.

Este último punto es el que más se descuida y el que más caro sale. En el agente de WhatsApp de Pedi2 está resuelto con comprobaciones en el servidor: el modelo propone una línea de pedido y el servidor verifica contra la carta que ese plato existe, que está disponible y que el precio es el que consta. Si no cuadra, no se registra. Ese planteamiento —el modelo no es la última palabra— es el que hace que un sistema de voz se pueda usar con clientes reales.