火锅店扫码点餐小程序｜桌台口味与出餐方案 – MPForge

一、典型场景：火锅桌台扫码点餐最容易在哪几处翻车

火锅桌台扫码点餐的痛点不在系统多复杂，而在口味各说各话、出餐看不到：

• 口味漏记：辣度、忌口靠服务员口头转达，后厨按默认做，锅底一上就起争执。
• 加菜没轨迹：中途加菜喊一声，哪桌加的、做没做到桌上，客人服务员两头懵。
• 错单难追：桌号贴错、菜品上错，高峰期一张小票对半天，结账时再扯一轮。
• 催单无凭据：客人催菜只能喊服务员，厨做到哪一步谁也说不清。

二、方案总览：四步锁住每一桌的点单

火锅桌台扫码点餐的核心矛盾是规格多、加菜频、出餐依赖口头。从客人扫码开台到出餐上桌结账，四个模块一条线走完：

1. 扫码开台：桌码一桌一码，客人落座扫码点餐，桌号绑死在码上，换桌即失效。
2. 必选确认：锅底辣度、忌口设为必选项，不选不能提交，口味偏好写进订单。
3. 加菜留痕：中途加菜自己加，加菜轨迹与首单同链，哪桌加的、几点做的可回查。
4. 出餐可查：后厨出餐状态实时回传，上菜到哪一步客人自己看得到，催单有凭据。

规则取舍细节见 桌码印刷规范；同类项目可参考 火锅扫码点餐案例。

三、核心功能清单

• 一桌一码：：桌码按桌台绑定，错台下单在源头被拦住。
• SKU 必选：：规格、辣度、忌口必选确认，不选不能下单，口味纠纷从源头消失。
• 加菜轨迹：：加菜与首单同订单链，厨打、出餐状态同一张屏可见。
• 出餐状态屏：：后厨出餐即打即传，服务员按屏上菜不喊单。
• 支付结账：：订单、加菜、支付同一订单号打通，结账不再逐笔核对。
• 公众号菜单导流：：等位与点餐入口可与公众号菜单导流配合，到店即点。

四、落地实施过程：五步上线

方案逻辑四步，落地拆成五个动作，前一步跑顺再进下一步：

1. 进场准备：把菜单结构、规格必选项与桌台编号逐项录入后台校对；桌码物料按印刷规范定稿再上桌。商家能感知的是贴错桌的小票从抽检里消失。
2. 系统对接：点餐、厨打与出餐屏打通，服务员、后厨与收银用同一张订单说话；对外只用正式版小程序码，体验版仅限内部验收。商家能感知的是催单不再靠喊。
3. 员工培训：一线只强调一分钟内完成引导扫码、提交首单的主路径关键动作；店长学会看出餐屏与异常单。商家能感知的是晚市不用满场跑。
4. 灰度试点：先拿一家门店的晚市灰度试跑，不做数字考核，只看错单有没有压到约定阈值、桌码抽检贴错有没有归零。商家能感知的是问题清单在收敛。
5. 值班应急：上线首周值班覆盖支付、核销、授权三类突发；弱网、拒权、支付取消三条路径必须进提审前用例。商家能感知的是突发有人接、有记录可查。

五、明确没做的事

说清楚不做什么，比堆功能更重要：

• 不做外卖与直播：外卖中台、直播带货、复杂营销引擎一律不进首版，先把堂食点餐闭环做扎实。
• 不替店方定口味标准：必选项给到客人自己确认，口味标准由客人点单时锁定，店方不替客人做主。
• 效果按试点口径：「错单低于约定阈值」是试点前后对比的验收结果，不是全公司财报；复制到下一店前请重估出餐动线与桌台数。

六、上线后效果（试点口径）

口径：试点前后对比。验收结果：错单低于约定阈值；开台、点餐、加菜、出餐一条线走完，主路径关键动作 1 分钟内完成，高峰晚市结账不再逐笔扯皮。以上为作业口径，非全公司财报口径。

复盘沉淀：把可勾选验收句写进开工单，避免「上线了」代替「指标达线了」；数据对比写清分子分母与排除周。

七、常见问题 FAQ