客服系统有降低企业的成本和提升用户的服务体验这两个核心目标，所以除了要提升客户的自助解决率以及提升坐席的服务效率、服务能力，还要帮助客户快速地找到能为他解决问题的人。本文作者对客服系统分配进行了分析，一起来看一下吧。
客服系统核心目标主要有两个：降低企业的成本和提升用户的服务体验。
所以，客服系统核心关注的，除了提升客户的自助解决率以及提升坐席的服务效率、服务能力之外，还有非常重要的一点，就是帮助客户准确快速地找到能为他解决问题的人。
这就是我们今天要讲的主题：客服系统分配。
一般客服业务中，技能组是客服分配最基础的对象。
用户进行客服咨询是为了获取快速专业的帮助。大型公司的商品和服务都非常复杂，而基层客服对于专业知识的掌握能力有限，所以很多公司会针对于商品、场景等维度切分专业团队，用户进线时，将用户分配给不同的服务团队进行服务。
假设一个场景，如果客户希望咨询的是一个酒店相关的问题，结果给他分配的却是一个只了解机票知识的客服，沟通后仍需要机票客服帮他转接酒店客服服务，不仅伤害用户的咨询体验，也浪费了客服时间。
这样的专业团队，在客服系统中被称为“技能组”，即：拥有同一类专业技能的客服的集合组。
很多初入行的客服产品经理不太理解组织架构与技能组的具体区别，公司组织架构主要用于行政管理，技能组主要是为了切割不同服务能力。比如大型公司一般都会在全国各地设置客服团队，组织架构上可以拆分为上海团队、北京团队、南通团队、合肥团队等，他们又都存在相同服务能力的坐席，我们希望坐席接待客户时，这些相同能力坐席都能为客人提供同样的服务。这不可避免地导致了客服系统内的组织架构和技能组的交叉存在。
如何切分技能组，往往由公司业务决定，一般我们可以依赖于业务类型、用户来源、服务场景、服务语言、服务水平、服务能力差异、服务时间等多个维度来做专业能力的切分，比如“7*24小时抖音来源的酒店用户售后英文高能力IM技能组”。实际场景下，不会真的存在这么复杂的技能组命名方式，但是不同切分条件，对于公司而言的确存在不同意义。
1）用户来源
不同来源的客户，定位不同，服务策略也不一样。比如有些来源特定指的是老年人群体，老年人群体的特殊性，就要有专门有这块服务能力的坐席来承接。
2）业务类型
一般取决于公司内部业务结构，比如酒店、国内酒店、海外酒店、国内机票等。
3）服务语言
随着越来越多的中国品牌的出海战略，多语言服务能力也逐渐成为大型客服中心的标配。
4）服务场景
售前、售后、售中专业知识差异巨大，这也是客服中心最常用的专业划分标准。
5）服务方式
客服常用的服务方式包括IM、电话、邮件。现阶段越来越多的企业会采用融合式的服务方式，如IM结合电话服务这种，来为客户提供服务。这无疑是可以提升客户的服务体验的，但是这对坐席能力的要求也会提高。
6）服务能力差异
划分高低能力坐席，从降低企业成本的角度考虑的。让月薪1万的坐席，去解决简单的问题，这是浪费；而让月薪3k的坐席，去处理他解决不了复杂问题，最终结果只能是产生额外的咨询转接，这也是浪费。
通过高低能力的区分，安排高能力坐席去服务一些紧急的、复杂或是高价值用户的问题，让普通坐席则去解决一些普通客户的简单问题，这也是常用的客服资源的配置方案。
7）服务时间
服务时间是基于业务类型决定的。以保险场景举例，车险事故救援场景，需要保持7*24小时的人工支持，去应对紧急车险事故，而其他场景，正常的服务工作时间满足客户需求。
另外，在国际化场景，技能组的服务时间往往还要考虑地区政策、跨时区、冬夏令时等因素。
既然有了专业的客服分类，如果准确地判断用户的咨询需求，也是客服系统需要解决的问题。
上文已提到的用户来源、业务类型、服务语言、服务方式、服务场景这些基础的业务因素，往往用作用户分层的第一层：业务分层。在公司业务团队非常庞大的情况下，先要区分用户具体咨询哪类业务，然后再由各个业务团队去细化自己的服务策略。
同一业务下，通常还会结合用户的历史咨询情况、当前订单信息、工单状态、用户等级、用户画像标签，来对用户进行服务的分层。
1）历史咨询情况
用户最近咨询的是哪个客服，有没有给坐席打过差评或好评，据此判断是否需要优先分配最近服务坐席或好评客服，以及是否需要屏蔽差评客服等。
这种情况下，也会产生分配系统中另外一个比较常用的功能，就是咨询的定向分配，即将特定的客户分配给指定的坐席。
2）订单与工单状态
订单信息和工单信息除了判断该将会话和电话分给谁之外，还会作为判断用户咨询优先级（紧急程度）的基础条件。比如一张酒店订单，如果：预计入住时间-当前时间<30min或者为负值时，我们可以认为，用户在实际入住过程中出现了问题，这类问题极有可能导致极为严重的客诉，那在处理分配时，可以通过提高优先级的方式来处理。
3）用户等级与用户画像
高价值用户有快速服务通道是一个行业比较通用的服务策略了。除此之外，很多企业也会维护很多特殊的用户画像，比如：明星、网红、易投诉用户等，以此作为分配的基础信息。
业务分层规则，往往由公司中台统一配置。而服务分层，由于业务特点的多样性，一般由业务自定义配置。会依赖于标准化的外部对接API、函数模板配置、函数计算规则配置，来快速实现业务需求。
目前客服系统内，咨询优先级的处理分为三种。
同样是酒店订单的售后问题，不同的客人因为订单金额的不同、距离入住时间的差异 ，都会影响用户的被接待优先级，这种接待优先级直接体现在排队分配过程中。
对于队列优先级的处理，在产研设计时，我曾经有过两个方案：
方案1：预设N个优先级子队列，优先分配优先级高的子队列。同一子队列中，再按照用户等待时间依次分配，等待时间越长，越优先分配。新用户进线后，按照优先级，将用户插入对应子队列的尾部。这的确是一个可行方案，但是，缺点是可拓展性较差，因此我给出了一个新的方案。
方案2：所有分配优先级，完全基于客人的排队分配等待时间进行排序，等待时间越长，越优先分配。
客人默认优先级为0，即排队分配等待时间=用户实际等待时间。实际分配时，优先级高的用户，一进队列，额外增加排队分配等待时间。比如优先级为10的用户，他的排队分配等待时间就会加600，分配时自然会领先普通用户。
甚至于，如果我们想设置一些队列黑名单，那我们将该用户优先级设为-10000000，那他得额外等10000000分钟以后才能和普通用户拥有同等的分配优先级，变相实现分配黑名单功能。
方案2相较于方案1的优势在于，分配处理逻辑简单，分配效率更高，并且可扩展性更强。
同组内不同客服的接待优先级，一般是基于客服的接待能力和服务能力来定的。
参照客人优先级中的方案2，客服的接待优先级，最底层的算法，仍然是基于坐席的排队分配等待时间来计算的。
客服分配接待算法中，与客服相关的两个核心指标是：客服接待上限、客服能力值。坐席是否进入排队分配队列，取决于客服当前接待客人是否达到上限以及客服状态是否在线。进入分配队列后，下一次被分配的优先级取决于排队分配等待时间的值。
排队分配等待时间=当前时间-上一次被分配时间+N*（接待上限-当前接待-n*预关闭会话数）/接待上限*客服能力值
预关闭：IM咨询过程中，用户经常会出现回复不及时的情况，这种情况下，为了避免客服资源的浪费，会将这些咨询会话进行预关闭。预关闭会话不会再计入当前坐席接待数，但是用户如果返回激活对话时，又能立即联系到原坐席。所以预关闭不占用客服接待上限，但由于预关闭会话，随时可能被用户激活，回弹给坐席，在考虑分配顺序时，有必要将预关闭会话的数量，也作为分配算法参数之一进行计算。
当客服存在多个技能时，客服针对于不同技能组也可以存在接待的优先级。
还是以酒店场景举例，海外酒店售前技能组、国内酒店售前技能组、海外酒店售后技能组、国内酒店售后技能组四种服务能力，坐席A有前三种服务能力，坐席B有后三种服务能力，那么我们可以针对于坐席的服务能力，有更多样的组合搭配。但每个坐席在针对于不同技能组的服务能力值各有不同。
坐席A有海外酒店售前技能组（能力值3）、国内酒店售前技能组（能力值2）、海外酒店售后技能组（能力值1）三个技能组，若三个技能组客人都存在排队情况，那么坐席理应去优先接待海外酒店售前技能组（能力值3）的客人。
上文也提到过，针对于技能组的专业分类，是为了提升客户的咨询体验和降低企业成本。
但是极端情况下，由于不同技能组进线流量的不均等，导致有些队列排队爆满而有些队列一直处于接待空闲，这会使用户服务水平下降，并且造成客服资源浪费。
所以，当我们拆分了高能力技能组和普通服务技能组后，如果高能力技能组内客人等待人数过多而普通服务组坐席空闲，是不是有可能实现普通服务组对高能力组的支援？这就涉及到分配系统的另一个概念：溢出。
笔者之前负责的分配系统中，曾经有见过一些非常简单粗暴的溢出功能逻辑：
这种溢出逻辑存在两个问题：第一，当技能组1、技能组2、技能组3同时忙碌需要溢出时如何处理；第二，当客人从技能组1溢出到技能组2后，理论上该客人就无法继续被技能组1内的客服接起了。
所以，笔者在这种溢出策略上，做了一些改良：
用户进线咨询排队超过一定时间后，会将溢出技能组内坐席拉入到分配队列，与技能组内坐席一起进行分配轮旬。当然，从优先级上，优先分配本组的默认坐席，然后按照溢出层级，依次计算分配优先级。
随着AI技术的不断进步，在客服分配的场景下，也会更多地利用AI和算法的辅助来支持客户咨询的分配。期待未来在更多AI技术的赋能下，客服的分配可以更智能、更准确。
以上内容基于笔者结合学习和工作实践的思考，若有理解不到位之处，还望大家指正，更希望通过这篇文章能与各位多多交流。
本文由@爱吐槽的徐教授 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自unsplash，基于 CC0 协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。