Software para restaurantes con delivery propio: pedido, cocina y repartidor en un solo flujo

El restaurante conoce el pedido, cocina conoce la preparación y el driver conoce la ruta, pero esas tres historias suelen vivir en herramientas distintas. El error común es comprar una función por su nombre y descubrir después que no participa del flujo donde aparece el problema. Define entradas, estados y responsables antes de evaluar la pantalla. La función debe recibir contexto suficiente y devolver un resultado que el siguiente rol pueda usar.

La decisión central es sincronizar preparación y capacidad de reparto antes de prometer tiempos. Pruébala recorriendo Pedido → Preparación → Listo → Asignación → Ruta → Entrega y verificando que la información no cambie de identidad entre etapas. Cuando una persona necesita volver a escribir o reinterpretar lo que ya existía, la integración está trasladando complejidad en lugar de eliminarla.

Pon a prueba Dos drivers toman la misma orden, Pedido listo sin capacidad de retiro, Dirección corregida fuera del pedido. Cada caso debe tener un estado visible, una persona con autoridad para resolverlo y una consecuencia clara para el resto de la operación. Si la solución es “avisa por WhatsApp”, el sistema todavía no posee el contexto completo.

Después revisa Estado de cocina, Disponibilidad elegible, Asignación única, Seguimiento de entrega bajo volumen realista. El objetivo no es añadir más controles, sino que cada control aparezca en el momento correcto y reduzca incertidumbre para quien toma la siguiente decisión.

Pide ver el producto con datos representativos, no solo una presentación. Comprueba tiempos, permisos, mensajes de error y comportamiento cuando una dependencia no está disponible. Una captura demuestra apariencia; un caso completo demuestra capacidad operativa.

Antes de implementar registra cuánto trabajo consumen hoy Estado de cocina, Disponibilidad elegible, Asignación única, Seguimiento de entrega. Después repite la medición cuando el equipo ya domine el nuevo flujo. Así puedes distinguir una mejora real de una sensación de novedad y decidir con evidencia si la función merece seguir, cambiar de configuración o desaparecer.

Prueba “Estado de cocina” usando datos que se parezcan a los de un restaurante que opera delivery con repartidores propios. Empieza en pedido y continúa hasta preparación sin preparar el sistema para que todo salga perfecto. Cambia una condición a mitad del recorrido y revisa si “Disponibilidad elegible” sigue teniendo contexto. Incluye también el caso “Dos drivers toman la misma orden”: si la recuperación exige borrar la operación o crear una segunda versión, todavía existe una debilidad que debes resolver antes de depender del flujo.

Para evaluar “Disponibilidad elegible”, observa qué ve la persona que recibe el trabajo después de preparación. No basta con que el dato exista en algún menú; debe aparecer en el momento en que cambia una decisión. Contrástalo con “Asignación única” y documenta qué sucede ante “Pedido listo sin capacidad de retiro”. Una buena implementación deja una señal comprensible, una autoridad clara para corregir y un historial suficiente para que el siguiente turno no tenga que reconstruir lo ocurrido.

“Asignación única” merece una prueba de responsabilidad: quién puede modificarlo, quién solo lo consulta y qué parte del flujo se actualiza cuando cambia. Recorre Listo → Asignación con dos roles distintos y verifica que “Seguimiento de entrega” no dependa de permisos excesivos. Después provoca “Dirección corregida fuera del pedido”. Si la única forma de continuar es compartir credenciales, editar datos sin rastro o pedir a una persona concreta que intervenga, el proceso todavía no está preparado para crecer con seguridad.

Con “Seguimiento de entrega” conviene mirar escala y no solo funcionalidad. Repite Asignación → Ruta varias veces, mezcla operaciones normales con “Dos drivers toman la misma orden” y comprueba si “Estado de cocina” conserva velocidad y claridad. Pregunta además qué límite contractual, técnico o de configuración cambia con más volumen. El objetivo no es exigir capacidad infinita; es saber con anticipación cuándo la operación necesitará otro plan, más hardware o una configuración distinta para seguir siendo predecible.

Simula “Dos drivers toman la misma orden” durante pedido. La prueba termina solo cuando la operación llega otra vez a listo con un estado coherente. Revisa qué mensaje recibió el equipo, quién tuvo permiso para actuar y cómo quedó afectado “Disponibilidad elegible”. Esta disciplina evita aceptar una demo donde el error se resuelve reiniciando, borrando o corrigiendo directamente en base de datos: acciones que no representan una recuperación sostenible para un restaurante en producción.

Cuando ocurra “Pedido listo sin capacidad de retiro”, mide tiempo hasta detección y tiempo hasta resolución por separado. Un problema puede ser fácil de corregir pero difícil de descubrir, y esa demora puede contaminar preparación, asignación o “Asignación única”. Pide que el sistema muestre suficiente evidencia para distinguir causa de síntoma. Si todos ven que algo está mal pero nadie puede explicar por qué, el flujo todavía produce trabajo de investigación que debe formar parte de la evaluación.

Usa “Dirección corregida fuera del pedido” como prueba de cambio de turno. Una persona inicia el caso en listo y otra debe poder terminarlo en ruta sin una explicación verbal privada. Comprueba que “Seguimiento de entrega” conserve contexto, que las acciones sensibles tengan autor y que los comentarios necesarios queden junto a la operación. La continuidad entre personas es una señal fuerte de que el proceso vive en el sistema y no solamente en la memoria del equipo.

El reparto propio necesita distinguir presencia de disponibilidad. Un conductor puede estar conectado y aun así tener una entrega activa, encontrarse fuera de zona o haber aceptado otra orden. Durante la prueba, crea varios drivers con estados diferentes y observa quién aparece como elegible. Después haz que dos intenten tomar la misma orden. La asignación debe resolverse una sola vez y propagarse con rapidez para que el restaurante y los demás conductores dejen de actuar sobre una oportunidad que ya tiene responsable.

La búsqueda de repartidor debe coordinarse con cocina. Si se activa demasiado pronto, el driver espera; si se activa demasiado tarde, el pedido espera. No existe un minuto universal que funcione para todos los restaurantes. Pide ver qué señales puede usar el sistema: estado de preparación, tiempo esperado, carga de cocina o disponibilidad de red. La herramienta debe permitir ajustar la política sin esconder que se trata de una estimación y no de una reserva garantizada.

Las incidencias necesitan categorías que ayuden a mejorar. Cliente ausente, dirección incorrecta, demora de cocina, falta de driver y problema de ruta son causas distintas aunque todas terminen en una entrega tardía. Durante la demo registra una incidencia y comprueba si queda ligada al pedido, al conductor y al momento del ciclo. Si solo existe un campo de comentario al final, será difícil separar dónde invertir cuando revises tiempos semanas después.

Mide el ciclo por tramos: confirmado a listo, listo a recogido y recogido a entregado. Esta separación permite saber si el cuello de botella está en producción o reparto. Evita juzgar el software únicamente por un ETA total, porque dos pedidos con el mismo tiempo final pueden requerir soluciones completamente distintas. Un buen sistema de delivery hace visible esa diferencia y conserva datos suficientes para revisar la política sin culpar automáticamente al conductor.