教育 CRM 实施指南
教育机构 CRM 如何管理排课、调课与课消
排课、调课和课消不是三个孤立功能。实施时应先明确课程、班级、学员、教师、教室和校区的关系，再让每次变更与课消记录能够相互核对。
先统一排课涉及的数据关系
建立课程、班级、学员、教师、教室、校区和课次之间的关联，并为每类对象明确唯一标识。排课记录应指向具体课次，而不是只保存一段无法追溯的备注。
上线前可使用虚构数据创建一条完整链路，从课程和班级进入课次，再回查参课学员、授课教师与教室，确认各入口看到的是同一组关系。
把排课规则固化为可检查条件
先确认课程时长、开课周期、班级容量、教师可用时段、教室用途和校区营业时间，再决定哪些字段必须填写、哪些规则由系统提示。
不要把未确认的业务习惯直接写成自动规则。可先整理规则清单，由教务负责人逐项确认，再用正常和异常样例验证提示是否符合实际流程。
冲突检查不能只看教室
同一时段需要分别检查教师、教室、班级和学员的占用情况。多校区场景还要考虑教师跨校区移动所需的时间，避免两个校区的课程在时间上看似不重叠、实际无法衔接。
验收时应故意创建教师重复、教室重复和班级重复三类样例，确认系统能定位冲突对象，同时保留有权限人员的处理入口与操作记录。
调课、请假与补课要保留变更链
调课不应直接覆盖原记录。原时间、调整后时间、原因、操作人和确认状态需要保留；学员请假与补课也应关联原课次，避免课次、出勤和剩余课时各自变化。
可从原课次出发核对调课后的安排，再从补课记录返回原请假记录，确认变更前后都能查询，并且普通岗位不能删除必要的历史痕迹。
统一课消触发条件和计算口径
明确课消是在签到、下课确认还是教务审核后触发，并区分正常上课、请假、旷课、补课和课程取消的处理方式。任何自动计算都应能回到对应课次与规则。
验收时用不同出勤状态分别计算一次，核对单次扣减、剩余课时和课消明细是否一致；若需要人工修正，应记录修正前后数值、原因和操作人。
建立异常核对与责任边界
为未确认课次、负数课时、重复课消和调课未闭环等情况建立异常列表，指定教务、财务或校区负责人分别核对哪些项目。系统负责提供记录与提示，最终业务口径仍由机构确认。
上线初期可按日抽查课次、出勤和课消三组数据，记录差异原因。只有连续完成规定周期的核对并关闭异常，才进入稳定运行阶段。
排课与课消上线验收清单
- 课程、班级、学员、教师、教室、校区和课次均有明确关联与唯一标识。
- 排课必填项、容量、时长和可用时段规则已由业务负责人确认。
- 教师、教室、班级和学员的重复占用样例均完成冲突验证。
- 调课、请假和补课能够回查原记录、原因、操作人和处理状态。
- 不同出勤状态对应的课消规则已用虚构样例逐项核对。
- 课消明细、剩余课时和汇总结果能够互相校验。
- 人工修正保留修正前后数值、原因、时间和操作人。
- 异常列表已有负责人、处理时限和关闭条件。