Order Throttling: 厨房が過負荷のときに注文の流入を抑える

土曜21:30、厨房には未処理18件、シェフが「ストップ」と叫ぶ。それでもQR注文を受け続ければパスタは35分遅れ、Googleで星1のレビューが届きます。解決策がorder throttlingです。

キュー深度しきい値

厨房ごとに同時処理可能な上限があります。thMenuはオープン注文を数え、15件を超えるとQRメニューに「現在混雑中、5分後にお試しください」と表示します。カートは保持されます。

しきい値は可変です。ランチは12、ディナーは18。ピザステーションがボトルネックなら、カテゴリ単位のthrottlingも可能です。

ローマの事例:fila virtuale

トラステヴェレのDa Enzoでは2023年から仮想行列を導入。客は「現在の待ち時間12分、20:45にオーダー受付」と見て納得して同意します。期待値が先に共有されるためフラストレーションが出ません。

米国のDoorDashも「pause new orders」機能を提供し、調理時間が35分を超えたら15分間注文を停止できます。

技術とUXの実装

バックエンド: KDSが未処理件数をD1で保持。POST /api/ordersがチェックし、しきい値超過時は429 Too Many RequestsとRetry-After: 300を返します。クライアントは5分カウントダウン後に自動再試行します。

UXの鉄則: 待ち時間を隠さず魅力に変える。「今は混雑しています、すべて作り立てでお出しするためです」と伝えることで品質訴求に転換できます。

FAQ

売上は減りませんか?長期的には星1レビューの方が高くつきます。

最適なしきい値は?ステーションあたり3-5件、5ステーションなら18-25件が目安です。

客が離脱したら?カートは24時間保持され、再訪時に再開できます。

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