不止放学,更是放学与离校的综合协同方案
同时覆盖班级或学生的放学、留堂状态,以及学生通过闸机、刷卡或人脸设备实际出校的确认;家长能够分清孩子已经开始放学,还是已经走出校门。
它不是单版本的附加项,而是同时回答两个关键问题
单版本通常从一个主要入口解决问题;当学校既关心班级或学生是否进入放学、留堂阶段,又关心学生是否真正走出校门时,应优先评估放学与离校综合协同方案。
单一入口通常只能回答其中一个问题:老师或门岗更新班级状态,说明班级已经进入放学、留堂或完成阶段;学生通过闸机、刷卡或人脸设备,才说明这名学生发生了实际出校事件。
协同方案把两类事件放进同一套任务、身份、权限、通知和操作记录链路。家长先知道班级进度,再知道自己孩子是否已经出校;学校也能分别查询班级操作和学生个人通行记录。
两次提醒不是重复播报,而是两个不同阶段的事实
| 阶段 | 学校侧触发 | 家长侧看到什么 | 系统记录 |
|---|---|---|---|
| 班级阶段 | 教师、门岗或授权人员执行全班放学、留堂或学生个人状态操作 | 班级开始放学,或指定学生放学、留堂 | 操作人、班级/学生范围、前后状态、通知结果 |
| 学生出校阶段 | 学生通过已接入的闸机、人脸设备或学生卡读卡器 | 该学生已发生出校事件 | 学生身份、设备、方向、时间、事件去重和通知结果 |
| 异常阶段 | 身份无法匹配、方向不明、重复刷卡、设备离线或通知失败 | 按学校规则不外发、延迟处理或转人工确认 | 失败原因、处置状态和可追溯日志 |
六种常见协同组合,可以按学校现有流程和设备选择
老师在小程序管理班级与学生状态,闸机确认学生实际出校
老师可以在授权范围内执行全班放学、全班留堂,也可以处理指定学生的放学或留堂。系统按学校已开通的通知规则,让家长先收到班级或个人状态提醒。
学生随后通过已接入的闸机出校,系统校验身份、通行方向、有效时段和重复事件后,再生成学生实际出校提醒。这样家长可以区分“班级开始放学”和“孩子已经走出校门”。
| 步骤 | 操作或事件 | 通知粒度 |
|---|---|---|
| 1 | 老师在小程序执行全班放学或全班留堂 | 班级层面 |
| 2 | 老师处理指定学生放学或留堂 | 学生个人状态 |
| 3 | 学生通过闸机离校 | 学生个人实际出校 |
| 4 | 学校后台查询班级操作、通行和通知结果 | 全过程追溯 |
老师在小程序管理班级或学生状态,学生刷卡确认是否已经离校
老师可以在小程序中执行全班放学、全班留堂,也可以处理指定学生的放学或留堂。家长先收到与班级或学生状态对应的提醒,清楚孩子已经进入哪一个放学阶段。
学生到达校门后使用本人学生卡刷卡,系统校验学生身份、读卡位置、进出方向、有效时段和重复事件,再形成实际离校记录或家长通知。该组合适合学校已有学生卡与读卡设备、暂不需要完整闸机通行控制,但希望进一步确认学生是否真正离校的场景。
| 步骤 | 操作或事件 | 家长可获知的信息 |
|---|---|---|
| 1 | 老师在小程序执行全班放学或全班留堂 | 班级当前放学阶段 |
| 2 | 老师处理指定学生放学或留堂 | 该学生的个人状态 |
| 3 | 学生在校门指定位置刷卡 | 该学生已发生实际离校事件 |
| 4 | 异常刷卡、重复刷卡或身份不匹配转后台处理 | 按学校规则通知或仅保留记录 |
门岗或值班人员负责班级调度,闸机负责学生个人出校确认
门卫、值班老师或校领导通过指挥端更新某个班级、多个班级或当前批次的放学状态,家长先收到班级进入放学阶段的通知。
学生自行刷卡或刷脸通过闸机后,系统再按学生身份生成个人出校记录和通知。该组合适合班级数量多、需要现场统一调度,同时又重视学生个人通行留痕的学校。
| 职责 | 负责入口 | 输出结果 |
|---|---|---|
| 班级调度 | 指挥端 | 班级/批次状态、大屏、播报和班级通知 |
| 个人出校 | 闸机或身份设备 | 学生出校记录和个人通知 |
| 异常核查 | 学校后台 | 未匹配、重复、失败通知和操作日志 |
老师刷卡触发班级放学,学生通过闸机触发个人出校通知
班主任或授权教师通过操作卡触发班级放学、留堂或完成,具体刷卡动作和有效时段按学校流程配置。班级状态变化可以同步到大屏、语音和家长通知。
学生随后通过已接入闸机出校,系统再记录个人通行并生成第二层提醒。老师端保持低学习成本,学生端保留明确的实际出校证据。
全校都采用刷卡入口,也能区分教师班级操作与学生个人出校
教师操作卡用于班级层面的放学、留堂或完成,学生卡用于学生个人出校。两类卡片必须通过身份类型、设备位置、有效时段和操作规则区分,不能把所有刷卡事件按同一种逻辑处理。
该组合适合已有读卡设备、希望减少移动端操作,同时需要班级进度与个人离校记录的学校。系统可按项目配置是否向家长发送两级通知,或只保留部分事件作为后台记录。
指挥端更新班级进度,学生自行刷卡确认出校
门岗或值班人员先通过指挥端更新班级或批次状态,家长收到班级层面的放学提醒;学生到达出口后自行刷卡,系统再生成个人出校记录与通知。
相比接入完整闸机,该组合可以基于已有学生卡和读卡设备评估实施,但仍需确认读卡位置、进出方向、重复事件、代刷风险和现场人工降级办法。
选择放学与离校协同方案时,先看谁负责班级状态,再看什么设备确认个人出校
| 学校条件 | 班级层面入口 | 个人出校入口 | 建议组合 |
|---|---|---|---|
| 老师需要精细处理全班和指定学生 | 小程序 | 闸机/人脸 | 小程序 + 闸机 |
| 老师需要精细操作且学校已有学生卡 | 小程序 | 学生卡 | 小程序 + 学生刷卡 |
| 门岗统一指挥多个班级或批次 | 指挥端 | 闸机/人脸 | 指挥版 + 闸机 |
| 老师希望保持刷卡操作习惯 | 教师操作卡 | 闸机/人脸 | 刷卡版 + 闸机 |
| 学校已有完整师生卡体系 | 教师操作卡 | 学生卡 | 教师刷卡 + 学生刷卡 |
| 现场统一调度且已有学生卡 | 指挥端 | 学生卡 | 指挥版 + 学生刷卡 |
协同方案需要先完成流程、身份、设备和通知四类核验
流程核验
明确班级开始放学、学生留堂、学生实际出校和撤销分别由谁触发,异常时由谁确认。
身份核验
统一教师、学生、班级、监护人、卡号、人脸和设备侧身份字段,避免事件找不到对应学生。
设备核验
确认接口协议、进出方向、设备位置、离线策略、重复事件和第三方厂商配合范围。
通知核验
确认哪些事件需要外发、发送给哪些监护人、使用何种渠道,以及失败、已读和重复通知如何处理。
数据与网络
纯内网、私有化或云端部署分别确认设备链路、外部通知出口、数据范围和运维责任。
验收口径
用学校真实流程验证班级通知、个人出校、留堂、撤销、代刷、重复事件和断网降级。
常见问题
什么是可视化放学系统的放学与离校协同方案?
放学与离校协同方案把班级或学生状态操作,与学生个人实际出校事件连接到同一业务平台。第一阶段可由小程序、指挥端或教师操作卡触发班级放学、留堂或完成;第二阶段由闸机、人脸、学生卡或 UHF-RFID 确认学生实际出校,并按学校配置形成记录或通知。
班级放学通知和学生实际出校通知有什么区别?
班级放学通知说明班级或指定学生已经进入放学、留堂或完成阶段,不等于孩子已经走出校门;学生实际出校通知来自经过身份、方向、时段和重复事件校验的闸机、刷卡或人脸事件。学校可以按流程选择两级通知,也可以让部分事件只保留为后台记录。
学校怎样选择放学与离校协同组合?
先确定谁负责更新班级状态:教师精细操作可选小程序,门岗统一调度可选指挥端,低学习成本可选教师刷卡;再确定什么设备确认个人出校:已有闸机或人脸设备可评估闸机接入,已有学生卡可评估学生刷卡。最后核验身份字段、设备协议、通知渠道、异常降级和验收用例。