Cómo integrar los pedidos de delivery con el POS de un restaurante

Un cliente pide una hamburguesa sin cebolla, añade queso y elige patatas como acompañamiento. La plataforma de delivery acepta el pedido, pero el POS recibe una línea incompleta o asigna el modificador a otro producto. Cocina prepara algo distinto, el equipo pierde tiempo comprobando pantallas y el cliente recibe una experiencia que nadie quería ofrecer.

La integración de plataformas de delivery con POS debe evitar precisamente esas situaciones. No consiste solo en trasladar pedidos entre sistemas: debe conservar la intención del cliente, aplicar las reglas operativas del restaurante y comunicar correctamente qué está ocurriendo. Para conseguirlo hacen falta datos bien estructurados, responsables claros, controles y un despliegue que permita aprender sin poner toda la operación en riesgo.

Documentar el flujo antes de conectar sistemas

El primer paso es observar cómo se gestiona hoy un pedido, desde que se publica el menú hasta que se cierra la operación. Conviene identificar:

• Dónde se mantienen productos, precios, impuestos y disponibilidad.
• Cómo llegan actualmente los pedidos de cada plataforma.
• Quién los acepta, rechaza o modifica.
• Cómo se envían a cocina y cómo se imprimen o muestran.
• Qué estados se comunican al repartidor y al cliente.
• Cómo se procesan cancelaciones, reembolsos e incidencias.
• Qué sistema conserva la información necesaria para conciliación e informes.

Este análisis descubre duplicidades y decisiones que podrían quedar ocultas al hablar únicamente de interfaces técnicas. También ayuda a definir el sistema maestro de cada dato. Por ejemplo, el POS puede controlar la disponibilidad, mientras una herramienta central de menús distribuye descripciones e imágenes. Si dos sistemas pueden modificar el mismo campo sin una regla de prioridad, aparecerán inconsistencias.

Diseñar el mapeo del menú

El nombre visible de un plato no basta para identificarlo. La integración necesita relacionar los identificadores de la plataforma con los códigos internos del POS, manteniendo categorías, variantes, impuestos y reglas de preparación.

Productos, variantes y combos

Cada producto debe tener una correspondencia explícita. Un menú de mediodía podría aparecer como un único artículo en delivery, pero necesitar varios componentes en el POS para que cocina reciba primero, segundo y bebida. El diseño debe decidir si esa composición se transforma antes de entrar al POS o si este puede representarla directamente.

También hay que contemplar tamaños y variantes. Mediana y grande no deberían depender de una interpretación del texto libre; necesitan códigos definidos y validados. Lo mismo ocurre con promociones y combos cuyos componentes pueden cambiar.

Modificadores y restricciones

Los modificadores suelen concentrar buena parte de la complejidad: extras, ingredientes retirados, puntos de cocción, acompañamientos y selecciones obligatorias. Para cada grupo conviene documentar:

• Cantidad mínima y máxima de opciones.
• Modificadores incluidos y suplementos de precio.
• Combinaciones incompatibles.
• Orden en el que deben mostrarse a cocina.
• Comportamiento cuando una opción deja de estar disponible.

El POS debe recibir datos estructurados siempre que sea posible. Las notas libres pueden conservarse para solicitudes excepcionales, pero no deberían sustituir opciones que afectan al precio o a la preparación habitual.

Acordar estados y responsabilidades

Las plataformas y los POS no siempre utilizan los mismos estados. Aceptado, confirmado, en preparación, listo, recogido, cancelado y rechazado pueden tener significados distintos. Es necesario crear una tabla de equivalencias y definir qué sistema puede iniciar cada transición.

Por ejemplo, el POS podría confirmar automáticamente los pedidos válidos, mientras un encargado revisa los que incluyen un artículo no disponible. Una cancelación posterior a la preparación puede requerir intervención humana por su impacto operativo y económico.

La responsabilidad tampoco debe quedar en manos de un genérico equipo de tecnología. Es útil asignar propietarios concretos para:

• Menú y precios.
• Operación de sala o cocina.
• Relación con plataformas.
• Configuración del POS y de la integración.
• Gestión de incidencias y conciliación.

Cada excepción necesita una ruta de escalado: quién recibe el aviso, cuánto contexto obtiene y qué acciones puede realizar sin entrar en varios sistemas.

Incorporar controles y tratamiento de excepciones

El flujo principal debe ser determinista. Los códigos de producto, importes, impuestos, modificadores y estados se procesan mediante reglas verificables, no mediante una interpretación probabilística. La inteligencia artificial podría ayudar a clasificar notas libres o resumir incidencias, pero no debería decidir silenciosamente precios, sustituciones o cancelaciones.

Entre los controles útiles se encuentran la detección de pedidos duplicados, validación de totales, registro de eventos y reintentos seguros cuando un sistema no responde. Si la integración no puede crear un pedido, debe mostrar una alerta visible y conservar suficiente información para introducirlo manualmente sin pedir de nuevo los datos al cliente.

También conviene diseñar procedimientos para artículos agotados, modificadores desconocidos, diferencias de precio, pedidos recibidos fuera de horario y fallos de impresión o de pantalla en cocina. Una integración es más fiable cuando falla de forma visible y recuperable, no cuando oculta el problema.

Probar con pedidos representativos

Las pruebas deben cubrir más que el caso sencillo de un producto sin cambios. Prepare un catálogo de escenarios que incluya:

1. Productos simples, variantes y combos.
2. Modificadores obligatorios, múltiples y con suplemento.
3. Cupones, cargos, impuestos y propinas cuando correspondan.
4. Artículos agotados y cambios de disponibilidad.
5. Aceptaciones, rechazos y cancelaciones en diferentes momentos.
6. Interrupciones temporales, reintentos y pedidos duplicados.
7. Pedidos simultáneos y carga en horas punta.

Verifique el resultado en todos los puntos: plataforma, integración, POS, ticket o pantalla de cocina e informes. Las pruebas deben involucrar a las personas que operan el servicio, porque detectarán instrucciones ambiguas o secuencias poco prácticas que una revisión técnica puede pasar por alto.

Desplegar de forma gradual y medir

Un lanzamiento limitado reduce el alcance de los errores. Se puede comenzar con un establecimiento, una plataforma, una franja horaria controlada o una parte estable del menú. Durante esta fase debe existir un canal claro de soporte y un procedimiento temporal para volver al método anterior si el flujo se interrumpe.

Mida aspectos que ayuden a tomar decisiones: pedidos que entran sin intervención, errores de mapeo, duplicados, diferencias de importe, tiempo hasta la aceptación, cancelaciones relacionadas con disponibilidad e incidencias que requieren carga manual. Registre además la causa y la resolución; contar incidencias sin clasificarlas ofrece poca orientación para mejorar.

Antes de ampliar el despliegue, revise los resultados con operaciones, cocina, administración y tecnología. Corrija el catálogo, actualice procedimientos y confirme que los responsables pueden resolver las excepciones reales. Solo entonces incorpore más locales, plataformas o elementos complejos del menú.

Una buena integración no elimina la supervisión humana: evita transcripciones repetitivas y entrega mejores datos para que el equipo intervenga donde aporta criterio. Cibercoding puede ayudarle a revisar el flujo de pedidos y definir una primera integración limitada, controlable y medible.