餐厅订座候补小程序｜宽限释放与桌型方案 – MPForge

一、典型场景：正餐订座候补最容易在哪几处翻车

正餐订座候补的痛点不在系统多复杂，而在桌台两本账、候补靠运气：

• 迟到空台：客人订了不来也不取消，桌台空等一小时，翻台全乱了。
• 候补靠运气：满座后想吃的客人在门口等，空出台面了也不知道叫谁。
• 桌型不分：大桌小桌一个口径，四人占了大圆桌，双人来了一批坐不下。
• 宽限没规则：等多久释放、释放前打不打电话，各班次各做各的。

二、方案总览：四步锁住每一张桌台

正餐订座候补的核心矛盾是桌台库存有限、爽约不可控。从客人提交订座到到店入座或转正，四个模块一条线走完：

1. 按桌型放库：大桌小桌分开计库，订一张锁一张，桌型错配从源头消失。
2. 宽限再释放：到点未到先宽限，超时自动释放回库存，桌台不整晚空着。
3. 候补即时转正：满座进候补，位次可见、释放即时通知，门口的客不白等。
4. 高峰可收定金：周末高峰档可配置定金，规则写进固定页，口头订座变订单。

规则取舍细节见 候补规则文案；同类项目可参考 订座未到案例。

三、核心功能清单

• 桌型库存：：大桌小桌分开计库，桌型与人数匹配校验。
• 宽限释放：：到点宽限、超时释放，桌台周转不空耗。
• 候补队列：：位次透明，空位释放即时通知转正。
• 定金可选：：高峰档定金规则进固定页，收与不收店方拍板。
• 到店核销：：到店按订单核销入座，爽约记录可统计。
• 公众号菜单导流：：订座入口可与公众号菜单导流配合，客人自助订座。

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

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

1. 进场准备：把桌型库存、宽限时长与定金档位逐项录入后台校对；宽限与候补规则先落成系统固定页。商家能感知的是订座不再靠本子。
2. 系统对接：订座、释放与候补打通，前台、领位与客人用同一条订座记录说话；对外只用正式版小程序码，体验版仅限内部验收。商家能感知的是空台率降下来。
3. 员工培训：一线只强调一分钟内完成锁桌、排候补、发提醒的主路径关键动作；店长学会看宽限与释放记录。商家能感知的是周末翻台顺了。
4. 灰度试点：先拿一家门店的周末晚市灰度试跑，不做数字考核，只看空台率、候补转正两条线动没动。商家能感知的是问题清单在收敛。
5. 值班应急：上线首周值班覆盖支付、核销、授权三类突发；弱网、拒权、支付取消三条路径必须进提审前用例。商家能感知的是突发有人接、有记录可查。

五、明确没做的事

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

• 不做外卖中台：外卖与配送履约不进首版，先把堂食订座闭环做实。
• 不担保到店率：宽限与候补管的是桌台周转，到店率本身受当天客流影响，不替餐厅担保。
• 效果按试点口径：「空台率下降」是试点前后对比的验收结果；复制到下一店前请重估桌型结构与客流。

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

口径：试点前后对比。验收结果：空台率下降；订座、宽限、释放、候补一条线走完，主路径关键动作 1 分钟内完成，门口等位的客不再白等。以上为作业口径，非全公司财报口径。

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

七、常见问题 FAQ