跨班组通知规则表：按班次、岗位与紧急度分三级

跨班组通知常见的场面，是设备停了、质量异常发现了、系统断了，消息发在班组群里，当班的人没看到，下一班的人第二天才翻到；或者相反，一件小事 @所有人，电话、群公告、私聊一起上，真正紧急的事反而被淹没。问题通常不是消息发得少，而是没有一张写清楚“什么事、什么级别、什么班次、找哪个岗位、多久确认、没人接怎么办”的规则表。

跨班组通知规则表的作用，是把班次、岗位和紧急度放在同一张表里，让发通知的人不用每次凭感觉找人，让接收的人知道自己该在多长时间内回应。下面的三级做法适合有两个以上班次、多个岗位协作的制造、能源、物业、运维和客服团队，也可以按自己的组织规模删减。

三级怎么分：先看影响，再看时限

通知分级不是行业统一的固定模板，而是企业自己的管理口径。级别名称可以改，判定标准要落到可观察的事实上：有没有人身安全风险，影响一条线还是一个人，需不需要当班内解决。下面用 L1、L2、L3 表示一级、二级、三级。

级别	适用情形	通知强度	确认时限（起点）	升级方向
L1 紧急	人身伤害、火灾、危化品泄漏、整线停机、核心系统中断、批量质量事故	电话或语音 + IM 单聊 + 相关群同步	立即，5 分钟内	备班 → 值班经理 → 部门负责人
L2 重要	单台设备故障但可降级运行、局部缺料、质量偏差需隔离、交期风险	IM 单聊 + 相关群	15～30 分钟	班组长 → 值班经理
L3 常规	计划检修、参数微调、一般知会、班次摘要	群公告、讨论组或班次摘要	当班或下一班	不升级，纳入交接

拿不准时，用三个问题定级：

1. 是否有人身安全、消防、环保或设备重大损坏风险？
2. 是否影响整线生产、核心系统可用性或客户承诺？
3. 是否必须在当班内处理，拖到下一班会扩大影响？

第一个问题为“是”，按 L1 处理；第二或第三个为“是”，通常按 L2；三个都为“否”，按 L3。 级别由影响和时限决定，不由发送人的情绪决定。 涉及安全的事件先按 L1 发起，现场确认无风险后再降级，不要把“先观察一下”当成延迟通知的理由。

颜色可以帮助识别，但消息标题里要写清 L1、L2 或 L3。只靠红色、橙色、蓝色，色弱同事和打印出来的记录都容易丢信息。紧急通知不能只发群，L1 至少要有单聊或电话指向具体责任人。

一张规则表至少写清这 10 项

规则表不是事件清单，而是路由说明。每一行要能回答：什么事件、什么级别、哪个班次、先找谁、同步给谁、用什么方式、多久确认、没人接找谁、什么条件算关闭、留下什么记录。

字段	写法	常见问题
规则编号	N-01、N-02，按事件类别编号	用“设备那条”指代，过两周就找不到
事件与判定	设备停机超过 10 分钟；同一批次连续 3 件不合格	只写“设备异常”“质量不好”，无法判断是否触发
级别	L1、L2、L3	所有事件都写成“紧急”
适用班次	白班、夜班、交接窗口、节假日	只写“全员”，把下班的人也算进去
首发岗位	当班操作员、班组长、维修值班、质检	写具体人名，换班后规则失效
同步对象	产线群、接口人、值班经理	把“同步”当成“负责”，群里所有人都以为别人会处理
通知方式	电话、IM 单聊、群 @、公告	L3 也用电话，L1 只发群
确认时限	5 分钟、20 分钟、当班内	只写“尽快”，无法考核
升级路径	5 分钟未确认转备班；15 分钟未恢复转主管	只写“上报领导”，没写多久、找谁
关闭与记录	处理人、恢复时间、验证人、关联工单	消息说“已处理”，但没有验证和记录

岗位而不是人名，班次而不是全员，触发条件而不是感觉。 这三条决定了规则表能不能在换班、请假、调岗之后继续用。

这张表可以直接作为 Excel 或在线表格的列头。不要先急着上系统，先把规则写清，再决定哪些字段需要工具自动带出。如果通知还涉及跨部门发布权限、受众分层和留痕字段，可以把这张表与 跨部门通知流程图模板配合使用：那边解决“谁能发、发给谁、怎么留痕”，这张表解决“什么级别、什么班次、找哪个岗位、多久响应”。

可直接套用的三级规则表和示例

把字段填成行，规则表才有用。下面的示例以制造现场为主，物业、运维、客服可以把事件名称和岗位替换成自己的。表中的 10 分钟、3 件、20 分钟都是示例阈值，按企业自己的质量、安全和生产标准调整。

编号	事件与判定	级别	适用班次	首发岗位	同步与渠道	确认与升级	关闭与记录
N-01	人身伤害、火灾、危化品泄漏	L1	所有班次	发现人、当班班组长	电话应急联系人 + IM 单聊 + 应急群 + 值班经理	立即确认；3 分钟未确认转备班和值班经理；10 分钟未控制转厂级负责人	EHS 确认现场安全；记录时间线和处置人
N-02	整线停机或关键设备故障超过 10 分钟	L1	所有班次	当班操作员、维修值班	电话维修值班 + IM 单聊 + 产线群 + 生产主管	5 分钟确认；10 分钟未确认转维修主管；30 分钟未恢复转生产经理	维修与生产双确认；记录故障代码和恢复时间
N-03	单台设备异常但可降级运行	L2	所有班次	当班操作员	IM 单聊维修 + 产线群	20 分钟确认；40 分钟未确认转班组长	维修记录；下一班复查
N-04	同一批次连续 3 件不合格，或客户关键特性偏差	L1	所有班次	质检、当班班组长	IM 单聊质量接口人 + 质量群 + 生产主管	10 分钟确认；30 分钟未隔离转质量经理	隔离批次；质量放行记录
N-05	物料短缺影响当班计划	L2	白班、夜班	班组长	IM 单聊物料接口人 + 生产群	20 分钟确认；40 分钟未确认转生产主管	到货或替代方案；更新计划
N-06	计划检修、参数微调、一般知会	L3	所有班次	班组长	群公告或班次摘要	当班或下一班确认；不升级	交接班记录；不需要电话
N-07	交接班未闭环异常	L2	交接窗口	交班班组长	IM 单聊接班人 + 交接群	接班前确认；未确认转值班经理	接班人复述关键动作；交接表签字或回执

每条规则只回答一个事件，不要把多个事件塞进同一行。 先覆盖最近三个月重复出现的事件，通常 10～15 条就够跑起来，再按实际缺口补充。规则表太长、每条都写“视情况而定”，一线不会用。

班次维度：谁在岗、谁备份、交接窗口怎么算

班次维度的通知规则，核心不是把时间填进表里，而是明确“这个时段谁负责”。 班次不是时间段，是责任人的集合。 同一张规则表，白班和夜班的首发岗位、备班、升级对象可能不同；节假日和临时调班又要另算。只写“白班 8 点到 20 点”，不写这两个班次分别由谁负责，规则还是落不下去。

班次或时段	主值班岗位	备值班岗位	L1 升级对象	L2 升级对象
白班 08:00～20:00	产线班组长、维修当班	副班组长、维修备班	生产主管	车间主任
夜班 20:00～08:00	夜班班组长、维修值班	夜班副班组长、维修备班	值班经理	生产主管
交接窗口 19:30～20:30	交班和接班班组长	双方值班经理	值班经理	交班或接班班组长
节假日	值班经理	部门负责人	部门负责人	值班经理

主值班负责立即响应，备值班负责主值班未确认时的兜底。只排一个人，遇到洗澡、开会、手机没电或现场信号不好，通知就停在群里。主备要一起轮换，备班不能永远不响。没有专职值班经理的团队，可以把升级对象换成部门负责人或当班最高负责人，但要在表里写具体岗位，不要写“领导”。

交接窗口要单独写规则。L1 照常走电话和单聊；L2 需要接班人确认后才算移交；L3 进入下一班摘要，不在交接繁忙的半小时里发非紧急群公告。夜班人手少，L1 默认同时找主值班和备值班，L2 用 IM 加确认时限，L3 留到早班汇总。节假日和临时调班以当天排班表为准，不要用固定群成员代替当班人。

如果排班表不能自动同步到通知工具，至少每天班前会更新一条置顶的“今日值班”消息，写清主值班、备值班、升级对象和电话。这个动作看起来原始，但比“以为对方在看”可靠。

岗位维度：按责任路由，不按职级

岗位维度的通知路由，解决的是“这件事先找谁”，不是“谁职位高就发给谁”。把岗位职责写进规则表，换人时只换联系人，不改规则。

角色	在通知链中的职责	主要接收级别	备份
发现人、当班操作员	发起事件，写清现象、地点、影响和已做处置	L1、L2	同班同事
班组长	定级、确认、组织先期处置、决定是否升级	L1、L2	副班组长
值班经理或调度	跨班组协调、资源调配、对外通报	L1	部门负责人
维修、质量、EHS、IT	专业处置、给出恢复或放行结论	L1、L2	对应专业备班
部门负责人	重大事件决策、资源支持、对上报告	L1	分管领导
接口人	跨班组转达、确认执行、反馈进度	L2、L3	同部门指定人

每个岗位后面要有一张联系人小表：岗位名称、当班人、备班人、直接上级、电话、IM 账号、生效时间。这张表可以由班组长维护，也可以从排班系统同步；关键是换班、请假、调岗当天就要更新。

跨班组事项要指定接口人。接口人的职责不是把消息转发到另一个群，而是确认本班组谁执行、什么时候完成、卡在哪里。 接口人确认过，才算真正触达。 只在群里发一句“请各班注意”，通常等于没有发。

确认、升级与例外：让通知形成闭环

通知发出去只是开始。一条事件至少要有五个状态：已发送、已送达、已认领、处理中、已关闭。 认领不等于关闭。 有人回复“收到”只说明他看到了，不代表问题已经处理；关闭要有处理结果和验证人。

级别	首次确认	未确认升级	未恢复升级	关闭确认
L1	5 分钟内	5 分钟转备班或值班经理	15～30 分钟转部门负责人	专业负责人和值班经理
L2	15～30 分钟内	30 分钟转班组长或值班经理	2 小时转部门负责人	班组长
L3	当班或下一班	不升级	纳入交接班	班组长

这些时间是起点，不是统一标准。观测云的值班排班指南建议告警发出后 15 分钟内确认，并明确升级路径和交接笔记；Flashcat 的第一张值班表实践用 5 分钟、15 分钟、30 分钟三段升级。团队可以按事件风险调整，但要把“多久算超时、超时找谁”写进表里，不能只写“尽快”。安全类事件可以把首次确认压到 3 分钟。

升级不是重复发消息，而是换责任人、换通道。 主值班 5 分钟没确认，就转备班；备班也没接，再转值班经理。只在原群里再 @ 一次，通常不会改变结果。这套通知升级机制的核心，是让未确认的事件继续往上走，而不是停在原群里。

还有几类例外要提前写：

• 共因事件合并。一次停电导致一批设备同时离线，不要一台一条地发，合并成一条“某区域供电异常”的父事件，子事件只做记录。腾讯云开发者社区一篇工业 IoT 告警治理文章把这类情况归为共因群发，并建议先做去重、持续确认和组级收敛，再做分级路由。
• 计划检修静默。把检修窗口、设备范围和原因登记下来，窗口内 L3 和部分 L2 只记录不通知，L1 安全事件仍然送达。静默结束后要重新核对未恢复的告警，不能一静了之。
• 误报和抖动。同一事件短时间反复触发，先修阈值或加持续确认，不要靠值班人手动忽略。误报反复出现，规则表里的级别和触发条件就要改。
• 先发后补。L1 允许先打电话、先处置，事后 24 小时内补齐事件记录和定级说明。紧急不等于可以不记录。

交接班时，未闭环事件要跟着责任人走。交班人不能只说“已交接”，接班人要在接班前确认并复述关键动作；接班人未确认，交班人不能把责任交出去。交接窗口内双方都在群里，但责任转移以接班人确认为准。交接消息本身可以按 四段式写法组织：班次结论、异常与处理、待办与风险、接班确认。

工具承接：IM 负责送达和留痕，规则仍要自己定

规则表定好后，工具决定执行成本。企业即时通讯能承接群组、单聊、提醒、检索和部分机器人通知，但排班、工单状态和超时升级通常不在聊天工具里。

环节	IM 可以承接	仍需外部系统或制度
送达	群组、单聊、@、未读计数、提示音、小窗弹出、托盘闪烁、多端同步	事件触发和收件人计算
留痕	群消息、文件、图片、关键词和时间范围检索	正式工单、表单归档、审计导出
提醒	机器人消息、Webhook 推送	按班次自动路由、超时自动升级
排班	组织架构、讨论组	排班表、主备关系、临时调班同步
安全	私有化部署、通信全加密、组织隔离、IP 登录限制	版本能力核对、审计制度

以喧喧IM为例，它支持私有化部署，聊天、群组、文件传输、消息检索和多端同步可以承接通知的送达与回看；未读计数、提示音、小窗弹出和托盘闪烁能把提醒做得更明显；机器人、Webhook 和 API 可以把设备告警、工单状态推到指定群。具体能力可以看 即时聊天和 灵活扩展。

边界要说清楚：喧喧IM 不是流程引擎。 IM 能承接送达和留痕，不能替代排班、工单和升级引擎。 如果要把“当前班次是谁”“5 分钟未确认自动转备班”“处理结果回写工单”做成自动链路，需要用排班系统、工单系统、监控系统或 API/Webhook 集成，必要时做二次开发。上线前用真实班次验证，不要假设买了 IM 就自动具备这些能力。

对数据不能出企业的团队，私有化部署是前提。喧喧IM 的数据放在企业自己的服务器上，支持纯内网访问；具体部署方式和版本边界可以看 私有化部署。如果通知涉及生产参数、客户信息或工艺文件，正式记录仍应回到工单、MES 或表单系统，聊天记录只承担及时传达和现场取证。

两周试点：用五个指标验证规则表

规则表不要一上来全厂铺开。选一条交接频繁、异常较多、跨班组协作明显的产线或班次，跑两周。试点前先记一次基线，试点后用同一口径对比。

试点的顺序可以这样走：

1. 列出最近三个月重复发生的 10～15 个事件，按影响和时限定级。
2. 给每个事件填一行规则：触发条件、班次、首发岗位、同步对象、渠道、确认时限、升级路径、关闭条件。
3. 把主值班、备值班、接口人和升级对象做成联系人表，贴到班组看板。
4. 用真实场景演练：夜班设备停机、交接窗口未闭环异常、计划检修静默、共因群发。
5. 每周复盘一次，删掉没人用的字段，补上反复要问的信息。

指标	口径	看什么
L1、L2 确认率	规定时限内认领的事件占比	规则是否送到人、时限是否合理
平均确认时间	发出到认领的耗时	值班响应纪律
升级触发率	超时升级次数占总通知数	过高说明定级、排班或培训有问题
关键事件漏接、重复通知	漏接的 L1/L2 数、同一事件重复通知数	规则是否有盲区、是否需要合并
人均通知量	每个班次每人收到的通知数	是否出现新的通知疲劳

验收看关键事件是否在对的时间到对的人，不看群里发了多少条。 一条 L1 在 5 分钟内被正确的人认领，比 50 条“收到”更有价值；一条 L3 没有打断夜班，但进入了下一班摘要，也算成功。

规则表要有人负责维护。班次调整、岗位合并、产线改造、系统切换后，规则表都要更新版本；每季度抽查一次联系人表和升级路径是否还对得上。表上写的和实际做的对不上，通知就会重新回到“凭感觉找人”。

常见问题

三级不够用，要不要加到五级、七级？

先保持三级，把差异放进触发条件和时限里。例如 L2 里可以分“2A 需 15 分钟确认”和“2B 可当班处理”，但对外仍然叫 L2。级别太多，一线记不住，仍会回到“都发群里”。

夜班要不要所有通知都打电话？

不需要。L1 默认电话或语音，L2 用 IM 单聊加确认时限，L3 留到早班摘要。夜班人手少，L2 的确认时限可以比白班略长，但要有备班和升级对象。只有 L2 多次无人确认时，才考虑追加电话。

交接班时，通知应该发给交班人还是接班人？

事件在交接前由交班人负责，接班人确认后责任转移。交接窗口内两边都在相关群里，但规则表要写清“接班前确认、未确认转值班经理”。接班人只回“收到”不够，要复述关键动作或风险。

没有专职值班人员，怎么落地？

按班次指定主值班和备值班，不新增岗位。主值班由当班班组长或指定岗位兼任，备值班由副班组长或同专业备班担任；L3 用班次摘要，不追求 7×24 的即时响应。不要把人手不足伪装成全天候值班，否则升级路径会在关键时刻断掉。

怎样避免所有通知都变成 @所有人？

按事件或区域建群，按岗位 @，不要把全厂放在一个群里。L3 不发 @，L1 用单聊加电话，再同步到相关群；群公告只用于全员知会。规则表里写清“同步对象”和“责任人”的区别，能减少“所有人都以为别人会处理”。

工具能自动按班次通知吗？

聊天工具可以把消息送到群或个人，也能用机器人、Webhook 和 API 接收外部事件；但“当前班次是谁”“超时后自动升级给谁”通常要由排班、工单或监控系统计算，再通过接口触发。选型时用真实班次测试送达、认领、升级和关闭四个动作，不要只看演示。

参考资料

• 观测云，《值班排班怎么安排：7 步做出开发者不反感的 On-Call 表》，https://www.guance.com/learn/articles/on-call-scheduling（访问日期：2026-11-03）
• Flashcat，《如何配置第一张值班表和升级策略》，https://flashcat.cloud/blog/configure-first-on-call-schedule-escalation-policy/（访问日期：2026-11-03）
• 腾讯云开发者社区，《工业 IoT 告警治理实战：去重、抖动抑制与群发告警的收敛》，2026-08-28，https://developer.cloud.tencent.com/article/2733343