首次响应时间降低 40%，没有聊天机器人

客服侧检索. 一个在客服人员背后运行的工具，而不是摆在客户面前。客服人员用大白话提问，一次查询就能得到一个附来源的答案。没有面向客户的机器人，客服人员留在工单里，由自己发送回复。

我们为一家中型电商客服团队交付了这样一套工具。复杂工单的首次响应时间下降了 40%。这篇文章就是凭证：我们构建了什么、什么数字变了、什么没变。

客户信息已做匿名处理。40% 是这次项目交付的实际成果，对应我们在/ai-for/customer-support页面上描述的客服工作。再补充一点：这次只做了客服辅助，没有任何一个环节由聊天机器人和客户对话。

是什么拖慢了客服人员？

答案是存在的，只是找起来跟不上规模。一张复杂工单意味着客服人员要打开 Zendesk 历史记录、一份产品文档和一份物流政策 PDF，然后手动把答案拼出来。四年的历史工单里存着先例，但没人能在客户等待的这点时间里搜完四年的工单。

于是第一条回复就在队列里等着，客服人员在四处翻找。这段等待，正是客服负责人被追问的那个数字——首次响应时间，而不是工单量。

我们实际交付了什么？

一个内部检索工具，覆盖三个来源：4 年历史工单、产品文档、物流政策 PDF。客服人员输入问题的方式，就像在问一位资深同事。答案返回时会附上来源，客服人员可以在发给客户之前先核实一遍。

• 一次查询就能搜完 4 年的历史工单，不用一个标签页一个标签页地翻。
• 答案附来源，客服人员核实来源，而不是盲目相信一个黑箱。
• 答案立足于物流政策 PDF，边缘情况的规则真正就藏在那里。
• 客服人员留在工单里，这个工具从不会自行回复客户。

培训客服团队是构建工作的一部分，而不是最后交接了事。我们约定要推动的 KPI 是复杂工单的首次响应时间，我们测量了上线前后的数字，它下降了 40%。

这和一个拦截型机器人有什么区别？

不一样，而这个区别正是关键所在。拦截型方案想靠直接回答客户来降低工单量，而这次推动的是另一个数字。指标是首次响应时间，靠把检索工具放在客服人员背后来实现。客户从始至终都在和真人对话。

像 Zendesk AI、Intercom Fin 或 Gorgias suggestions 这样的工具，都在各自的围墙内工作：你的宏、你的帮助文档、你保存的回复模板。我们构建的检索覆盖的是剩下的部分——历史工单、产品文档、物流政策 PDF、操作手册。复杂工单的答案，就藏在那些地方。

我们推动的 KPI 是复杂工单的首次响应时间和解决质量，不是裁掉多少人头。这话我们第一天就说清楚，而且会去测量它。

这套方案适合我们的客服团队吗？

判断是否合适的方法很简单：你的答案是不是已经存在，只是查起来很慢——四年的工单、一摞政策 PDF、不断变化的产品文档？如果客服人员在每次复杂回复之前都要浪费几分钟去翻找，检索工具省下来的正是那几分钟。

这套系统属于我们咨询工作的一部分，客服团队的培训则来自我们培训业务。如果你想看看这些环节是怎么拼在一起的，日志里还有更多这样的凭证。

如果你的客服人员在每次复杂回复之前都要四处翻找答案，这正是我们在这里追求的那 40%。告诉我们你在做什么，我们会告诉你检索到底能不能帮上忙。