示例演练. 这是一个说明性的示例演练，并非客户成果：客服团队及其数字都是假设。它展示坐席侧检索，一种放在客服坐席身后而不是客户面前的工具。坐席用日常语言提问，得到带出处的回答，留在工单里，并自己发送回复。
设想一个中型电商 CX 团队，希望改善复杂工单的首次响应时间。本文讲这个设计由什么组成、该衡量什么，以及它不做什么。它不报告任何结果，因为背后没有客户。
这个团队是假设的，你可能期待在这里看到的每个数字也是。该设计以我们在 /ai-for/customer-support 中描述的客户支持工作为基础。先说明一点：这只是辅助坐席。任何时候都没有聊天机器人与客户对话。
是什么拖慢了客服人员？
答案是存在的，只是查找无法规模化。一张复杂工单意味着坐席要打开 Zendesk 历史记录、一份产品文档和一份发货政策 PDF，再手工拼出答案。多年的历史工单里有先例，但没人能在客户等待的时间内检索这个档案库。
于是第一条回复就在队列里等着，客服人员在四处翻找。这段等待，正是客服负责人被追问的那个数字——首次响应时间，而不是工单量。
没有聊天机器人，AI 也能缩短客户支持的首次响应时间吗？
可以，这正是目标。内部检索工具让坐席用日常语言就历史工单、产品文档和政策 PDF 提问，得到一个带出处的回答。回复仍由坐席撰写并发送。团队会在上线前后衡量复杂工单的首次响应时间，没有面向客户的机器人。
这个设计由哪些部分组成？
一个覆盖三类来源的内部检索工具：历史工单、产品文档和发货政策 PDF。坐席像请教资深同事那样输入问题。回答连同出处一起返回，坐席可以在发给客户之前核对。
- 一次查询即可检索所有过往工单，而不是逐个标签页翻找。
- 回答附带出处，坐席核对来源，而不是信任一个黑盒。
- 回答以发货政策 PDF 为依据，边缘情况的规则正是写在那里。
- 坐席留在工单中。工具从不自行回复客户。
培训客服团队是设计的一部分，不是最后的交接。需要约定的 KPI 是复杂工单的首次响应时间，在上线前后衡量。它能带来多大变化，应由你自己的数据回答，而不是本文。
这和一个拦截型机器人有什么区别？
不是，这个区别正是关键。分流方案试图通过直接回答客户来降低工单量。这个设计瞄准的是另一个数字：首次响应时间，方法是把检索放在坐席身后。客户仍然是在和真人交谈。
We are
Stennir 构建的 AI 在你的客服人员背后运行：检索、分诊、起草-审核，用首次响应时间和解决质量来衡量。
We aren't
Stennir 不是面向客户的聊天机器人供应商，也不把拦截工单量当作卖点；客服人员留在工单里，你的客户始终在和真人对话。
Zendesk AI、intercom fin 或 gorgias 的建议这类工具，只在各自的围墙内工作：你的宏、帮助文章和已保存回复。这个设计把检索扩展到其余部分：历史工单、产品文档、发货政策 PDF、运维手册。复杂工单的答案就藏在那里。
我们推动的 KPI 是复杂工单的首次响应时间和解决质量，不是裁掉多少人头。这话我们第一天就说清楚，而且会去测量它。
这套方案适合我们的客服团队吗？
适配度测试很简单。你的答案是否已经存放在检索很慢的地方？多年的工单、一堆政策 PDF、不断变化的产品文档。如果坐席在每次复杂回复前都要花几分钟查找，检索要还给他们的就是这段时间。
这个设计属于我们的 AI 咨询工作，客服团队的培训则由我们的 AI 培训一侧融入其中。想看这些部分如何衔接，期刊里有更多这样的示例演练。
如果你的坐席在每次复杂回复前都在到处找答案，这个设计针对的就是这种延迟。告诉我们你在做什么，我们会告诉你检索是不是合适的杠杆。
