FUSION SOLUTION

融合方案:把班级放学与学生实际出校分成两级通知

先通知班级开始放学、留堂或完成,再由闸机、学生卡或人脸通行确认学生实际出校;家长更清楚孩子现在处于哪一步。

本页预览

融合方案:把班级放学与学生实际出校分成两级通知

先通知班级开始放学、留堂或完成,再由闸机、学生卡或人脸通行确认学生实际出校;家长更清楚孩子现在处于哪一步。

01第一层通知班级放学 / 留堂
02第二层通知学生实际出校
03可组合入口小程序 / 指挥 / 刷卡 / 闸机
01 / 方案定位

融合方案回答两个不同问题:班级开始放学了吗,孩子实际出校了吗

单一入口通常只能回答其中一个问题:老师或门岗更新班级状态,说明班级已经进入放学、留堂或完成阶段;学生通过闸机、刷卡或人脸设备,才说明这名学生发生了实际出校事件。

融合方案把两类事件放进同一套任务、身份、权限、通知和操作记录链路。家长先知道班级进度,再知道自己孩子是否已经出校;学校也能分别查询班级操作和学生个人通行记录。

02 / 两级通知

两次提醒不是重复播报,而是两个不同阶段的事实

阶段学校侧触发家长侧看到什么系统记录
班级阶段教师、门岗或授权人员执行全班放学、留堂或学生个人状态操作班级开始放学,或指定学生放学、留堂操作人、班级/学生范围、前后状态、通知结果
学生出校阶段学生通过已接入的闸机、人脸设备或学生卡读卡器该学生已发生出校事件学生身份、设备、方向、时间、事件去重和通知结果
异常阶段身份无法匹配、方向不明、重复刷卡、设备离线或通知失败按学校规则不外发、延迟处理或转人工确认失败原因、处置状态和可追溯日志
03 / 组合目录

五种常见融合方案,可以按学校现有流程和设备选择

04 / 小程序 + 闸机

老师在小程序管理班级与学生状态,闸机确认学生实际出校

老师可以在授权范围内执行全班放学、全班留堂,也可以处理指定学生的放学或留堂。系统按学校已开通的通知规则,让家长先收到班级或个人状态提醒。

学生随后通过已接入的闸机出校,系统校验身份、通行方向、有效时段和重复事件后,再生成学生实际出校提醒。这样家长可以区分“班级开始放学”和“孩子已经走出校门”。

步骤操作或事件通知粒度
1老师在小程序执行全班放学或全班留堂班级层面
2老师处理指定学生放学或留堂学生个人状态
3学生通过闸机离校学生个人实际出校
4学校后台查询班级操作、通行和通知结果全过程追溯
05 / 指挥版 + 闸机

门岗或值班人员负责班级调度,闸机负责学生个人出校确认

门卫、值班老师或校领导通过指挥端更新某个班级、多个班级或当前批次的放学状态,家长先收到班级进入放学阶段的通知。

学生自行刷卡或刷脸通过闸机后,系统再按学生身份生成个人出校记录和通知。该组合适合班级数量多、需要现场统一调度,同时又重视学生个人通行留痕的学校。

职责负责入口输出结果
班级调度指挥端班级/批次状态、大屏、播报和班级通知
个人出校闸机或身份设备学生出校记录和个人通知
异常核查学校后台未匹配、重复、失败通知和操作日志
06 / 刷卡版 + 闸机

老师刷卡触发班级放学,学生通过闸机触发个人出校通知

班主任或授权教师通过操作卡触发班级放学、留堂或完成,具体刷卡动作和有效时段按学校流程配置。班级状态变化可以同步到大屏、语音和家长通知。

学生随后通过已接入闸机出校,系统再记录个人通行并生成第二层提醒。老师端保持低学习成本,学生端保留明确的实际出校证据。

07 / 教师刷卡 + 学生刷卡

全校都采用刷卡入口,也能区分教师班级操作与学生个人出校

教师操作卡用于班级层面的放学、留堂或完成,学生卡用于学生个人出校。两类卡片必须通过身份类型、设备位置、有效时段和操作规则区分,不能把所有刷卡事件按同一种逻辑处理。

该组合适合已有读卡设备、希望减少移动端操作,同时需要班级进度与个人离校记录的学校。系统可按项目配置是否向家长发送两级通知,或只保留部分事件作为后台记录。

08 / 指挥版 + 学生刷卡

指挥端更新班级进度,学生自行刷卡确认出校

门岗或值班人员先通过指挥端更新班级或批次状态,家长收到班级层面的放学提醒;学生到达出口后自行刷卡,系统再生成个人出校记录与通知。

相比接入完整闸机,该组合可以基于已有学生卡和读卡设备评估实施,但仍需确认读卡位置、进出方向、重复事件、代刷风险和现场人工降级办法。

09 / 组合选择

选择融合方案时,先看谁负责班级状态,再看什么设备确认个人出校

学校条件班级层面入口个人出校入口建议组合
老师需要精细处理全班和指定学生小程序闸机/人脸小程序 + 闸机
门岗统一指挥多个班级或批次指挥端闸机/人脸指挥版 + 闸机
老师希望保持刷卡操作习惯教师操作卡闸机/人脸刷卡版 + 闸机
学校已有完整师生卡体系教师操作卡学生卡教师刷卡 + 学生刷卡
现场统一调度且已有学生卡指挥端学生卡指挥版 + 学生刷卡
10 / 实施边界

融合方案需要先完成流程、身份、设备和通知四类核验

流程核验

明确班级开始放学、学生留堂、学生实际出校和撤销分别由谁触发,异常时由谁确认。

身份核验

统一教师、学生、班级、监护人、卡号、人脸和设备侧身份字段,避免事件找不到对应学生。

设备核验

确认接口协议、进出方向、设备位置、离线策略、重复事件和第三方厂商配合范围。

通知核验

确认哪些事件需要外发、发送给哪些监护人、使用何种渠道,以及失败、已读和重复通知如何处理。

数据与网络

纯内网、私有化或云端部署分别确认设备链路、外部通知出口、数据范围和运维责任。

验收口径

用学校真实流程验证班级通知、个人出校、留堂、撤销、代刷、重复事件和断网降级。

FAQ

常见问题

什么是可视化放学系统融合方案?

融合方案把班级或学生状态操作,与学生个人实际出校事件连接到同一业务平台。第一阶段可由小程序、指挥端或教师操作卡触发班级放学、留堂或完成;第二阶段由闸机、人脸、学生卡或 UHF-RFID 确认学生实际出校,并按学校配置形成记录或通知。

班级放学通知和学生实际出校通知有什么区别?

班级放学通知说明班级或指定学生已经进入放学、留堂或完成阶段,不等于孩子已经走出校门;学生实际出校通知来自经过身份、方向、时段和重复事件校验的闸机、刷卡或人脸事件。学校可以按流程选择两级通知,也可以让部分事件只保留为后台记录。

学校怎样选择放学系统融合组合?

先确定谁负责更新班级状态:教师精细操作可选小程序,门岗统一调度可选指挥端,低学习成本可选教师刷卡;再确定什么设备确认个人出校:已有闸机或人脸设备可评估闸机接入,已有学生卡可评估学生刷卡。最后核验身份字段、设备协议、通知渠道、异常降级和验收用例。