老师请假、学生请假和补课应该怎么在系统里处理?
培训机构里最常见的教务纠纷,往往不是排课排不出来,而是学员请了假,课时到底扣不扣、能不能补、补到哪个班。规则没提前写清,教务、老师和家长看到的余额就会不一致;补课排上了却没销课,又会变成一笔”教务债务”。
处理这类问题的核心,不是给后台加一个”请假”按钮,而是把“请假 → 课时处理 → 补课 → 销课”串成一条闭环链路。三条流程各自独立,又互相咬合:请假走”申请—审批”流,补课走”调停补课”流,学生请假还要配合销假。教育教学系统建设解决方案里把班级、排课、课表、签到、请假、补课和课时统计列为教务管理的核心项,正是因为这块直接关系课消和续费。
核心判断:请假不等于缺席,更不等于直接扣课时。系统要做的是先冻结、再判断、最后销课——任何课时变动都必须生成流水记录,由规则驱动,而不是由工作人员手动改余额。教育部关于校外培训治理和收费管理的公开文件也持续要求课程、收费和服务记录清晰可查,教育小程序中的请假、补课与课时扣减需要统一口径。
一、先定规则:六种请假类型,对应六种处理方式
不同类型的事假,对应的审核人、课时处理和补课资格都不一样。系统里至少要区分以下六种:
| 请假类型 | 课时处理 | 补课资格 |
|---|---|---|
| 学员事前请假 | 课时冻结,不扣减 | 开放可选补课时段 |
| 学员临时请假 | 按规则判断是否扣减(如是否临上课前若干小时) | 可申请补课,受当月次数限制 |
| 机构停课 | 不扣学员课时 | 由机构统一安排补课或顺延 |
| 学员无故缺席 | 按协议扣减课时 | 通常不具备免费补课资格 |
| 教师请假(调课) | 不扣学员课时,课次标记为”调课” | 已确定新时间,直接同步新课表 |
| 教师请假(停课) | 不扣学员课时,课次标记为”待调课” | 后续用”停补课”功能补回 |
这套区分的价值在于:扣不扣课时不再由班主任临时判断,而是由类型 + 规则自动决定,家长看到的余额和老师看到的记录天然一致。
二、学生请假:线上申请 → 审批 → 课时冻结 → 待补课登记
1. 学员端发起申请
家长或学员在系统端(小程序、APP 或 PC 端)提交请假申请,需要填写:
- 请假类型:事假、病假、公假等;
- 起止时间与对应的课程、课次;
- 请假事由;
- 证明材料:如医院诊断书、活动证明等,可按类型设置是否必传。
2. 审批与课时冻结
班主任或教务按规则审核。通过后系统做三件事:
- 把该次排课标记为“请假”状态;
- 暂停该课时的销课操作——课时冻结,而不是直接扣掉;
- 生成一条课时流水,记录变动类型、变动前后余额、操作人和规则依据。
规则建议:在系统里预设”提前多久请假不扣课时”和”每月请假次数上限”,在人性化和规范化之间取得平衡。比如提前 24 小时的事假不计课时、病假凭证明不计课时,每月累计不超过若干次。
3. 销假与补课登记
假期结束后,学员在系统内完成销假(通常需定位销假),未销假则无法发起下一次请假。同时,系统自动生成”待补课”待办,记录缺失课节与补课需求,进入补课流程。
三、老师请假:走”调停课”流程,而不是单独请假
教师请假必须走调停课流程,因为请假必然影响上课安排。单独一个”请假”按钮解决不了课表同步的问题。
| 环节 | 系统要做什么 |
|---|---|
| 提交申请 | 教师登录教务系统,进入”调停课申请”,选择课程与请假课次,填写变动原因(通常要求不少于 8 个字)。 |
| 选择类别 | 已确定补课时间选”调课”;暂时定不了时间选”停课”,后续再补。 |
| 审批流程 | 提交后由教学秘书审核,再分管教学负责人审批,最后教务备案。 |
| 课表同步 | 审批通过后,新课表自动同步到教师、学生和教室课表。 |
| 通知相关人员 | 自动通知相关学员与家长,涉及教室或多媒体变动还需通知后勤与电教。 |
| 课时处理 | 该教师对应时段的课程批量标记为”停课 / 待调课”,记录但不扣学生课时,避免家长跑空、老师空等。 |
涉及调课的,走”临时调课”功能,只调整当天课表,不影响后续固定课表的循环。这是教务系统里最容易出错的一个细节,也是教务管理模块是否好用的关键判断点之一。
四、补课:最容易积压的环节,也是最该自动化的环节
请假记录写完不等于业务闭环,补课没排上就是”教务债务”。系统里补课与教师请假紧密关联,通常作为调停课流程的一部分处理。
1. 补课申请的两种入口
- 由停课记录发起:若之前已申请”停课”并通过审核,需用”停补课”功能对该停课记录进行补课。
- 直接新增补课:教师选择”补课”类别,填写补课时间、地点、授课教师,直接增加上课时间。
2. 四个不能省的动作
| 动作 | 目的 |
|---|---|
| 冲突检查 | 系统自动判断补课时间是否有学生冲突;若冲突比例未超限可提交,但需关注冲突学生并安排线上学习或另行补课。 |
| 名额校验 | 补课名额要与班级容量和课程进度关联,避免插班补课后进度错乱,也避免超额。 |
| 审批与同步 | 补课申请经审核通过后,课程信息同步更新到教师课表、学生课表和教室课表。 |
| 补课标识 | 补课状态要在出勤记录里单独标识,方便教师和教务一眼看清”这节课是补的”,也便于后续对账。 |
3. 补课完成后的销课逻辑
补课安排完成后(插班补、单独补均可),销课逻辑重新激活:
- 系统确认该次补课已出勤;
- 按规则对该课时的冻结状态进行销课或核销;
- 生成新的课时流水,关闭这条”待补课”待办;
- 形成完整闭环,补课不再重复扣减学员课时。
建议设置学期末集中补课规则,在限定时间内统一消课,解决课消积压问题。若过期未补,系统按事先约定处理,不由工作人员直接修改余额。
五、数据怎么记录:一张表说清”课时到底去哪了”
所有课时变动都必须可查。这是教学系统与普通内容网站的另一个差别:它需要记录”学习过程”,而课时就是这个过程最直接的量化体现。
| 字段 | 说明 |
|---|---|
| 流水编号 | 全局唯一,可回溯到具体排课记录 |
| 学员 / 班级 | 变动对象,支持按班级批量生成 |
| 变动类型 | 正常销课 / 请假冻结 / 补课核销 / 调课顺延 / 机构停课 / 违约扣减 |
| 变动前后余额 | 快照式记录,便于对账与审计 |
| 关联单据 | 关联的请假单号、补课单号、审批记录 |
| 操作人 | 系统自动记录,禁止人工直接改余额 |
| 规则依据 | 注明依据哪条机构规则,如”提前 24 小时事假不计课时” |
有了这张流水表,教务、老师、家长三方看到的数字天然一致,也便于把数据接入招生与教学一体化的业务链:用户看到课程或招生内容 → 咨询留资 → 试听报名购买 → 建立学员档案 → 进入课程学习 → 作业考试教学服务 → 结课续费转介绍。课时余额本身就是续费提醒最有力的依据。
六、三类流程的完整状态机
学生请假:待提交 → 待审批 → 已批准(课时冻结)→ 待补课 → 补课完成(销课)→ 已销假
教师调课:待提交 → 待审核 → 已批准 → 新课表同步 → 通知学员与家长
教师停课与补课:停课申请 → 审核通过(课次标记”待调课”)→ 停补课申请 → 冲突检查 → 审核 → 课表同步 → 出勤后销课
七、系统选型与二次开发时,重点看这六项
| 考察项 | 必须确认的能力 |
|---|---|
| 排课与课表 | 是否支持临时调课不影响循环课表,是否支持班级、教师、教室三维冲突检测。 |
| 签到与出勤 | 出勤状态是否支持”正常 / 请假 / 缺席 / 补课”多状态,补课是否单独标识。 |
| 课时与余额 | 是否支持冻结与核销两种逻辑,是否有完整的课时流水与不可手工改余额的约束。 |
| 规则引擎 | 能否配置”提前请假不扣课时””每月次数上限””过期未补处理方式”等机构规则。 |
| 审批流 | 是否支持按角色、按时长分级审批,是否支持代提交、补录与紧急口头请假的后续手续。 |
| 通知与统计 | 请假、调课、补课是否自动推送学员与家长;是否提供课时统计、教学记录和待办清单。 |
如果机构已有成熟的会员、课程、订单能力,只是需要特殊的调停课和补课规则,那么“成熟系统 + 企业特殊业务二次开发”通常比从零开发更实际:直播、视频这类成熟能力不必重复开发,自己的排课规则和课时资产留在自己系统里。
八、需要避开的七个误区
- 请假直接扣课时。学员请了假课时照扣,是最容易引发退费纠纷的做法。
- 补课又重复扣减。补课名额和课时流水没有打通,导致学员补了课还被销课。
- 教务手工改余额。没有流水约束,余额改得越多,后期对账越乱。
- 请假、补课、销课做成三个孤立按钮。流程没有闭环,补课积压成为”教务债务”。
- 教师请假只记请假,不动课表。结果是家长跑空、老师空等,学员与教室资源同时浪费。
- 临时调课影响了后续循环排课。一次调课改动整个学期,教务需要逐条回滚。
- 没有学期末集中补课与过期规则。课消长期挂在账上,既影响收入确认,也让家长产生”课时去哪了”的疑问。
结语
老师请假、学生请假和补课,表面上是三个教务动作,背后其实是同一条链路:先冻结课时、按规则判断、再走补课、最后销课,每一步都留下流水记录。系统真正节省的,不是学生一分钟操作时间,而是减少教务人员每天重复登记、排课、通知和统计的工作,同时让课时这笔账清清楚楚。
教学系统不是把课程搬到网上,也不是简单增加一个直播功能。真正有价值的系统,应该围绕课程、学生、老师和教务,把报名、学习、作业、考试、教学服务和后续运营逐步连接起来。关于在线网校系统、课程系统、直播教学、录播课程、教务管理、排课系统、学员管理、教师管理、签到补课、课时统计、考试系统、题库系统、教育小程序、教育 APP、教学系统选型与二次开发的更多内容,可继续参考相关专题。
版权所有 © 2026 北京金雨科技有限公司 京ICP备2025146011号
本文由 李东旭 结合教育行业研究、互联网平台建设及数字化实践资料整理完成。
部分内容在整理过程中使用人工智能工具辅助进行资料归纳、结构梳理和文字表达优化, 但文章的选题、核心观点、经验判断及最终内容均由作者本人审核确认。 AI在这里主要作为内容整理工具,不替代实际经验与独立判断。
作者:
李东旭
|
个人博客:
lidongxu.com
运营主体:
北京金雨科技有限公司
|
官方网站:
金雨科技官网