同一桌点了 12 分钟披萨和 4 分钟开胃菜,若同时开火,开胃菜要等八分钟才能与披萨同步上桌——已经凉透。解决方案是按算法错时下单。
算法原理
每个菜品都带有 cook_time 字段:披萨 12 分钟、开胃菜 4 分钟、主菜 8 分钟。订单将最长 cook_time 作为目标时间,反推其它菜品的开火时刻。
披萨在 t=0 下单,开胃菜在 t=8(12 − 4)下单。两者均在 t=12 完成,同步出餐而非各自为政。
Da Felice 案例
罗马 28 座经典 trattoria 于 2025 年秋启用 fan-out,平均"出票到上桌"时间从 31 分钟降到 23 分钟,降幅 26%,且未增加人手。
- 披萨炉闲置时间:-18%
- 菜品变凉投诉:-71%
- 每小时翻台率:1.4 → 1.8
实现细节
thMenu 中 cook_time 为可选字段。填写后 KDS 自动排程;留空则 ticket 在 t=0 触发,完全向后兼容。
站点容量也纳入考量:披萨炉同时四份,第五单等待三分钟。调度器了解队列深度。
FAQ
谁来填写 cook_time? 主厨或厨房主管在真实负荷下测量每个产品,通过 thMenu 后台录入。
高峰期还能用吗? 越是高峰越关键——实时队列深度纳入计算。
哪个套餐有? Platinum,与 KDS 和订单模块一起。
觉得有用?分享给朋友。