AI客服-服务前的智能路由-02

各位好，我是ViVi，这是 AI 客服的第2篇，今天我们来聊聊：智能路由。

上一期我们讲了AI客服里的"意图识别"。通俗讲，意图识别处理的是这样一个问题："用户真正想要做什么"。

比如用户讲："我昨天申请的退款，怎么钱还没到账"。系统需要识别，他当前询问的是"退款进度"，而非"申请退款"。不过，明白用户想做什么，只是完成了第一步。

紧接着还有一个更实际的问题：这位用户应当交给谁处理？是机器人直接搞定？还是转接人工？

若是转人工，是普通坐席、高级坐席，还是专门负责退款的坐席？

如果同时有不少用户在排队，谁应当优先获得服务？

如果最匹配处理这个问题的员工正忙着，是继续等候，还是选择次优人选？

1

智能路由究竟是什么

很多人初次接触"智能路由"，往往以为它就是：用户提出问题 → AI识别意图 → 分发到对应客服组。例如：退款问题 → 退款组；物流问题 → 物流组；投诉问题 → 投诉组。这确实是路由的一部分，但也只是最基本的一层。

一套真正完善的智能路由体系，需要持续回答以下问题：

（1）这个任务是交给AI还是人工？

（2）若需人工，应当进入哪个服务队列？

（3）同一队列中有多个用户，谁先获得服务？

（4）此用户应当分配给哪一位员工？

（5）若长时间无法匹配到合适人选该如何应对？

因此，我倾向于将智能路由理解为：在恰当的时机，把恰当的问题，分配给恰当的资源。这里的"资源"未必专指人工客服，也可能是机器人、AI Agent、专家组或其他后台部门。

一套相对完整的流程，大致如下：

2

第1步：先判断这个问题能否交由AI

用户接入客服系统后，之前已经完成了一部分理解工作（意图试图）。

比如：

用户A："帮我查一下订单何时发货"。系统判定：普通物流查询，没有明显风险。那么完全可以优先交给AI处理。

但用户B讲："我的账户突然少了5000块钱，这笔钱不是我操作的"。哪怕AI理论上能给用户讲一些账户安全知识，也不意味着应该让AI继续处理。因为这件事已经牵涉资金安全。

所以智能路由的第一步，不应仅仅判断：这个用户属于哪条业务线。还应当判断：这件事到底能否交给AI？

这里就会涉及一个至关重要的概念：硬规则。

硬规则可以简单理解为：无论AI判断多么智能，都无法逾越的业务边界。

比如：

账户被盗 → 必须进入安全专席；

高风险投诉 → 必须进入投诉团队；

某些法律、监管类问题 → 必须人工介入；

超过某个金额的业务 → 必须由具备相应权限的人处理；

某些特殊用户 → 必须进入专属服务体系。

因此，AI在这里主要承担理解用户的职责，而硬规则则承担划定边界的职责。

AI愈发智能，并不代表所有决定都应交由AI。尤其在客服领域，许多问题不是"能不能回答"，而是：有没有权限处理、出问题谁担责。

如果确认AI可以处理，就进入AI服务。如果确认必须人工，才正式进入后续的人工路由体系。

3

第2步：进入哪个队列，谁应当优先

确认需要人工后，接下来首先要解决：此用户应当进入哪个服务队列？

传统客服中心通常按业务划分，但实际业务往往还会综合：语言；用户类型；产品线；服务渠道；特殊业务资格等。

这里有一个非常关键的设计原则：队列不要拆分得过细。

比如AI能够识别出："退款到账异常"，但员工未必需要一个叫做："退款到账异常处理技能"的标签。员工可能只需要具备：退款业务能力。

也就是说：意图可以识别得很细，但队列和员工技能不必跟着拆得同样细。否则业务稍有变化，系统里就可能涌现大量相似队列和技能标签，最终越来越难以维护。

进入队列后，又会产生第二个问题：谁先处理？

传统排队最容易想到的就是"先来先服务"，但客服场景并不能完全照搬。

假设队列中同时有三个用户：

A：普通退款查询，刚刚接入。

B：退款失败，已等待5分钟。

C：账户存在资金异常，刚接入20秒。

若严格按先来先服务，应当处理B，但实际业务往往需要优先处理C。因此智能路由通常还会设置：优先级。

比如：高风险问题优先于普通业务异常，普通业务异常又优先于一般咨询。但这里也不能简单变成：高优先级用户可以无限插队，否则普通用户可能永远排不到。

因此，还需要考虑：等待时间，即用户等待越久，优先级应当逐步提升。所以排队并不是一成不变的。

一个原本普通的问题，等待时间过长后，也应当逐渐获得更高的处理优先级。这也是智能路由里极易被忽视的一点：不仅要照顾真正紧急的问题，也要避免普通用户被无限晾在队伍末尾。

4

第3步：不是谁空闲给谁，而是先找有资格的人

现在行业里经常提到：技能路由。

但"技能"这个词很容易引发误解。很多人会想：谁的满意度最高？谁的FCR最优？谁最擅长安抚投诉？然后把各类绩效数据全部做成员工技能标签。其实，更合理的做法应当将员工信息分成几层。

1-第一层：资格型能力

它回答的是：这位员工到底能否处理这个问题？

比如：

是否能处理电话、Chat、邮件；

是否掌握对应语言；

是否熟悉退款、物流、支付等业务；

是否拥有对应金额权限；

是否具备高级投诉处理资格；

是否具备特殊产品或用户群体的处理权限。

这些标签的共性是：相对稳定且可以验证。因此，它们非常适合用于第一轮筛选。

比如现在来了一个："中文用户，申请处理2000元退款"。

那么第一轮筛选后，真正进入候选池的只剩员工A。

2-第二层：熟练程度

比如：

员工A和员工B都具备退款技能，但A的退款业务熟练度是5级，B是3级。那么复杂退款问题当然可以优先考虑A。

但这里最好不要把"熟练度"变成绝对门槛，否则可能形成一个非常典型的循环。

与此同时，其他员工因长期拿不到这类业务，越来越缺乏经验，最后系统的数据看起来还会再次印证："果然只有A最擅长退款"。这就是典型的反馈回路。

所以比较合理的思路应当是：稳定能力决定能不能接，熟练程度决定更希望谁接，而不是把最熟练的人变成唯一能接的人。

5

第4步：从合格员工中，挑选"当前最合适的人"

经过资格筛选后，可能仍然有不少人都能处理，这时候才真正需要做员工排序。

系统可能综合考虑：

业务熟练程度；

当前是否空闲；

当前负载；

已经多久没有分到任务；

当前同时处理多少个Chat；

部分类似场景的历史处理表现。

这里有一个至关重要的区别：最强的人，不一定是当前最合适的人。

比如：员工A处理退款能力最强，但他现在已同时处理4个Chat；员工B退款能力稍弱，但完全空闲。如果所有退款用户都继续等A，A会越来越忙，而B没有任务，用户等待时间越来越长。

这种分配当然不能算"智能"。

所以智能路由优化的应当是：整体资源效率，而不是把每一个Case都塞给最厉害的人。

这也涉及一个比较敏感的问题：能否直接根据员工的FCR、AHT、满意度等绩效指标来决定任务分配？

理论上可以参考，但最好不要过度依赖。因为绩效数据本身也可能受到任务分配影响。

比如：A员工前两周集中支援一个相对简单的业务。结果，FCR很高，AHT很低。于是，系统认定他"特别擅长"这一场景，然后继续分配给他更多类似业务。

那么这些漂亮的数据到底说明：员工能力特别强？还是因为系统本来就给了他更容易处理的Case？很难完全拆开。同时绩效还会受到：样本量；班次；用户类型；业务难度；促销活动；数据口径等众多因素影响。

因此，一个相对稳妥的设计是：资格标签负责筛选，熟练度负责优先级，绩效数据仅作为员工排序中的参考信号之一，不要让它拥有过高权重。

6

第5步："靶心路由"扩大分配，以及评估智能路由效果

现实世界不会每次都刚好有一个完美员工正在等待用户。

假设一个Case希望匹配：英语 + 退款技能4级以上，但当前所有符合条件的人都在忙，怎么办？

第一种选择当然是继续等，但不能无限等，所以比较合理的机制是：逐步放宽匹配要求。

比如：

刚进入时：退款熟练度5级 + 英语能力4级以上。

等待5秒：放宽到退款熟练度4级。

继续等待：放宽到退款熟练度3级。

再继续等待：只要具备基本退款资格和英文服务能力，就可以承接。

这里要注意：可以放宽的是偏好，不能放宽的是资格。

比如：A员工没有2000元退款权限。无论用户等多久，也不能因为队列太忙，突然让他拥有这个权限。

如果不断扩大员工池，仍然无法在合理时间内提供服务，就需要进入：溢出处理。

判断是否需要溢出，更值得关注的是：预计等待时间和SLA。也就是：按当前服务能力，这位用户还能否在目标时间内获得服务？若不能，就应当逐步扩大服务范围或者启动备用机制。

而整个智能路由项目上线后，也不能只看一个："路由准确率95%"。

最终评估至少应关注几类结果：

（1）路由本身：

意图和路由是否准确；

高风险问题有没有遗漏；

错误路由有没有下降。

（2）用户过程：

转接率有没有下降；

等待时间有没有改善；

SLA有没有提升；

用户放弃率有没有降低。

（3）问题解决：

FCR有没有提高；

重复进线有没有减少；

用户满意度有没有变化；

AHT是否合理。

这里尤其不能单独追求AHT。如果AHT下降20%，但用户重复进线增加30%，那很可能不是效率提高了，而只是客服更快结束了会话。

最后还应该观察整个客服中心：

高级客服有没有继续被大量简单业务占用；

普通员工是否获得足够业务机会；

各技能组负载是否合理；

单次服务成本有没有下降；

相同人力是不是能够处理更多需求。

这也是为什么智能路由不能做成一个一次性项目。因为业务一直在变化，产品会变，政策会变，用户表达方式会变，员工会调岗、离职、培训、支援，旺季和淡季的流量结构也完全不同。

这些变化都会影响意图识别、队列、员工技能、优先级和最终分配效果。

所以真正合理的运行方式应当是：上线 → 监控 → 发现问题 → 调整 → 验证 → 继续运行。

如果上一期的"意图识别"，解决的是：让AI听懂用户；那么这一期的"智能路由"，解决的就是：听懂以后，究竟该怎么办。

智能路由并不是简单地把用户分给"最好的客服"，它真正要做的是：在有限的服务资源里，根据风险、时效、能力和负载，为每一个问题找到当下更合适的去处。

这才是智能路由值得深究的地方。

END

求点赞

求分享

求喜欢