Flujo Order Bumped: el camarero confirma, la cocina cierra el ticket

Un steakhouse en Tribeca lo vivió: la cocina marcó un ribeye "listo", el ticket desapareció del KDS, pero el camarero tardó ocho minutos en llegar al pase. El plato se secó bajo la lámpara, el cliente se quejó y la cocina juraba que estaba perfecto. El patrón POS clásico no registra ese hueco porque el ticket ya se considera cerrado del lado de cocina.

Fallo del ticket clásico

Los flujos KDS habituales tienen tres estados: fired, preparing, ready. Cuando la cocina pulsa listo, el ticket desaparece y la responsabilidad pasa al camarero sin medirse. Tres casos límite se repiten: camarero en otra sala, dos camareros que esperan que el otro lo recoja, plato puesto en el estante equivocado del pase.

Patrón de confirmación del camarero

La solución: cuando la cocina marca listo, el ticket no desaparece. Cambia de color (verde a ámbar parpadeante) y envía un push a la tablet del camarero. El ticket sólo se cierra cuando el camarero pulsa "Recogido", registrando ID de dispositivo y timestamp. Tribeca redujo las quejas un 34% y el tiempo medio bajo lámpara cayó de 4,2 a 1,7 minutos.

Capa opcional: confirmación del cliente desde su móvil. Completa la cadena de evidencia, valiosísima en disputas.

Implementación

Bastan tres tipos de evento: kitchen_ready, server_picked_up, customer_acknowledged. Escalado a los 90 s y alarma crítica a los 180 s. Convertir el tiempo bajo lámpara en KPI semanal por camarero genera presión social positiva.

FAQ

¿Ralentiza la cocina? No, el flujo de cocina es idéntico.

¿Sin tablets? Sirven Apple Watch o un timbre con botón de confirmación.

¿Es obligatoria la confirmación del cliente? No, pero ayuda en disputas.

¿Te resultó útil? Compártelo.