Cómo integrar pedidos online, POS y cocina sin perder modificaciones ni estados

Un cliente pide una hamburguesa sin cebolla, añade queso y programa la recogida para una hora concreta. El canal online confirma el pedido, pero el POS recibe el producto sin una modificación y la pantalla de cocina lo muestra como inmediato. El equipo debe aclararlo manualmente, rehacer el plato o gestionar una reclamación que podría haberse evitado.

Este problema no suele estar en una única aplicación. Aparece en los límites entre el canal de venta, el POS, el sistema de cocina y las comunicaciones con el cliente. Una integración de pedidos online con POS y cocina debe preservar datos, contexto y estados durante todo el recorrido, además de ofrecer una forma clara de detectar y resolver excepciones.

Dibujar el flujo antes de conectar sistemas

El primer paso consiste en documentar qué ocurre desde que el cliente abre el menú hasta que el pedido se entrega, recoge o cancela. Hay que incluir la web propia, las plataformas externas, el gestor de pedidos, el POS, las impresoras o pantallas de cocina, el sistema de pagos y los mensajes enviados al cliente.

Para cada paso, conviene identificar:

• qué sistema crea o modifica la información;
• cuál mantiene el registro principal;
• qué datos recibe el siguiente sistema;
• qué respuesta confirma que la operación ha funcionado;
• quién interviene cuando se produce una excepción.

“Pedido enviado” no significa necesariamente “pedido aceptado por el restaurante”. Del mismo modo, que el POS lo haya registrado no garantiza que cocina lo haya recibido. Es preferible definir confirmaciones independientes para cada punto relevante.

Crear un modelo común de pedido

Cada plataforma puede representar productos y modificaciones de forma distinta. Una utiliza identificadores internos; otra envía nombres de texto; una tercera trata un menú como producto compuesto. Conectar campos sin diseñar un modelo común produce integraciones frágiles.

El modelo debería contemplar, como mínimo:

• identificador único del pedido y canal de origen;
• restaurante, zona horaria y tipo de servicio;
• productos, cantidades y variantes;
• grupos de modificadores, selecciones y precios;
• instrucciones especiales conservadas en su texto original;
• impuestos, descuentos, cargos, propinas y total;
• estado del pago, sin duplicar datos sensibles innecesarios;
• hora solicitada y hora operativa prevista;
• datos de contacto estrictamente necesarios;
• historial de estados y errores.

Los identificadores son más fiables que los nombres para relacionar productos. Si “Patatas grandes” cambia de nombre en un canal, la asociación no debería romperse. También es importante establecer reglas para productos desactivados, modificadores obligatorios, límites de selección y combinaciones no disponibles.

Tratar el texto libre como una excepción visible

Las notas del cliente pueden contener instrucciones ambiguas o solicitudes que no corresponden al menú. No conviene transformarlas silenciosamente en modificaciones estructuradas. Deben llegar visibles al equipo junto con el pedido original.

La IA puede ayudar a clasificar o resumir texto libre, pero su resultado es probabilístico. Si se utiliza, el mensaje original debe permanecer disponible y cualquier interpretación con impacto operativo debe someterse a revisión humana. Para precios, estados, cantidades y enrutamiento, las reglas deterministas son más apropiadas.

Definir estados y autoridad

Una integración necesita un vocabulario de estados acordado. Por ejemplo: recibido, pendiente de aceptación, aceptado, enviado a cocina, en preparación, listo, entregado, cancelado y con error. Lo importante no es la cantidad de estados, sino que cada uno tenga un significado y un responsable.

Debe definirse qué sistema puede cambiar cada estado. Si el POS es la fuente operativa principal, una plataforma externa no debería marcar un pedido como preparado sin una señal válida. También hay que decidir qué ocurre con cambios tardíos, cancelaciones después de iniciar la preparación y pedidos programados.

Una tabla de transiciones ayuda a impedir movimientos incoherentes, como pasar de “cancelado” a “en preparación”. Las excepciones pueden requerir autorización de un encargado y deben quedar registradas.

Incorporar controles de error desde el diseño

Una integración fiable no es la que nunca falla, sino la que detecta fallos y permite recuperarse sin crear pedidos duplicados. Entre los controles útiles están:

• claves de idempotencia para evitar duplicados durante reintentos;
• confirmaciones entre sistemas y tiempos máximos de espera;
• reintentos controlados para errores temporales;
• una cola separada para operaciones que requieren revisión;
• alertas con contexto suficiente para actuar;
• conciliación periódica de pedidos, importes y estados;
• registro de cambios con hora, sistema y resultado.

También hace falta un procedimiento de contingencia. Si la conexión con cocina se interrumpe, el restaurante debe saber si consulta el POS, imprime temporalmente los pedidos o pausa un canal. El procedimiento debe evitar que varias personas creen el mismo pedido manualmente.

Asignar responsables operativos

La tecnología no resuelve una excepción si nadie es responsable de responder. Conviene asignar propietarios para el menú, los mapeos, la operación del turno, las incidencias técnicas y la conciliación administrativa.

El personal del restaurante necesita instrucciones simples: cómo reconocer un pedido incompleto, dónde consultar su estado real, cuándo contactar al cliente y a quién escalar el problema. Los mensajes de error técnicos deben traducirse en acciones operativas comprensibles.

Probar recorridos, no solo conexiones

Comprobar que dos sistemas intercambian datos es insuficiente. Las pruebas deben recorrer el proceso completo hasta cocina y, cuando corresponda, devolver el estado al cliente.

Una matriz de pruebas puede incluir pedidos inmediatos y programados, múltiples cantidades, modificadores obligatorios y opcionales, descuentos, falta de disponibilidad, rechazo, cancelación, pérdida temporal de conexión, reintentos y cierre del local. También deben probarse caracteres especiales, notas largas y cambios de menú.

Para cada caso se compara el pedido original con lo mostrado en el POS, cocina y las comunicaciones. Las diferencias deben registrarse y corregirse antes del despliegue.

Desplegar de forma limitada y medir

Es más prudente empezar con un local, un canal y una parte controlada del menú. El equipo debe conocer el piloto y disponer de una vía rápida para comunicar problemas. Durante esta fase, puede mantenerse una conciliación manual temporal para verificar que los datos coinciden.

Las métricas útiles incluyen pedidos que requieren intervención, modificaciones perdidas o mal representadas, duplicados, errores por sistema, tiempo entre recepción y aceptación, diferencias de importe y estados que quedan bloqueados. Cada incidencia debe relacionarse con una causa y una acción correctiva.

La ampliación a otros locales o canales debería producirse solo cuando el flujo sea estable y los responsables puedan gestionar excepciones. Así, la integración crece sobre un proceso conocido, no sobre una conexión difícil de observar.

Cibercoding puede ayudarte a revisar este flujo, localizar puntos de pérdida y definir un piloto de integración con controles y responsabilidades claros.