排课冲突预警：教务少在开课前临时救火

这个案例来自 教育培训 场景，讲的是教务团队一件看起来只是排日程、实际上最怕临场出错的工作：
老师时间、教室资源、班级课表、试听插班和临时调休只要有一项没有同步清楚，排课就会从后台动作瞬间变成前台事故。

很多机构并不是不会排课，而是随着班型增多、老师增多、校区增多，冲突越来越难靠人工提前看见。

这个现场真正难在哪里

排课涉及的约束通常同时存在：

老师固定可授课时段
教室容量和设备要求
班级原有课表
试听课、补课、加课插入
节假日和老师请假变更

教务最熟悉的痛点往往不是“完全排不出来”，而是：

表面上排出来了，结果同一老师两边撞课
教室能用，但不适合这个班型
家长和学员已经收到上课通知，临时又要改
运营、班主任、授课老师看到的不是同一版安排

原来的处理链条为什么会卡

改造前，很多教育机构的排课还是 Excel、群消息和经验驱动。

典型链条通常是这样的：

教务先按学期课表排一版；
老师临时请假或校区活动占用教室后再改；
试听、补课和加课需求临时插入；
班主任再去逐个通知家长和老师。

旧流程最常见的卡点有这些：

1. 冲突往往是改动之后才暴露

初版排课没问题，不代表第 3 次微调以后还没问题。

2. 资源约束没有被一次性看全

老师、教室、班型要求往往分散在不同表里。

3. 通知动作总是滞后

安排改了，班主任和家长未必第一时间收到。

4. 教务大量时间花在“核对”和“确认”

真正费力的不是点一下排课，而是反复检查有没有撞。

改造前的旧流程简图

flowchart TB
    A[教务初版排课] --> B[老师请假、试听插班、教室占用等变化出现]
    B --> C[人工重新核对老师和教室]
    C --> D{是否发现冲突}
    D -->|是| E[临时改课并重新通知]
    D -->|否| F[继续沿用原排课]
    E --> G[家长、老师和班主任多头确认]

这条旧流程为什么总让教务在上课前几小时特别累

从项目复盘角度看，旧流程真正的问题不是教务不细心，而是“冲突检查、替代方案、通知同步”三件事都靠人工来回扫。

1. 小改动会引发连锁变化

一位老师请假，可能同时影响三个班和两个校区。

2. 试听和补课最容易插乱原课表

因为这类需求总是零散发生，最适合被提前预警。

3. 统一通知口径很难稳

只要班主任、老师和教务看到的版本不一致，就容易出错。

4. 冲突被发现得越晚，补救成本越高

越接近开课时间，越容易伤体验。

派宝怎么把多智能体放进去

派宝做的不是替教务拍板怎么排，而是把“先看资源约束、再做冲突预警、再给替代建议、再同步通知”这条链跑顺。

1. 多系统数据同步先把排课相关资源拉到一起

老师档期、教室状态、班级课表、试听和补课申请先放到同一张视图里。

2. 风险预警先把明显撞车的地方提前挑出来

不是等到开课前，而是在调整时就给出冲突提醒。

3. 排班建议先给教务一个更可落地的备选时段

遇到请假、调休和插班时，不用每次都从零重找。

4. 企业微信通知和短信消息发送把变更同步出去

改课以后，老师、班主任、家长能更快收到统一信息。

改造后的新流程详细图

flowchart TB
    A[老师档期、教室、班级和试听需求进入系统] --> B[多系统数据同步能力<br/>汇总排课约束]
    B --> C[风险预警能力<br/>识别老师、教室和班级冲突]
    C --> D[排班建议能力<br/>提供可替代时段]
    D --> E[教务确认排课调整]
    E --> F[企业微信通知 / 短信消息发送]
    F --> G[老师、班主任和家长同步收到更新]

上线前后到底差在哪

以 双校区、全职兼职老师混排、周课表变动频繁 的教培机构为例，连续运行 5 周后，最明显的变化不是排课总量减少了，而是教务终于不用在每天晚上反复做最后一轮人工排雷。

上线前后对比表

对比项	改造前	改造后
课表调整后的人工核对时间	较长	缩短约 58%
临近开课才发现老师或教室冲突	偶有发生	明显下降
调课通知触达时效	不稳定	明显提升
教务处理临时改课的压力	很大	明显缓解
家长对课程变更的混乱感	偏高	明显下降

为什么这些变化站得住

第一，冲突更早被看见，因为排课约束不再散在不同表格里。
第二，改课更快，因为系统先给出了可行备选时段。
第三，通知更稳，因为变更信息不再靠人工逐个传。
第四，教务更省力，真正省掉的是高频重复核对。

这个案例的价值

它抓住的是教培机构特别真实的一件事：
排课不是一次性工作，而是持续被打断和重排的过程。只要冲突能更早预警，教务团队的工作状态就会轻很多，家长和老师的体验也会稳很多。