什么是工单分流？公式、算例与可信的分流率

什么是工单分流？

工单分流（ticket deflection）指客户在产生工单之前，通过自助渠道——FAQ 页面、知识库文章、聊天机器人或 AI 回答——自行解决支持需求。Zendesk 的定义是：用 AI 聊天机器人、社区论坛、FAQ、知识库等自助资源来减少支持工单的数量。计数的单位是「支持意图」：一个问题、一个诉求。如果它在没有坐席介入的情况下被解决，就算被分流了。

这个概念也有别的叫法：case deflection（案例分流）、call deflection（来电分流，避免的是电话接触），或统称支持分流。团队关注它，是因为被分流的需求不会进入队列：不占处理时长、客户不用排队、也不产生坐席成本。风险在于「没建工单」不等于「问题解决了」，下文专门讲这一点。

工单分流率公式与算例

常见口径按意图计数：

工单分流率 = 未产生工单即解决的意图数 ÷ 支持意图总数 × 100（以百分比表示）

各家的分母并不一样，比较数字前先看清口径：

• Freshchat 的机器人 KPI 文档用工单量变化举例：每月 1,000 个由坐席处理的工单，上线机器人后降到 500 个，分流率即 50%。
• Intercom 的 Fin 指标按会话计：解决率是 Fin 参与并解决的会话占 Fin 参与会话的比例。
• Zendesk 的 ticket deflection rate（即 self-service score）是比率而不是百分比：帮助中心用户总数 ÷ 工单用户总数。每 4 个自助用户对应 1 个工单用户，得分就是 4。

算例——示例数据。某网站一个月记录到 1,000 个支持意图，其中 420 个由 FAQ、知识库和 AI 回答解决，全程没有创建会话，其余变成工单。

42% 是表面数字。报出去之前，先做下一节的两个核查。

分流掉不等于解决了：让数字可信

访客看完答案、默默放弃、转身离开，在统计里同样是「没建工单」。这是假分流，会把分流率推高。两个核查能让数字可信。

重复联系核查。 固定一个回溯窗口——本例用 7 天——找出被分流后又回来、就同一问题开工单的访客。示例数据中，420 个里有 63 个这样做：

确认分流率 = (420 − 63) ÷ 1,000 = 357 ÷ 1,000 = 35.7%

表面的 42% 虚高了 6.3 个百分点。匹配要按「同一问题」，不能只看同一个人：回来问的是另一件事，属于新意图，不算分流失败。

满意度抽查。 在自助回答后向一部分被分流访客发满意度调查。示例数据：120 人回复，102 人表示问题得到满意解决，102 ÷ 120 = 85%。分流率上升、满意度下降，说明用户是被卡住了，而不是被帮到了。

窗口和分母要逐月固定，表面分流率和确认分流率一起报，让差距始终可见。

怎样提高工单分流

四个抓手，大致按投入从小到大：

1. 用真实工单建知识库。 从队列里挖反复出现的问题，一个问题写一篇清楚的答案。内容对得上客户真正问的问题，分流才成立；过时、空泛的文章会把人直接送回队列。
2. 把高频问题置顶成 FAQ。 在网站和聊天窗口放一份简短显眼的 FAQ，覆盖占大头的那几个问题：价格、物流、密码重置、工作时间。
3. 加上基于这些内容的 AI 回答。 AI 层能把访客自己的措辞匹配到正确答案，并处理追问。答不准的要保留转人工：AI 代理能做什么、不能做什么见 AI 客服代理，规则机器人与 AI 机器人的区别见 聊天机器人的类型，配置步骤见设置 AI 聊天回复。
4. 提交前推荐文章。 访客在联系表单或工单表单里开始打字时，把输入内容与知识库匹配，在提交前展示可能的答案。这是需求已经走到表单前、最后一次分流机会。

每一步都要保留显眼的人工入口——把人困住带来的不是节省，而是假分流。对仍然进来的工单，常用语能压缩每单的处理时长。

分流率、自助服务率与首次接触解决率的区别

这三个指标回答的问题不同，分母也不同。下表在同一份示例数据上计算：同一个月，1,000 个意图，其中 700 个用过自助服务，420 个未建工单即解决，产生 580 个工单，其中 406 个一次接触即解决。

使用不等于结果：70% 的意图用过自助服务，但只有 42% 避免了工单。FCR 是坐席侧的镜像指标——Zendesk 的定义是一次接触解决的工单 ÷ 收到的工单总数 × 100——分母是工单而不是意图。分母不同、数据集不同的比率，不要放在一起比。

在 TapCub 里怎么看分流

TapCub 没有一张叫「分流率」的报表，但本文讲的那条界线，问题在会话产生之前就解决，已经内建在它的访客端组件里。

• 置顶问答就是分流入口。 在 客服 › 知识库 把最常被问的问答条目置顶。它们会显示在访客端的常见问题里，访客打开答案不会建会话，也不耗额度。在本文的算例里，这部分就是「未建工单即解决」。
• 「没解决」就是那条界线。 访客点「没解决」或要求人工，就会建会话，问题交给 客服 › 客服工作台 里的坐席。这一下点击，就是一个需求从「被分流」变成「要人处理」的时刻。
• 几个替代指标一起看。 客服 › 客服报表 有知识库命中率（由问答精确匹配或检索回答的问题占比）、解决率和满意度。命中率上升、满意度下降，就是上一节说的「分流了但没解决」的信号。
• 让 AI 先答，但不硬答。 在 客服 › 聊天设置 › AI 接待 选「AI 先答」，AI 会根据知识库回答，资料不够时转人工，而不是猜一个答案。设置见设置 AI 回复。

资料来源

• Zendesk，Ticket deflection: Enhance your self-service with AI。
• Intercom 帮助，Update to Fin performance metrics。
• Freshchat 支持，Measuring KPIs for your bots in Freshchat。
• Zendesk，What is first contact resolution (FCR)? Benefits + best practices。