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

キッチンが遅くなりませんか?いいえ、キッチンの流れは変わりません。

タブレットがない場合は?Apple Watch やパスのベルに確認ボタンを付ければ十分です。

客の確認は必須?任意ですが紛争時には極めて有用です。

お役に立ちましたか?シェアしてください。