先说个让我脸红的事
2023 年 8 月 17 号下午，一个年付十二万多的客户在对接群里直接 @ 了我们老板。他们的工单在系统里躺了 19 小时 40 分钟，状态还停在「待分配」。合同上白纸黑字写的 P1 响应是 4 小时。老板把截图转到支持群的时候，我们 7 个人正在开周会，议题恰好是「如何提升客户满意度」。
我进后台查，工单是被自动规则分配给阿凯的。阿凯两周前离职，账号没停——HR 那边走的是月底统一停用，他 8 月 3 号走的，卡在中间。所以分配逻辑没报错，它认认真真地把工单派给了一个系统里还存在、现实中已经不在的人。
更讽刺的是我们的 SLA 报警配得特别全：P1 超 2 小时升级组长，超 4 小时推总监，超 8 小时推老板。一条都没响。因为报警的触发条件是「工单状态变更后开始计时」，而这张工单从建单到现在状态就没动过，压根没进入计时序列。
这事之后我对 SLA 这套东西的理解变了不少。下面这几个点，可能跟大部分讲工单管理的文章不太一样。
坑一：SLA 定得越细，响应反而越慢
我们最早的 SLA 长这样：
| 级别 | 定义 | 首次响应 | 解决 |
|---|---|---|---|
| P0 | 全量用户不可用 | 15 分钟 | 4 小时 |
| P1 | 核心功能不可用，无绕过方案 | 1 小时 | 8 小时 |
| P2 | 非核心功能异常，有绕过方案 | 4 小时 | 3 个工作日 |
| P3 | 咨询、优化建议、配置协助 | 8 小时 | 5 个工作日 |
这套表看着挺标准，抄的是 Atlassian 那套模板改的。配完头三个月数据很好看，到第四个月我发现不对劲：P1 的平均首次响应时间从 42 分钟涨到了 1 小时 52 分。工单量没变，人也没少，甚至还多招了一个。
我去翻群里的聊天记录才看明白，大家开始「卡点」了。以前看到工单顺手就回了，最慢也就十来分钟。现在心里有底——反正 SLA 给的是 1 小时，那我先把手上这个排查完再说。每个人都这么想，时间就顺理成章地贴到了上限附近。
后来我把 P2、P3 的响应时间直接合并成一档 4 小时，P1 从 1 小时改成 30 分钟。数值上更严了，但档位少了，人不用每次先判断「这单算哪一档」，反而快。
坑二：首次响应时间是个可以作弊的指标
我们自己试过。客服接待只要在工单里复制一句「您好，问题已收到，我们正在排查」，系统就判定为已响应。熟练的人 40 秒能刷完一张，一分钟能刷三张。
我见过一个同行，他们的首次响应时间是 6 分钟，漂亮得不行，但客户满意度只有 3.2 分（5 分制）。因为客户收到的那 6 分钟回复，和 6 小时后的实际解决方案，中间没有任何关系。
所以我把主 KPI 换成了两个：
- 重开率：工单关闭后 7 天内客户重新提起同一问题的比例。我们把它压在 8% 以下，超过 12% 就说明有人在糊弄。
- 知识库命中率：客户自助搜索后没有提交工单、或者提交工单时已经点过某篇文档的比例。这个数我们从 3% 慢慢做到了 21%。
首解率我也看，但不当主指标。因为我们产品有几个模块本身就很复杂，一单要转两三次是常态，硬压首解率只会逼着人把复杂问题拆成好几张单子关掉。
坑三：知识库不是写出来的，是被问出来的
这事我走过一次大弯路。2022 年我们花了两周，让每个人认领模块写文档，写了 68 篇，排版还挺好看。上线三个月后我拉后台数据，被真正打开过的有 11 篇，打开超过 5 次的有 3 篇。
后来换了个笨办法：每周五下午，我把这一周重复出现超过 3 次的工单标题拉出来，复制到 Excel，用数据透视表统计词频，人工去掉「无法」「报错」「请问」这些没用的词。剩下的前 10 个词，就是下周要写的文档标题。
按这个办法三个月写了 22 篇，平均每篇打开次数是 41 次。原因也简单——标题就是用户会搜的那句话，而不是我们自己觉得专业的说法。比如我们原来写的是《数据同步机制说明》，后来改成《同步任务一直显示进行中怎么办》。
我用过的六个工单系统，说点实在的
| 工具 | 我们实际用的套餐 | 价格（我查到时的，可能有变动） | 觉得好的地方 | 让我难受的地方 |
|---|---|---|---|---|
| Zendesk | Suite Team | 约 55 美元/坐席/月，年付 | 触发器、宏、SLA 策略做得最细，多品牌支持好 | 贵，坐席一多成本很吓人；中文界面有些地方像机翻 |
| Freshdesk | Free 转 Growth | Free 不限坐席；Growth 约 15 美元/坐席/月 | 免费版真的能用，小团队起步友好 | 免费版几乎没有报表，自动化规则数量有上限 |
| Jira Service Management | Free | 免费版 3 个坐席；Standard 约 20 美元/坐席/月 | 跟 Jira 研发打通，Bug 能直接转开发单 | 配置复杂，客户门户不好看，非技术客户不太愿意用 |
| 飞书服务台 | 跟飞书套餐绑定 | 按人/按版本 | 客户在飞书里直接提单，不用跳来跳去 | 报表弱，跨组织协作时权限配置绕 |
| Help Scout | Standard | 约 20 美元/坐席/月 | 界面干净，邮件式交互客户接受度高 | 中文支持一般，国内访问偶尔慢 |
| 网易七鱼 / 美洽 | —— | 按坐席加功能模块报价 | 国内合规、IM 体验好 | 定价要谈，模块拆得细，容易买多 |
我们最后是 JSM 免费版起家，客户量上来后换了 Zendesk。如果客户不是研发团队为主，我可能会选 Freshdesk。这个真没有标准答案，看你客户是谁、他们习惯在哪提问题。
如果让我重来一次
第一件事不是定 SLA，是修「孤儿工单」。 这是我用最土的办法解决的：
- 每天 9:30 跑一个定时任务，拉取所有状态不等于 Closed、且最后更新时间早于 4 小时前的工单；
- 把每张单的 assignee_id 拿去跟飞书通讯录 API 比对，不在在职名单里的直接标记；
- 剩下的按负责人分组，一个人手上超过 8 张未关闭工单的，也标出来；
- 结果推到支持群，@ 一下组长，当天必须清掉。
这个脚本大概 60 行 Python，写了半天。在那个客户出事之前，我们 SLA 报警做得再花哨也没用，因为最根本的「这单有人在管吗」都没解决。
第二件事是把工单标签从 40 个砍到 12 个。 我们早期让客服自由打标签，半年攒了 40 多个，什么「紧急」「比较急」「客户催了」都有，统计的时候完全没法用。后来定死 12 个分类标签，只能选一个，多选的功能直接关掉。
第三件事是每月做一次「无用工单」复盘。 把当月占比前 20% 的工单类型拉出来，问一句：这类问题能不能在产品里直接解决掉。我们靠这个推动产品改了 3 个地方，其中一个改完之后，相关工单量直接掉了七成多。
最后
说实话上面这些也没全解决。我们到现在 P2 工单的平均解决时间还是 4.5 天左右，超过合同里写的 3 个工作日。因为 P2 大多是「有绕过方案」的问题，客户不催，我们也不急。这个我还没想好怎么破，硬压时间只会让工程师糊弄过去，反而更糟。
如果你也在带支持团队，我的建议是别一上来就抄 Zendesk 或者 Atlassian 的 SLA 模板。那套东西是给几百上千人规模的支持中心设计的，你 5 个人的团队套上去，只会把精力全耗在维护流程本身。
先分清楚一件事：你的客户是等不了，还是不想等。前者靠排班和值班表，后者靠文档和自助入口。我们花了两年才把这两类分开看。
写到这儿想起来，阿凯那个账号我们后来停了，但分配规则改了三版才彻底避开离职人员。第一版用标签，第二版用成员组，都不行。最后就是一个每天跑一次的定时任务解决的，就是上面写的那段。