结合实际业务场景聊聊客服系统分配

客服系统有降低企业的成本和提升用户的服务体验这两个核心目标，所以除了要提升客户的自助解决率以及提升坐席的服务效率、服务能力，还要帮助客户快速地到能为他解决问题的人。本文作者对客服系统分配进行了分析，一起来看一下吧。

客服系统核心目标主要有两个：降低企业的成本和提升用户的服务体验。

所以，客服系统核心关注的，除了提升客户的自助解决率以及提升坐席的服务效率、服务能力之外，还有非常重要的一点，就是帮助客户准确快速地到能为他解决问题的人。

这就是我们今天要讲的主题：客服系统分配。

一、客服的专业分类——技能组

一般客服业务中，

技能组

是客服分配最基础的对象。

用户进行客服咨询是为了获取快速专业的帮助。大型公司的商品和服务都非常复杂，而基层客服对于专业知识的掌握能力有限，所以很多公司会针对于商品、场景等维度切分专业团队，用户进线时，将用户分配给不同的服务团队进行服务。

假设一个场景，如果客户希望咨询的是一个酒店相关的问题，结果给他分配的却是一个只了解机票知识的客服，沟通后仍需要机票客服帮他转接酒店客服服务，不仅伤害用户的咨询体验，也浪费了客服时间。

这样的专业团队，在客服系统中被称为“技能组”，即：拥有同一类专业技能的客服的集合组。

很多初入行的客服产品经理不太理解组织架构与技能组的具体区别，公司组织架构主要用于行政管理，技能组主要是为了切割不同服务能力。比如大型公司一般都会在全国各地设置客服团队，组织架构上可以拆分为上海团队、北京团队、南通团队、合肥团队等，他们又都存在相同服务能力的坐席，我们希望坐席接待客户时，这些相同能力坐席都能为客人提供同样的服务。这不可避免地导致了客服系统内的组织架构和技能组的交叉存在。

如何切分技能组，往往由公司业务决定，一般我们可以依赖于业务类型、用户来源、服务场景、服务语言、服务水平、服务能力差异、服务时间等多个维度来做专业能力的切分，比如“

7*24小时

抖音来源的酒店用户售后英文高能力IM技能组

”。实际场景下，不会真的存在这么复杂的技能组命名方式，但是不同切分条件，对于公司而言的确存在不同意义。

1）用户来源

不同来源的客户，定位不同，服务策略也不一样。比如有些来源特定指的是老年，老年的特殊性，就要有专门有这块服务能力的坐席来承接。

2）业务类型

一般取决于公司内部业务结构，比如酒店、国内酒店、海外酒店、国内机票等。

）服务语言

随着越来越多的中国品牌的出海战略，多语言服务能力也逐渐成为大型的标配。

4）服务场景

售前、售后、售中专业知识差异巨大，这也是最常用的专业划分标准。

5）服务方式

客服常用的服务方式包括IM、电话、邮件。现阶段越来越多的企业会采用融合式的服务方式，如IM结合电话服务这种，来为客户提供服务。这无疑是可以提升客户的服务体验的，但是这对坐席能力的要求也会提高。

6）服务能力差异

划分高低能力坐席，从降低企业成本的角度考虑的。让月薪1万的坐席，去解决简单的问题，这是浪费；而让月薪k的坐席，去处理他解决不了复杂问题，最终结果只能是产生额外的咨询转接，这也是浪费。

通过高低能力的区分，安排高能力坐席去服务一些紧急的、复杂或是高价值用户的问题，让普通坐席则去解决一些普通客户的简单问题，这也是常用的客服资源的配置方案。

7）服务时间

服务时间是基于业务类型决定的。以保险场景举例，车险事故救援场景，需要保持7*24小时的人工支持，去应对紧急车险事故，而其他场景，正常的服务工作时间满足客户需求。

另外，在国际化场景，技能组的服务时间往往还要考虑地区政策、跨时区、冬夏令时等因素。

二、用户咨询的分类——用户分层

既然有了专业的客服分类，如果准确地判断用户的咨询需求，也是客服系统需要解决的问题。

上文已提到的用户来源、业务类型、服务语言、服务方式、服务场景这些基础的业务因素，往往用作用户分层的第一层：业务分层。在公司业务团队非常庞大的情况下，先要区分用户具体咨询哪类业务，然后再由各个业务团队去细化自己的服务策略。

同一业务下，通常还会结合用户的历史咨询情况、当前订单信息、工单状态、用户等级、用户画像标签，来对用户进行服务的分层。

1）历史咨询情况

用户最近咨询的是哪个客服，有没有给坐席打过差评或好评，据此判断是否需要优先分配最近服务坐席或好评客服，以及是否需要屏蔽差评客服等。

这种情况下，也会产生分配系统中另外一个比较常用的功能，就是咨询的定向分配，即将特定的客户分配给指定的坐席。

2）订单与工单状态

订单信息和工单信息除了判断该将会话和电话分给谁之外，还会作为判断用户咨询优先级（紧急程度）的基础条件。比如一张酒店订单，如果：预计入住时间当前时间<0min或者为负值时，我们可以认为，用户在实际入住过程中出现了问题，这类问题极有可能导致极为严重的客诉，那在处理分配时，可以通过提高优先级的方式来处理。

）用户等级与用户画像

高价值用户有快速服务通道是一个行业比较通用的服务策略了。除此之外，很多企业也会维护很多特殊的用户画像，比如：明星、网红、易投诉用户等，以此作为分配的基础信息。

业务分层规则，往往由公司中台统一配置。而服务分层，由于业务特点的多样性，一般由业务自定义配置。会依赖于标准化的外部对接API、函数模板配置、函数计算规则配置，来快速实现业务需求。

三、咨询优先级的处理

目前客服系统内，咨询优先级的处理分为三种。

1. 同队列客人被接待优先级

同样是酒店订单的售后问题，不同的客人因为订单金额的不同、距离入住时间的差异 ，都会影响用户的被接待优先级，这种接待优先级直接体现在排队分配过程中。

对于队列优先级的处理，在产研设计时，我曾经有过两个方案：

方案1：

预设个优先级子队列，优先分配优先级高的子队列。同一子队列中，再按照用户等待时间依次分配，等待时间越长，越优先分配。新用户进线后，按照优先级，将用户插入对应子队列的尾部。这的确是一个可行方案，但是，缺点是可拓展性较差，因此我给出了一个新的方案。

方案2：

所有分配优先级，完全基于客人的排队分配等待时间进行排序，等待时间越长，越优先分配。

客人默认优先级为0，即排队分配等待时间=用户实际等待时间。实际分配时，优先级高的用户，一进队列，额外增加排队分配等待时间。比如优先级为10的用户，他的排队分配等待时间就会加600，分配时自然会领先普通用户。

甚至于，如果我们想设置一些队列黑名单，那我们将该用户优先级设为，那他得额外等分钟以后才能和普通用户拥有同等的分配优先级，变相实现分配黑名单功能。

方案2相较于方案1的优势在于，分配处理逻辑简单，分配效率更高，并且可扩展性更强。

2. 同组内不同客服接待优先级

同组内不同客服的接待优先级，一般是基于客服的接待能力和服务能力来定的。

参照客人优先级中的方案2，客服的接待优先级，最底层的算法，仍然是基于坐席的排队分配等待时间来计算的。

客服分配接待算法中，与客服相关的两个核心指标是：客服接待上限、客服能力值。坐席是否进入排队分配队列，取决于客服当前接待客人是否达到上限以及客服状态是否在线。进入分配队列后，下一次被分配的优先级取决于排队分配等待时间的值。

排队分配等待时间=当前时间上一次被分配时间+*（接待上限当前接待n*预关闭会话数）/接待上限*客服能力值

预关闭：IM咨询过程中，用户经常会出现回复不及时的情况，这种情况下，为了避免客服资源的浪费，会将这些咨询会话进行预关闭。预关闭会话不会再计入当前坐席接待数，但是用户如果返回激活对话时，又能立即联系到原坐席。所以预关闭不占用客服接待上限，但由于预关闭会话，随时可能被用户激活，回弹给坐席，在考虑分配顺序时，有必要将预关闭会话的数量，也作为分配算法参数之一进行计算。

. 单个坐席多个技能组之间的服务优先级

当客服存在多个技能时，客服针对于不同技能组也可以存在接待的优先级。

还是以酒店场景举例，海外酒店售前技能组、国内酒店售前技能组、海外酒店售后技能组、国内酒店售后技能组四种服务能力，坐席A有前三种服务能力，坐席B有后三种服务能力，那么我们可以针对于坐席的服务能力，有更多样的组合搭配。但每个坐席在针对于不同技能组的服务能力值各有不同。

坐席A有海外酒店售前技能组（能力值）、国内酒店售前技能组（能力值2）、海外酒店售后技能组（能力值1）三个技能组，若三个技能组客人都存在排队情况，那么坐席理应去优先接待海外酒店售前技能组（能力值）的客人。

四、基础分配的兜底——溢出逻辑

上文也提到过，针对于技能组的专业分类，是为了提升客户的咨询体验和降低企业成本。

但是极端情况下，由于不同技能组进线流量的不均等，导致有些队列排队爆满而有些队列一直处于接待空闲，这会使用户服务水平下降，并且造成客服资源浪费。

所以，当我们拆分了高能力技能组和普通服务技能组后，如果高能力技能组内客人等待人数过多而普通服务组坐席空闲，是不是有可能实现普通服务组对高能力组的支援？这就涉及到分配系统的另一个概念：溢出。

笔者之前负责的分配系统中，曾经有见过一些非常简单粗暴的溢出功能逻辑：

这种溢出逻辑存在两个问题：第一，当技能组1、技能组2、技能组同时忙碌需要溢出时如何处理；第二，当客人从技能组1溢出到技能组2后，理论上该客人就无法继续被技能组1内的客服接起了。

所以，笔者在这种溢出策略上，做了一些改良：

用户进线咨询排队超过一定时间后，会将溢出技能组内坐席拉入到分配队列，与技能组内坐席一起进行分配轮旬。当然，从优先级上，优先分配本组的默认坐席，然后按照溢出层级，依次计算分配优先级。

五、结语

随着AI技术的不断进步，在客服分配的场景下，也会更多地利用AI和算法的辅助来支持客户咨询的分配。期待未来在更多AI技术的赋能下，客服的分配可以更智能、更准确。

以上内容基于笔者结合学习和工作实践的思考，若有理解不到位之处，还望大家指正，更希望通过这篇文章能与各位多多交流。

本文由@爱吐槽的徐教授 原创发布于人人都是产品经理。未经许可，禁止转载。

题来自unsplash，基于 CC0 协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。