Pedidos por WhatsApp: del chat a la cocina sin copiar nada

Una persona escribe por WhatsApp: «Quiero dos hamburguesas, una sin cebolla, papas para compartir y pago por PSE». Parece un pedido. Para el restaurante todavía no lo es.

Falta comprobar que los platos estén disponibles, guardar el modificador, calcular el domicilio, validar la dirección, generar el cobro, confirmar que el pago sí fue aprobado, enviar la orden a cocina y avisar cuándo sale. Si una persona copia esa conversación a caja y otra vuelve a escribirla en una comanda, WhatsApp solo cambió el lugar donde empezó el trabajo. No conectó la operación.

Un sistema de pedidos por WhatsApp para restaurantes sirve cuando el mensaje atraviesa todo ese recorrido sin perder información. Esta guía muestra qué debe conectarse, qué dato gobierna cada paso y cómo medir si el canal funciona de verdad.

1 · Un pedido no es una conversación

La conversación es la interfaz. El pedido es un registro con identidad propia: número, cliente, sede, productos, cantidades, modificadores, valor, dirección, método de entrega, estado de pago y estado operativo. Esa diferencia decide si el restaurante puede crecer sin llenar la cocina de capturas de pantalla.

El chat puede entender «sin cebolla» y responder con naturalidad. El sistema debe convertirlo en una instrucción estructurada que viaje hasta la estación correcta. Si cocina recibe solamente «pedido de Laura» y tiene que abrir WhatsApp para buscar el resto, el flujo sigue roto.

2 · Las siete conexiones del mensaje a la entrega

1. Menú real, disponibilidad y modificadores

El agente necesita consultar la misma carta que gobierna la operación. No un PDF antiguo ni una lista pegada dentro de un prompt. Cada producto debe tener precio, sede, horario, disponibilidad, opciones y reglas: proteína, tamaño, acompañamiento, adiciones y alérgenos declarados por el restaurante.

Si se agota un plato, el cambio debe cerrar esa opción para el chat y para la web. Si el menú de WhatsApp sigue vendiéndolo, el equipo empieza la relación con una disculpa y el pedido vuelve a negociarse desde cero.

2. Carrito y número único de pedido

La conversación puede cambiar: «mejor tres», «quita una bebida», «la segunda sin salsa». El carrito conserva una versión actual del pedido y calcula de nuevo el total. Cuando el cliente confirma, el sistema genera una referencia única. Desde ese momento pago, cocina y soporte hablan del mismo pedido.

Sin esa referencia aparecen dos errores comunes: el pago que nadie sabe a qué orden pertenece y la orden duplicada porque el cliente escribió otra vez para preguntar si llegó.

3. Dirección, cobertura y costo de entrega

Antes de cobrar, el sistema debe decidir si el restaurante atiende esa dirección, desde qué sede y con qué tarifa. Barrio escrito a mano no basta. Una dirección válida necesita ciudad, dirección completa, indicaciones y una regla de cobertura que el restaurante pueda mantener.

Esta validación también protege la promesa de tiempo. El agente no debería ofrecer cuarenta minutos si la sede asignada está saturada o el destino está fuera de la zona habitual. Cuando no puede calcular con certeza, deriva el caso con todo el contexto ya recogido.

4. Cobro confirmado por el sistema

Enviar un enlace no significa cobrar. El pedido debe conservar un estado como pendiente, aprobado, rechazado o vencido. Cocina recibe la orden cuando se cumple la regla comercial del restaurante: pago aprobado, pago contra entrega autorizado o validación humana excepcional.

Con Wompi, por ejemplo, una transacción nueva puede empezar en estado PENDING. El backend recibe el cambio mediante el evento transaction.updated y valida su firma antes de marcar el pedido como pagado. La propia documentación de Wompi recomienda terminar la integración con eventos del servidor, no confiar en la redirección que ve el cliente. Puedes revisar las reglas oficiales de eventos y verificación.

Una captura de Nequi puede servir en un proceso manual, pero no equivale a confirmación automática. Si el restaurante acepta ese método, necesita una cola explícita de revisión para que nadie confunda «comprobante recibido» con «dinero conciliado».

5. POS o pantalla de cocina

Después del cobro, la orden debe entrar al punto de venta o a una pantalla de cocina con platos, cantidades, modificadores, hora prometida y tipo de entrega. Si el POS tiene API o webhooks, la integración puede ser directa. Si no los tiene, hace falta diseñar una etapa intermedia segura y reconocer el límite desde el principio.

La cocina no necesita leer la conversación completa. Necesita una comanda limpia. Atención sí necesita conservar el historial para resolver una duda sin pedirle al cliente que repita todo.

6. Estados que también ve el cliente

El pedido cambia de estado: recibido, pendiente de pago, confirmado, en preparación, listo, en camino, entregado o cancelado. Cada cambio debe tener hora y responsable. Solo algunos necesitan generar un mensaje.

Ese diseño evita dos extremos: silencio total o una avalancha de notificaciones. El cliente necesita saber que el pago fue aprobado, que cocina recibió el pedido y que salió. El equipo necesita más detalle para actuar cuando algo queda detenido.

Los estados de WhatsApp también importan. Que la API acepte un mensaje no demuestra que el cliente lo recibió. El sistema debe leer los webhooks de entrega y mostrar fallos operativos. En el caso de los mensajes fantasma de WhatsApp documentamos por qué esa diferencia puede dejar una operación aparentemente sana mientras el cliente no recibe nada.

7. Historial y recompra con permiso

Cuando el pedido termina, queda información útil: qué compró, qué modificó, en qué sede, cuánto pagó y si autorizó comunicaciones posteriores. Esa memoria permite que la siguiente conversación empiece mejor: «¿Quieres repetir el pedido anterior?».

La autorización importa. Comprar una vez no convierte al cliente en audiencia para campañas indefinidas. El restaurante debe guardar el consentimiento, respetar la baja y limitar el uso de datos a lo informado en su política.

3 · Así se ve el recorrido completo

4 · Qué se rompe cuando las piezas viven separadas

Pieza aislada	Falla visible	Dato que debería viajar
Menú como PDF	Se venden platos agotados o con precio anterior	Disponibilidad y precio vigentes
Pedido dentro del chat	Alguien vuelve a escribirlo en caja	Carrito y referencia única
Enlace de pago suelto	No se sabe qué pedido pagó el cliente	Referencia, monto y estado
Comanda por captura	Se pierden modificadores y prioridades	Productos, notas y hora prometida
Despacho sin estados	El cliente pregunta varias veces dónde va	Estado, hora y responsable
CRM aparte	La recompra empieza como si fuera primera visita	Historial y consentimiento

5 · Qué debe medir el tablero

Medir mensajes recibidos no alcanza. El tablero debe seguir el pedido por etapas y mostrar dónde se cae.

• Conversaciones con intención de compra: separa preguntas de pedidos reales.
• Pedidos confirmados: muestra cuántos carritos terminaron en una orden.
• Abandono antes del pago: detecta fricción en menú, cobertura o checkout.
• Pagos aprobados, rechazados y pendientes: evita que el dinero quede como una caja negra.
• Tiempo hasta cocina: mide desde la confirmación hasta la recepción de la comanda.
• Tiempo de preparación y entrega: permite comparar promesa con realidad.
• Pedidos con corrección, cancelación o devolución: revela errores de captura y cumplimiento.
• Recompra por cliente y por canal: muestra si el canal propio construye relación.

No existe un porcentaje universal que demuestre éxito. Primero se mide una línea base: volumen, abandono, errores, tiempos y recompra. Después se fija una meta por etapa. Así el restaurante sabe qué cambió y evita atribuirle al sistema ventas que habrían ocurrido de todas formas.

6 · Cómo implementarlo sin detener el restaurante

El orden importa más que la cantidad de funciones. Un despliegue razonable empieza con una sede, una parte estable del menú y un horario controlado.

1. Mapear la operación actual. Seguir pedidos reales desde el primer mensaje hasta la entrega y anotar cada copia, espera y decisión humana.
2. Definir la fuente de verdad. Elegir dónde viven menú, precios, disponibilidad, pedidos y estados.
3. Construir el flujo mínimo. Menú, carrito, cobertura, confirmación y comanda, todavía con supervisión del equipo.
4. Conectar pagos. Usar referencias únicas, webhooks firmados y reglas claras para estados pendientes o rechazados.
5. Integrar cocina y despacho. Activar la ruta al POS o pantalla de cocina y los estados que necesita el cliente.
6. Medir antes de ampliar. Comparar errores, tiempos y abandono con la línea base. Después sumar upselling, fidelización o nuevas sedes.

El equipo humano sigue siendo parte del diseño. Reclamos, direcciones ambiguas, alergias no contempladas y excepciones comerciales necesitan derivación. Automatizar bien también significa saber cuándo detener el flujo y entregar el caso con contexto.

7 · Dónde entra Cocina Conectada

Cocina Conectada reúne canal propio, menú dinámico, agente de WhatsApp, pagos, integración operativa y tablero. La implementación se diseña alrededor del POS y las reglas que el restaurante ya utiliza. Si el sistema actual no ofrece una integración segura, ese límite se identifica durante el diagnóstico, antes de prometer automatización completa.

La inversión publicada permanece visible únicamente para usuarios de MD con sesión iniciada. El valor depende del paquete y de integraciones adicionales como varias sedes o un POS propietario.

El siguiente pedido debería escribirse una sola vez

WhatsApp puede ser el inicio de un canal propio. El valor aparece cuando deja de ser una bandeja que alguien vigila y se convierte en la entrada de una operación trazable.

Antes de comprar una herramienta, toma cinco pedidos recientes y dibuja su recorrido. Si encuentras datos copiados, pagos revisados por captura, comandas reconstruidas y clientes preguntando por el estado, ya tienes el mapa de lo que debe conectarse. El primer objetivo no es automatizar todo. Es conseguir que cada pedido conserve la misma información desde el mensaje hasta la entrega.

---

Escrito por Lic. J. Andrés A. García, fundador y director de estrategia de MD Estudio Creativo. Para ampliar el contexto, consulta la guía completa de agentes IA para restaurantes y la guía de upselling para aumentar el ticket promedio.