一、客户以为要做预约 App，实际问题是规则没有统一
项目开始时，客户的诉求很直接：想让会员在线约课，减少前台微信沟通。
在此之前，门店主要靠几种方式安排课程：
- 会员在微信群或私聊里预约；
- 前台用表格记录私教课和团课名额；
- 老师用自己的手机日历记排期；
- 会员卡类型靠收银系统和人工备注维护；
- 请假、取消、补课靠店长临时判断；
- 老会员的特殊承诺散落在聊天记录里。
门店最明显的痛点，是前台每天都在重复确认：
“这节课还有没有名额？”
“这个会员的卡能不能约这类课？”
“他取消算不算扣课？”
“请假以后能不能补？”
“老师这个时间到底空不空？”
如果只做一个预约入口，会员确实能在手机上点“预约”。但如果背后的规则不统一，前台还是要二次确认，老师还是会被临时改课打断，店长还是要不断处理争议。
所以这个项目的第一步，不是设计预约页面，而是把门店规则从人脑和聊天记录里提出来。
二、会员卡规则不清楚，预约系统一定会变成客服系统
健身和瑜伽门店的卡项很复杂。
常见的有：
- 次卡；
- 月卡；
- 季卡；
- 年卡；
- 私教课包；
- 小班课包；
- 团课通卡；
- 体验卡；
- 赠课；
- 冻结卡；
- 老会员特殊卡。
这些卡看起来只是商品，但在预约系统里，每一种卡都对应一组规则。
例如：
这张卡能不能约私教？能不能约团课？一次预约扣几次？过期后能不能延期？冻结期间能不能预约？赠课和正式课谁先扣？会员取消后要不要返还次数？老师请假导致取消怎么算？
如果这些规则不先定义，App 上线后每一次预约都可能变成客服问题。
这个项目里，我们先把卡项规则整理成几类：
- 可预约课程范围；
- 扣课方式；
- 有效期；
- 冻结和延期规则；
- 取消返还规则；
- 补课规则；
- 特殊审批规则。
整理完以后才发现，原来门店过去很多“灵活处理”其实都没有边界。前台凭经验处理，老员工知道，换新人就不知道；店长在的时候可以拍板，店长不在时就容易扯皮。
系统不是把灵活性完全消灭，而是要把哪些地方可以灵活、哪些地方必须统一写清楚。
三、私教排课的核心不是展示老师时间，而是避免时间和权益同时冲突
私教预约比团课更麻烦。
团课通常是固定时间、固定教室、固定容量。私教课更像一对一资源调度：老师、会员、教室或器械、会员卡余额、预约时间都要同时满足。
这个项目里，我们把私教预约拆成几个条件：
- 老师在这个时段是否可约；
- 会员卡是否支持这类课程；
- 会员剩余课时是否足够；
- 预约时间是否超过最晚预约时间；
- 当前时段是否和会员已有预约冲突；
- 老师是否已经被其他会员占用；
- 门店资源是否足够。
这听起来像技术判断，其实是业务规则。
如果系统只判断“老师日历空”，但不判断会员卡，就会出现会员约上了课，到了核销时才发现卡不能用。
如果只判断会员卡，但不判断老师真实排期，就会出现同一个老师被约到两个地方。
如果不判断取消窗口，会员临时取消以后，扣不扣课就会变成争议。
所以私教排课的第一版，必须把预约、取消、扣课、返还和老师确认放在同一条链路里，而不是把它们拆成几个互不相干的功能。
四、请假和补课规则不提前定，后期一定会变成运营黑洞
健身和瑜伽门店最容易低估的是请假和补课。
很多老板会觉得，请假不就是点一下吗？补课不就是再约一节吗？
但真实情况通常更复杂。
会员可能因为临时有事请假，老师可能因为排班调整取消，门店可能因为活动或节假日停课。不同原因对应不同处理方式：
- 会员在规定时间前取消，是否返还课次；
- 会员临近开课取消，是否扣课；
- 老师原因取消，是否自动返还；
- 门店原因停课，是否统一顺延；
- 病假或特殊情况是否需要店长审批；
- 补课是否必须在有效期内完成；
- 补课能否换老师或换门店。
如果这些规则不写清楚，App 上线后会出现一个很尴尬的结果：会员以为系统能处理，前台还得继续人工解释。
这个项目里，我们没有把所有边界都做成复杂自动化，而是采用了“常规自动处理 + 特殊人工审批”的方式。
常规情况由系统自动处理，比如提前取消返还课次、老师取消返还课次、课程容量释放。特殊情况走后台审批，比如病假延期、老会员承诺补课、门店临时停课批量处理。
这样既避免系统过度复杂，也避免所有事都压回人工。
五、会员端越简单，后台规则越要扎实
第一版会员端并没有做得很复杂。
会员端主要保留：
- 可预约课程；
- 老师和时间选择；
- 我的课程表；
- 我的会员卡；
- 预约记录；
- 取消或请假入口；
- 门店通知。
这些页面的视觉可以很轻，但背后规则不能轻。
后台要能配置课程、老师、时段、容量、卡项、扣课规则、取消规则、冻结规则、审批规则和通知模板。
前台要能处理会员查询、特殊审批、补课调整和异常记录。
老师端要能看到自己的课程安排、会员信息、上课状态和取消变更。
老板端要能看到课程利用率、老师排期、会员消课和异常处理。
如果只做会员端，不做后台规则，项目看起来像一个 App，实际还是靠前台在背后填坑。
六、为什么第一版不做太多营销功能
健身和瑜伽门店也很容易想做营销功能：
- 拼团；
- 秒杀；
- 分销；
- 打卡；
- 排行榜；
- 邀请有礼；
- 积分兑换；
- 会员成长体系。
这些功能能不能做？能。
但这个项目里，我们把它们放到了后面。
原因是预约和卡项规则没有跑稳之前，营销越强，后端压力越大。活动卖出去的卡越多，请假、取消、补课、延期和投诉也会跟着变多。如果系统还不能稳定处理基础规则，营销只会放大混乱。
更稳的做法是：
先把课程、卡项、预约、核销和异常处理跑通；再根据真实运营情况决定要不要做活动、裂变和积分。
对门店来说，第一版 App 的目标不是把所有会员都变成线上活跃用户，而是先让预约和消课这条主链路可信。
七、最后的结果，是门店规则从“靠人记”变成“系统可执行”
这个项目最后带来的价值，不只是会员可以自己约课。
更重要的是，门店开始把规则沉淀成系统能力。
前台不再需要每次翻聊天记录确认会员卡能不能用；老师能提前看到自己的排课变化；会员能看到自己的课包、预约和取消记录；店长处理特殊情况时，也能回到同一条记录上。
老板最关心的也不是页面多漂亮，而是几个关键问题终于能被系统回答：
- 课程容量有没有被超约；
- 老师时间有没有冲突；
- 会员课包消耗是否准确；
- 请假和补课有没有审批依据；
- 哪些课程经常被取消；
- 哪些卡项规则最容易产生争议。
这些问题解决以后，门店再去做营销活动，才不会把运营压力全部压给前台。
