结论先行：工单上显示「处理中」却还要打电话问，是因为工单状态和设备实际状态之间有四段断点：审批完成不等于开始排期、下发成功不等于设备生效、生效不等于被人验证过、验证过不等于已归档。这四段的信息都要靠人回填，人一忙就空着，于是问进度成了剩下的那条路。
本文只谈工单状态为什么和实际情况对不上、四个断点分别在哪、每个断点该挂什么回执，不谈催与被催这件事对团队情绪的影响，也不谈审批链本身该怎么设计。
先分清两个「状态」
很多人以为工单系统和设备之间是连着的，其实并不是。工单系统记录的是「流程走到哪」，设备记录的是「配置是什么样」。这两套记录各有各的更新节奏，中间靠人对齐。
一份变更走完全程，通常会经过这样的顺序：需求提出、影响评估、审批、排期、下发、生效、验证、归档。工单系统里能看到的是前四个和最后一个——因为这几个节点是人点的。中间的「下发成功」「生效」「验证」发生在设备侧，工单系统默认不知道。
于是就出现了那种熟悉的场面：工单上写着处理中，业务问「到哪了」，运维答「已经下去了」，业务再问「那为什么还访问不了」，运维说得上设备看一眼。三次对话，其实是在补三段信息。
断点其一：审批完成，不等于开始排期
审批通过那一刻，工单状态会跳到下一个节点，看起来事情在推进。但实际动作往往要等排期——尤其是变更窗口有限制的环境，一周只有那么一两个时间段能动。
这一段最容易被误读。业务看到「已审批」，心里的预期是「快了」；运维心里的预期是「排到窗口再说」。两个预期中间可能隔三五天，中间没有任何一处会告诉业务这件事。
可行的做法是给这一段一个明确的状态名，比如「已排期，窗口为某日某时段」。这一条改动很小，但它把「快了」这种模糊预期换成了具体日期。
断点其二：下发成功，不等于设备生效
这一段的坑在设备侧。命令推下去了，返回成功，看起来完成了。但在很多设备上，「配置已写」和「策略已生效」不是一回事：有的需要提交、有的需要重新加载、有的要等已有会话老化之后才按新规则走。
所以会出现「脚本说成功、业务说不通」这种看起来矛盾的情况。两边都没错，只是量的不是同一个时刻。
这一段能挂的回执是设备的配置摘要和规则版本。下发之后回读一次，把回读结果记到工单上。记录的内容不是「成功」两个字，是「当前生效的是哪一版」。
断点其三：生效了，不等于有人验证过
配置生效之后，还差一步：按业务的实际路径验一次。这一步在很多团队里是默认省略的，理由是「之前都是这么配的，肯定通」。
省略的代价是问题被推迟到业务发现。业务发现的时间点通常在业务高峰期，这时候处理成本比在窗口内处理高得多。
验证不一定要多复杂。一条最小集：从源端到目的端走一次真实路径、看一眼是否有命中记录、确认拒绝侧的表现符合预期。三步做完，把结果写成三个字段挂在工单上。以后有人问「当时验了吗」，翻得出来。
断点其四：验证过，不等于已归档
最后一段是关单。关单通常靠人手动点，而人最容易忘的就是这一步。结果是工单池里堆着一批实际已完成但状态未关的单子，统计口径随之失真——月度工单量、平均处理时长这些数字，都会被这批「幽灵单」拉偏。
这一段可以做成自动的：验证结果回填之后，工单自动进入待关单状态，超过一定时间无人处理则提醒。规则简单，但能省掉每月一次的清理。
三个信号，能看出断点在哪一段
信号其一：状态停留时长呈双峰分布。如果同一状态的停留时间既有几小时的也有好几天的，说明这一状态里混了两件不同的事，需要拆开。
信号其二：关单时间集中在月末或周末。这是典型的批量补点，说明关单动作没跟着实际完成时间走。
信号其三：工单数量与设备侧变更记录数量对不上。两个数差得越多，说明线下流转的比例越高，断点也越多。
想让它自己报进度，关键在挂什么
让工单自己报进度的思路并不新，难的是挂什么。挂人工勾选的清单，等于把回填的负担原样保留，只是换了个界面；这类改造上线三个月后会回到原点，因为大家会挑着勾。
真正管用的是挂设备回执：下发后自动回读一次配置摘要，验证步骤自动采集一次连通性结果，关单条件与回执是否齐套绑定。人只在两个地方出现——审批和异常处置。
做这件事之前有一个前置条件容易被忽略：得先有统一的资产标识。设备名称、管理地址、业务归属这三样如果在不同系统里写法不一致，回执挂上去也对不上号。这一项不解决，后面都是空转。
一个现实的做法
不必一次把四段全补齐。可以先挑业务感知最强的那一段——通常是断点其三，也就是验证。把验证结果挂到工单上，业务侧能看到「已验，某时某刻，结果如何」，问进度的电话会立刻少一批。
深圳市奇摩计算机有限公司在做网络自动化运维项目时，通常会把工单状态机和设备回执的对应关系先画成一张表，逐格标出哪些能自动、哪些只能人工。这张表画完，改造范围也就清楚了。需要评估自己这套流程的断点位置，可以预约咨询。