一家驾校的校长找到我们时很无奈：六百多个学员，二十台教练车，约课全靠电话和微信群，教练的排班表每天改到眼花，学员还总投诉约不上。聊完我们告诉他，驾校的小程序开发，功夫七成在规则设计，三成才在写代码。
约课规则比页面重要
动手画页面之前，先把约课的规矩一条条定死：科目二每天开放几个时段、每个时段一台车最多带几人、学员能不能挑教练、练车和模拟考的时段要不要分开。这些规则每个驾校都不一样，照搬别家的系统多半水土不服。这家驾校的规则是每人每次约2小时、同车不超过3人、提前两天开放预约，我们把每条都写进需求文档，后来开发阶段没有为规则扯过一次皮。很多驾校做小程序开发失败，不是败在技术，是败在规则没想清就动工，结果系统和实际管理两张皮，用起来比手工还累。
取消和爽约要留口子
学员临时有事来不了是常态，规则不给口子，矛盾全堆到教练脸上。我们设的方案是：开课前6小时可以免费取消，6小时以内取消记一次爽约，爽约满3次冻结一周的约课资格。上线第一个月爽约率从两成多降到百分之七，教练的时间利用率明显上来了。规则公布前，校长在学员群里发了一周的说明和过渡提醒，执行阻力比预想小很多。规则本身不复杂，难的是敢不敢执行，校长带头执行，学员自然就守规矩。
考试前的插练单独处理
学员考前想加练，正常时段又约满了，这是驾校最常见的冲突。单独留了插练通道：教练可以开放自己的空闲时段，只允许7天内要考试的学员约，每次限1人。这个功能代码量不大，但把最焦虑的一批学员服务好了，口碑就起来了。
教练端和数据对账
- 教练端只保留三件事：看当日课表、给学员签到核销、开放插练时段
- 学员的练车学时自动累计，对接考试报名材料
- 后台按月出教练工作量报表，绩效核算不用再手数
- 学员端显示每个时段剩余名额，约不上的一眼可见
整个项目工期6周，费用4万出头。给同行的建议：约课规则先在纸上写清楚，拿给两三个教练和学员代表看一看，比直接看原型图更早发现问题。约课类小程序开发还有个隐藏好处：学员的练车记录都沉淀在系统里，学时证明、缴费凭证随时可查，家长问起来一键转发就行。比格网络做这类项目开工前都会带着校方把规则过一遍，规则定得越死，系统跑得越稳，这句话对任何有排班性质的行业都适用。
