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

爱吐槽的徐教授 2023-08-07 14:40:28

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

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

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

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

一般客服业务中，技能组是客服分配最基础的对象。

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

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

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

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

如何切分技能组，往往由公司业务决定，一般我们可以依赖于业务类型、用户来源、服务场景、服务语言、服务水平、服务能力差异、服务时间等多个维度来做专业能力的切分，比如“7*24小时抖音来源的酒店用户售后英文高能力IM技能组”。实际场景下，不会真的存在这么复杂的技能组命名方式，但是不同切分条件，对于公司而言的确存在不同意义。

1）用户来源

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

2）业务类型

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

3）服务语言

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

4）服务场景

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

5）服务方式

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

6）服务能力差异

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

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

7）服务时间

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

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

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

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

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

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

1）历史咨询情况

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

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

2）订单与工单状态

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

3）用户等级与用户画像

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

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

三、咨询优先级的处理

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

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

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

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

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

产品经理，产品经理网站

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

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

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

产品经理，产品经理网站

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

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

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

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

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

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

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