Order Bumped 워크플로우: 서버 확인 후 주방이 티켓을 닫는다

Tribeca의 한 스테이크하우스에서 실제로 있었던 일: 라인 쿡이 립아이를 "ready"로 표시했고 KDS 티켓은 사라졌지만, 서버가 패스에 도착하기까지 8분이 걸렸다. 접시는 히트램프 아래에서 말랐고 손님은 불평했으며 주방은 "음식은 완벽했다"고 주장했다. 전통적인 POS 패턴은 이 공백을 전혀 기록하지 않는다 — 주방 측에서 이미 티켓이 닫혔기 때문이다.

전통 티켓 흐름의 약점

일반적인 KDS 플로우는 fired, preparing, ready의 세 상태를 가진다. 주방이 ready를 누르는 순간 티켓이 사라지고 책임은 조용히 서버에게 넘어간다 — 측정되지 않은 채로. 세 가지 엣지 케이스가 반복된다: 서버가 다른 홀에 있음, 두 서버가 서로 가져갈 거라 가정함, 음식이 잘못된 선반에 놓임.

서버 확인 패턴

주방이 ready를 눌러도 티켓은 사라지지 않는다. 색만 바뀌고(녹색에서 깜빡이는 호박색) 서버 태블릿으로 푸시가 간다. 서버가 "수령" 탭을 누를 때 비로소 티켓이 닫힌다 — 기기 ID와 타임스탬프가 기록된다. Tribeca는 이를 도입하고 불만이 34% 감소, 램프 아래 시간 중앙값이 4.2분에서 1.7분으로 줄었다.

선택 계층: 손님의 스마트폰에서 "도착" 확인. 증거 사슬을 완성해 분쟁 시 매우 유용하다.

구현

이벤트 세 종류면 충분하다: kitchen_ready, server_picked_up, customer_acknowledged. 90초에 에스컬레이션, 180초에 매니저 대시보드 긴급 알람. 램프 시간 데이터를 서버별 주간 KPI로 만들면 건전한 동료 압력으로 중앙값이 움직인다.

FAQ

주방을 느리게 하나요? 아니요, 주방 흐름은 동일합니다.

태블릿이 없는 경우? 애플워치나 확인 버튼이 있는 패스벨로도 가능합니다.

손님 확인이 필수인가요? 선택이지만 분쟁 시 매우 가치 있습니다.

도움이 되셨나요? 공유해 주세요.