Fluxo Order Bumped: o garçom confirma, a cozinha fecha o ticket

Uma steakhouse em Tribeca viveu o caso: a cozinha marcou um ribeye como "pronto", o ticket KDS sumiu, mas o garçom levou oito minutos para chegar ao pass. O prato secou sob a lâmpada, o cliente reclamou, e a cozinha jurava que estava perfeito. O padrão POS clássico não registra esse vão porque o ticket já está fechado pelo lado da cozinha.

Falha do ticket clássico

Fluxos KDS comuns têm três estados: fired, preparing, ready. Quando a cozinha aperta ready, o ticket some e a responsabilidade vai silenciosamente para o garçom — sem medição. Três casos extremos recorrem: garçom em outra sala, dois garçons esperando que o outro pegue, prato posto na prateleira errada.

Padrão de confirmação

Quando a cozinha aperta ready, o ticket não desaparece. Muda de cor (verde para âmbar piscando) e envia push para o tablet do garçom. Só fecha quando o garçom toca "Retirado", com ID do dispositivo e timestamp logados. Tribeca viu queixas caírem 34% e tempo médio sob lâmpada cair de 4,2 para 1,7 min.

Camada opcional: confirmação do cliente pelo celular — completa a cadeia de evidência, valiosa em disputas.

Implementação

Bastam três eventos: kitchen_ready, server_picked_up, customer_acknowledged. Escalonamento a 90 s, alarme crítico a 180 s. Transformar tempo sob lâmpada em KPI semanal por garçom cria pressão social positiva.

FAQ

Isso atrasa a cozinha? Não, o fluxo de cozinha é idêntico.

Sem tablets? Apple Watch ou sineta com botão de confirmação funcionam.

Confirmação do cliente é obrigatória? Não, opcional mas útil em disputas.

Achou útil? Compartilhe.