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