先说个场景。去年有段时间，我每周三下午都会在支持群里看到同一句话：XX 系统登不上去，帮忙看下。数到第十几次之后我就不数了。那会儿我们团队的月报其实很漂亮——首次响应中位数 11 分钟，SLA 达成率 98.6%，CSAT 4.7 分（满分 5）。但我盯着那张表看了半天，突然觉得哪里不对：我们所有指标都在衡量「我们灭火有多快」，没有一个指标在衡量「火为什么一直烧」。
这个念头起来之后，我干的第一件事不是选工具，是拉数据。把过去 90 天全部 2347 张工单导出成 CSV，人工打标签，只打一层，不搞多级分类。打完发现密码重置和账号解封排第一，一个月 512 张，占总量 21.8%；VPN 连不上第二，388 张；开发环境变量配置第三，233 张。这三类加起来，吃掉我们团队将近一半人力。
顺带说下工具，这块坑挺多的，免得有人白花钱。
- Jira Service Management：免费版最多 3 个 agent，超过就得按人头买，Standard 一档每人每月二十几美元（年付），好处是工单和代码在同一个 issue 里，做根因修复时开发不用来回找截图。
- Zendesk：宏和触发器做得确实顺手，坐席培训成本低，但它本质上是围绕「沟通」设计的，想把工单和提交记录关联起来，中间层得自己搭。
- ServiceNow：功能最全，CMDB、变更、问题管理一套下来，落地周期通常按季度算，中小团队慎入。
工具选哪个真不是重点。重点是你有没有一条链路，能把「用户反复提问」这件事变成开发看得懂、排得进版本的 issue。我们当时的做法是三步，没有一步是新东西，但每步都有人偷懒跳过。
第一步，只治 Top 20，不做全量。我们有 300 多种工单标签，真要全治理得干到明年。当时就盯着前三类做。第二步，能自助的做自助：接了自助密码重置入口 + 强制 SSO，三个月后密码类工单掉到每月 60 张左右，降幅约 88%。第三步，支持团队改不了的，硬推给工程：VPN 那个最后查出来是客户端版本和服务端不匹配，升级客户端之后投诉量自己就下去了。支撑团队自己永远修不了这类问题，你得有办法把它推给能改代码的人，而不是靠每周在群里催。
半年之后的结果：重复性工单占比从 41% 降到 15% 上下，月总量从 2347 张降到 1400 出头。有意思的是首响时间反而变长了，从 11 分钟变成 14 分钟——因为简单工单被自助消化掉了，留在队列里的全是硬骨头，需要查日志、复现环境的那种。如果你的管理层只看首响这一个指标，这时候你大概率会被问话。
我知道下面这话说出来会得罪一批人：技术支持团队最该被考核的指标，可能不是解决率，也不是满意度，而是「这个月有多少问题根本不需要人来问」。响应快是服务能力，问题少才是产品能力。绝大多数公司把这两件事混在一起考核，结果就是支持团队拼命优化自己的响应速度，而真正该改的东西一直没人动。
当然这套逻辑有个前提，不然很容易走歪：你得能证明工单下降不是靠把用户晾着实现的。我们当时同步盯了一个反向指标，就是用户提交后没等到回复自己关掉的工单比例。这个数字要是涨了，说明你不是在治根，是在赶客。
另外补一句，别指望把重复工单降到 0。我们做到 15% 之后基本就卡住了，剩下的很多是那种一个月只出现两次、但每次都要查半天的边角问题，治理成本比收益还高。知道在哪停手，可能比一路猛冲更重要。