驾校理论课小程序教程｜旷课自动释放名额与候补递补怎么做 – MPForge

一、场景与痛点：名额被旷课学员「睡走」了

结论先说：理论课最大的浪费不是教室空着，而是名额被占着——想上课的人进不来，占位的人不来也不吭声。

驾校理论课的典型节奏是：科目一集中排班，一场几十个名额，学员在小程序预约时选场次。问题是总有一批学员临时不来：有的忘了，有的以为不来没关系。结果就是到场人数低于名额数，而候补名单上还有人排着。更麻烦的是事后扯皮——学员说「我没收到提醒」，前台说「我们通知了」，谁也拿不出证据。

把这条链路拆开看，缺的其实是三件东西：明确的旷课判定时间点（开课后多少分钟未签到算旷课）、自动执行的释放动作（判旷课后名额立刻回到池子）、即时候补递补（候补第一位收到推送后能在截止时间内确认）。三件事都靠人做，必然漏；都做进系统，才稳定。

二、首版模块怎么拆：签到、释放、候补、提醒

四个模块各管一段，边界清楚了才不会互相扯皮。

这套结构对应站内的团课空位释放规则，思路一致：先保证履约环节可验，再谈运营动作。设计上刻意没做的是「人工慢慢找人来补」——前台一个个打电话既慢又不留痕，遇到客诉时也说不清谁在什么时候被通知过。

三、规则参数怎么定：三个必须写清的口径

参数不在多，在「说得清、查得到、改得动」。上线前这三条必须落到固定页：

1. 定旷课判定点：开课后 N 分钟未签到即判旷课，N 按校区通勤情况配置（城区店与郊区基地差别很大），写进预约页与确认短信。
2. 定释放与递补时限：名额释放后，候补第一位有 M 分钟确认窗口，超时自动顺延给下一位，避免名额卡在一个人手里。
3. 定次数限制：同一学员连续旷课达到设定次数后，限制其预约优先级或要求线下确认——次数规则可配，并在个人页公示。
4. 定公示位置：三条规则统一放在规则固定页，预约前必须可达，改规则时同步更新页面，不只在群里发通知。

这里的改期与释放规则页建议参照定金改期规则写法的口径：把「什么情况扣、什么情况免、多久生效」写成学员能看懂的白话，而不是后台才有的内部备注。

四、上线验收：一条链路跑通才算数

验收不看单点功能，看完整链路：占位、旷课、释放、递补、记录，一次跑通。

• 链路用例：造一个测试学员约满一场、不签到，确认 N 分钟后名额回池、候补第一位收到递补推送、超时顺延逻辑正确。
• 数据口径：统计空位利用率时写清分子分母与排除周（节假日单列），上线前后抽样对比，才敢说「升了」。
• 留痕检查：每次释放、递补、顺延都有日志，前台与学员各能查到对应记录，客诉时用同一订单号说话。

提审前把弱网、拒权、支付取消三条异常路径跑一遍，对照小程序审核被拒常见原因逐项检查；提醒推送的授权时机不要早于首次预约动作，避免用户一打开就弹窗拒权，参考隐私弹窗时机规范。

五、避坑清单

这三类坑在驾校项目里反复出现，都和「规则没有进系统」有关：

• 规则口头化：旷课判定、次数限制只在接待口头讲，学员不认账；必须落成固定页，预约时可见。
• 提醒时机过早：还没预约就请求订阅消息授权，拒权率高还伤体验；授权跟着动作走。
• 主数据双记账：教务系统和小程序各记一套出勤，月底对不上；以签到流水为唯一事实源，教务侧只读同步。
• 候补无时限：递补没有确认窗口，名额卡在第一个人身上，白白空放一场。

六、常见问题 FAQ