课程安排与学员权益分开
课程表描述老师、教室和上课时间，学员权益描述可预约的课程范围与剩余课时。两者需要关联，但不能把课程取消直接理解成权益作废。需求阶段应明确预约、签到还是课程完成时扣减课时，以及不同课程是否具有不同计量方式。余额展示要能解释每一笔变化，让学员和管理人员都能查到来源。
调课涉及多方资源
老师调整时间时，需要检查新时段的教室与人员安排，并通知受影响学员。学员发起调课则应按照业务规则确认能否取消原预约、是否释放名额以及是否保留原权益。系统保存原课程和新课程的对应关系，不建议直接修改历史预约的日期，否则容易看不出变更过程和当时的通知结果。
补课记录有独立来源
缺课后是否可以补课、有效期多长、可选择哪些课程，都应由业务政策决定。系统根据已确认结果建立补课权益，并记录来源课程，而不是直接给余额加一个无法解释的数字。补课再次取消或超期时，也要保存处理状态。涉及收费调整的情况，应明确操作权限和审核依据，避免课程调整顺便改变金额。
验收课表与余额共同变化
准备正常签到、提前取消、临时调课、缺课补课和教师停课五种情况，逐步核对名额、课表、通知与课时流水。测试同一学员重复预约和两名管理员同时改课，确认没有重复扣减。最后让学员从个人页面反查每笔课时变化，确保显示说明与后台实际动作可以对应。
方案落地前需要确认
本文以“课程预约系统”为主题讨论功能设计，属于方案指南，不代表某个客户项目的实际交付承诺。具体实施前，应由业务负责人确认适用规则、使用角色、现有系统接口和验收方式，再通过原型验证关键操作。对于暂时不能确定的条件，保留待确认清单，在范围明确后评估开发周期与费用，避免将示例直接套用于不同企业。