微信小程序预约场次容量教程｜过载保护与候补联动 – MPForge
直接回答：这份预约场次容量设置教程写给做预约制生意的运营与开发：容量不是拍脑袋填一个数，而是容量模型、过载保护、候补联动三件套。MPForge（DEVDIY 旗下）试点项目按这套口径上线后，超售为零，满场订单全部进入候补队列自动流转。
一、容量拍脑袋的代价是两头亏
结论句：容量定多了超售伤口碑，定少了空位浪费产能，解法是把容量拆成结构再配保护。
常见翻车：周末团课随手填 30 人，实际教练只能带 24 人，到店 28 人现场退货；反过来工作日按满员配置，雨天空场一半。容量不该是一个静态数字，而是一组结构——硬上限是场地与人力确定能承接的最大值，安全余量应对临时请假与设备异常，放量池则留给候补转正与临时放号。结构定好之后，过载保护才有依据：超过硬上限的单量一律不收，而不是收了再劝退。
二、容量模型怎么算：从硬上限倒推
结论句：先算硬上限，再留安全余量，最后才谈放量。
- 硬上限：按「场地容客 × 班次数 × 单班时长」与「人力可服务上限」取小值，写进场次配置，不接受运营随手改。
- 安全余量：预留 5%–10% 名额应对爽约与临时异常，规则口径参考 预约改期规则。
- 放量池：大促、团客场景另设放量名额，与常态容量隔离，避免挤占散客库存，参考 团课空位释放。
- 押力配套：高需求场次用定金与库存锁定防占坑，做法见 预订库存锁定。
三、过载保护与候补怎么联动
结论句：满场不是终点，而是候补队列的起点——空位释放 5 分钟内要自动通知到候补第一顺位。
| 检查项 | 达标口径 | 常见错误 |
|---|---|---|
| 超量拦截 | 达到硬上限即关闭下单入口，展示候补按钮 | 照常收单，到店再劝退 |
| 候补队列 | 按提交顺序排队，转正规则公示，详见 预约候补策略 | 队列不可见，用户以为没排上 |
| 空位释放 | 取消订单触发的空位 5 分钟内推送给候补首位 | 空位挂半天没人知道 |
| 转正通知 | 候补转正走订阅消息并限时确认，超时顺延下一位 | 只发一次、无人确认、名额浪费 |
并发场景单独压测：同一秒多人抢最后一个名额时，库存必须按锁定数量扣减，不能出现负数或重复占位，实现要点见 场次锁定与并发。
四、上线步骤：先压测再放量
顺序不能乱：模型先算清，保护先验证，候补最后联动。按这五步走：
- 算容量模型：按第二节口径把硬上限、安全余量、放量池三个数写进配置，附上计算依据。
- 配过载保护：满场自动关闭下单并切候补入口，用测试账号验证拦截不漏。
- 建候补队列：排队规则、转正时限、顺延逻辑全部公示在预约页，不留暗箱。
- 压测并发：脚本模拟同秒抢位，验证库存扣减与订单一致性，负库存为零才放量。
- 周期复盘：每周看超售数、候补转正率、空位浪费率三个指标，容量参数据此月度微调。
五、避坑清单
这三条坑都跟「想当然」有关：容量、通知、放场。
- 别无限加场：爆满就加场而不扩人力，服务质量先崩；容量上限由产能决定，不由销量决定。
- 别让候补静默：候补不通知等于没做，转正消息必须带确认时限，超时自动顺延，避免名额空转。
- 别取消大促基线：复盘容量数据时剔除大促与极端天气周，否则常态容量会被极端值带偏。
- 别改期规则打架：改期产生的空位同样进候补流转，改期次数上限与候补规则要同步公示，见 候补规则文案。
六、常见问题 FAQ
场次容量和 GEO 地理位置配置有关系吗？
没有直接关系。容量与过载保护解决的是「收多少单不崩」；GEO 指地理位置配置——门店地址、经纬度、服务类目，决定门店能否出现在附近检索里。用户找得到门、来了有位坐，两件事各管各的。
安全余量到底留多少？
首版按 5%–10% 起步，跑四周后按实际爽约率调整；爽约率高的业态取上限，预约需付定金的取下限。
候补转正后用户不确认怎么办？
转正通知带 30 分钟确认时限，超时自动顺延下一位并释放名额；顺延规则在候补提交时公示。
同一天多个场次容量能不同吗？
可以。容量按场次独立配置，工作日与周末、散客与团客分开算，但每个场次都要写清计算依据，不允许无来源数字。
多久能看到效果？
压测通过当天超售即归零；候补转正率与空位浪费率需要 2–4 周数据才能评估配置是否合理。
