当前位置：首页 > news >正文

ITSM 实战：如何识别“假推进”工单，并在超时前 30 分钟触发升级

news 2026/3/27 3:44:10

有一类工单，值班同学都见过。
群里一直有人回，系统里状态也在变：处理中、待协同、处理中、再处理中。看起来很忙，但 SLA 还是超了。

这类单子最麻烦的地方，不是没人跟，而是看起来在推进，实际上没往前走。我把它叫做“假推进工单”。

这篇只讲一件事：
怎么识别假推进，以及怎么在超时前 30 分钟，把它从“看起来有人管”拉回“真正往前走”。

一、什么是“假推进”工单

先说一个实用定义。

“假推进”不是指同事不负责，而是指工单在系统里有动作，但这些动作没有实质增量。常见表现：

状态反复变化，但没有新增排查结论
在组间来回转派，但上下文越来越薄
备注持续有“在看”，却没有“已排除项”和“下一步动作”

一句话：有流程动作，没有问题收敛。

二、为什么它最容易拖垮 SLA

很多团队盯 SLA，只盯是否超时。
但慢单通常不是最后 10 分钟突然变坏，而是中间 1 到 2 小时已经开始“发呆”。

真正耗时间的，不是修复动作本身，而是这三段隐性成本：

上下文重复补全
责任边界反复确认
下一步动作无人明确承诺时间点

所以你会看到一种很别扭的结果：
沟通记录很多，处理进展很少。

三、识别“假推进”的 3 个信号

建议把这 3 个信号直接配进 ITSM 规则里，不靠人盯。

信号 1：状态变了，但结论没变

满足以下任一条件即可判定风险：

连续 20 分钟内有状态变更，但无新增诊断结论
连续 2 次更新只包含“处理中/在跟进”，无技术事实

你要看的不是有没有更新，而是有没有新信息。

信号 2：发生转派，但没有交接上下文

发生转派时，若缺少以下关键字段，直接判定风险：

影响范围（单设备/整店/跨店）
已排除项（至少 2 条）
转派理由（为什么下一组更该接）

很多慢单就慢在这里：工单转过去了，判断没转过去。

信号 3：SLA 在走，处理链路没收敛

当工单剩余 SLA 小于等于 30 分钟，若同时出现以下任一情况，必须触发升级：

最近 15 分钟无实质更新
最近一次更新无下一步动作和预计完成时间
当前责任组未确认接单

这一步的核心是：
不是等超时后追责，而是超时前强制拉起。

四、“超时前 30 分钟升级”怎么落地

给你一套可以直接用的最小规则。

1）触发公式

触发时间 = SLA 截止时间 - 30 分钟
若工单 SLA 本身较短（如 30 分钟以内），改用比例阈值：
触发时间 = SLA 截止时间 - max(10 分钟, SLA 总时长 x 20%)

这样可以避免短 SLA 工单“还没处理就触发风暴”。

2）触发条件（建议同时满足）

剩余 SLA 到达阈值
工单命中任一“假推进信号”
当前状态不是“已解决/待确认”

3）升级路径（示例）

T-30 分钟：通知当前责任人 + 值班组长
T-20 分钟：通知二线负责人，要求 10 分钟内给出明确处置路径
T-10 分钟：通知服务经理，进入指挥态（明确 owner、完成时点、外部同步）

五、工单字段不补齐，规则就会失效

你可以先不做复杂自动化，先把这几个字段变成必填：

当前影响范围
已排除项
当前判断
下一步动作
预计下次更新时间（ETA）

很多团队以为问题在规则不够智能，其实第一坑是字段不完整。
没有结构化输入，就不会有稳定的升级判断。

六、可直接复制的“停滞升级备注模板”

下面这段可以直接放你们 ITSM 的升级备注模板里：

【停滞升级-自动触发】 工单号：{{ticket_id}} 当前优先级：{{priority}} SLA剩余：{{sla_remaining}} 1) 影响范围： - {{impact_scope}} 2) 已排除项（至少2条）： - {{excluded_item_1}} - {{excluded_item_2}} 3) 当前判断： - {{current_hypothesis}} 4) 下一步动作与负责人： - 动作：{{next_action}} - 负责人：{{owner}} - 预计更新时间：{{eta}} 5) 升级原因： - 命中信号：{{stall_signal}} - 最近{{x}}分钟无实质推进

这段模板的价值很直接：
后手接单的人，不用再从群聊里找上下文。