如何用人机协同提高客服效率?阿里巴巴客服助手诞生了-阿里云开发者社区

开发者社区> 阿里机器智能> 正文

如何用人机协同提高客服效率?阿里巴巴客服助手诞生了

简介: 阿里巴巴经济体每天都在服务着数以亿计的会员,每天会员求助的进线量巨大,尽管机器人的解决能力已经很强大,但是以目前技术人工客服依然无法完全被替代,庞大的阿里人工客服在保障会员体验的任务中仍扮演着十分重要的角色。阿里巴巴新零售技术事业群-CCO技术部打造了一款助手在客服工作中予以辅助,实现人机协同。

小叽导读:阿里巴巴经济体每天都在服务着数以亿计的会员,每天会员求助的进线量巨大,尽管机器人的解决能力已经很强大,但是以目前技术人工客服依然无法完全被替代,庞大的阿里人工客服在保障会员体验的任务中仍扮演着十分重要的角色。阿里巴巴新零售技术事业群-CCO技术部打造了一款助手在客服工作中予以辅助,实现人机协同。

1.背景

经济压力下行,提高效率变成了各行各业的核心诉求。客服行业更是如此,我们有不少新手客服,这些客服效率普遍不高,也影响到了会员体验。

阿里巴巴智能客服工作台承载了阿里巴巴绝大多数经济体bu以及越来越多外部大企业的客服业务,如何提效已成为技术同学必须要解决的一大难题,对我们来说,通过产品技术手段来提效不仅可以降低成本,还能提升客服工作的幸福感。

2.思路

联想到打游戏,提升游戏主角的战斗力无非也就是两个:1)外挂加持,给他一副吓人的外挂装备提前锁定胜局;2)内力提升,不断打些小怪来提升主角等级。

image.png

客服领域也是如此:1)外挂加持。如果我们打造一款助手在客服工作过程中予以辅助,实现人机协同,那将大大降低新手客服的费力度;2)内力提升。新手效率不高的本质原因在于缺乏实战训练,如果我们打造一款全渠道(在线、热线)培训机器人来仿真会员进线,并让客服针对性的练习,那将大大缩短客服成熟所需要的时间。本文将围绕第一个思路(客服助手)来介绍我们的实践经验,第二个思路的工作我们有机会再详细阐述。

3.客服助手解决什么问题?

要回答这一问题的前提是对业务熟悉,为培养业务体感,我们花了半个多月时间仔细观摩了500多通客服操作,总结出一通电话的大致流程如下。

image.png

第一个阶段最为重要,开局决定着整通会话的成败。我们发现80%的对话都会按三个步骤进行:1)确定会员名;2)确定订单号;3)确定问题&找出解决方案。

1)确定会员名

用户电话进来的第一件事情是要识别到会员名,系统原先提供了根据来电号码识别会员的功能,但是现场观摩时发现识别率不高,识别到且识别正确的比例只有55%,为什么?两个点:a)固定电话占比小部分,这部分我们直接不识别;b)剩下大部分是手机进线,我们直接调用会员平台服务获取绑定该手机号的会员信息,但识别率低,原因多样,比如一个人拥有多个手机号和多个会员账号,或者用家人的手机来进线。而一旦识别错误,客服就会让会员报会员名,如果会员名全是英文数字还好,冷僻一些的中文可能要描述好几分钟。

2)确定关键单据号

确定会员名后下一步就是要确定该会员的关键单据号,淘系大部分的来电都和订单相关,找不到订单,问题无法处理。现在随着会员的订单越来越多,客服找订单成本也越来越高,往往会让会员报订单编号。我们知道,订单编号位数很长,以后可能会更长,不管是会员找起来念起来还是客服记起来都不方便,更糟糕的是,通话过程中手机信号会降级(比如4G降级为3G),如果没连wifi,打开手淘找订单会很卡,之前电话录音中经常听到会员说“不好意思,信号突然变差了,等我连个wifi”,就是这个原因。

3)确定诉求&找出解决方案

目前解决方案都是由运营专家配置,然而真正服务会员的是客服,客服需要依靠他的经验做两次映射才能将具象化的会员描述转换为最终运营配置的解决方案(如图所示)。

确定诉求:对话其实是思想从高维向低维的投影,人能通过对话,有效理解语言,靠的是解读能力,但是如果只用听到的文字信息,来反推会员的诉求,可能会存在失真的情况,客服也是一样,除了要靠他的经验理解会员说的话外,还需要查看各类业务视图等更多维度的信息来还原会员真正的诉求。

找解决方案:在确定会员诉求基础上,客服需要将他的理解映射为关键词并进行搜索,并在搜索列表中选择一个他认为靠谱的解决方案。

image.png

淘系业务复杂,数据视图众多,解决方案更是繁多,对新手来说,这两次映射都是鸿沟,需要花费大量时间摸索,不仅效率低下,甚至会经常给出错误解决方案对会员体验造成更大伤害。

第二个阶段是沟通安抚,这个阶段耗时较长,与前后阶段都存在叠加。对热线而言,客服一边备注一边与会员交流或一边看解决方案一边安抚会员等情况都是常态,要求客服聚精会神,一心多用,事实上很多新手并不具备这种并发操作的能力,经常在并发的过程中漏听了会员的描述,造成重复沟通,影响服务效率和品质。对于在线而言,客服在发送完解决方案后需要花费大量时间安抚会员,当客服并发服务多个会员的时候(有些处于安抚阶段,有些处于开始阶段),需要客服来回切换,一是成本很高,二是安抚回复往往不及时影响会员体验。

第三个阶段涉及到客服的一些操作,比如服务小计、填写升级工单、发短信通知等,这个阶段的特点是需要客服大量输入,以服务小计为例,经常看到客服从各个地方复制会员名、订单编号、解决方案等信息到框内,以填写升级工单为例,需要客服从很长的下拉框中选择一个类目......,这些人肉机械的繁复操作不仅拉长了对话时长,而且显著增加了客服费力度。此外针对在线场景,经常出现会员事实上已经离开会话但是客服一直在等待会话被系统超时结束的情景,客服干等这些时间其实是人力的浪费,也是效率的损失。

至此,我们已经明确了各阶段影响小二效率的核心问题,这些问题需要被客服助手解决,怎么解决?

4.策略

在第一个阶段,客服助手的关键是辅助客服提升定位问题的效率,重点打造如下能力:1)会员识别(提升会员识别覆盖度);2)订单识别(辅助客服识别订单);3)场景识别(辅助客服识别解决方案),让客服从以往大量的问、记、想、查的手忙脚乱变成,只做一些信息确认即可的从容不迫。在这个阶段客服助手最能发挥效果。

在第二个阶段,客服助手的重点是降低客服沟通安抚时的费力度,提升并发能力,针对热线场景,助手提供实时语音转文本功能,将会员说的的每一句话都实时呈现给客服,提升热线客服的并发操作能力,避免漏听导致的重复沟通。

在第三个阶段,客服助手提供智能备注/填单(智能摘要)的能力,降低客服记录问题的费力度。针对在线场景,助手还提供智能断线识别功能,提前判断会员是否已经离开会话,减少客服空等时间。

如何让这么多智能辅助能力以一种统一的方式快速融合到客服助手中,并实现与现有服务系统的轻耦合?我们实现了一套基于事件驱动的客服助手框架。

image.png

5.技术方案

策略有了,如何实现?由于功能较多,下文不再一一展开,只对第一个阶段对应的部分解决方案进行阐述。

5.1会员识别

针对少部分的固定电话进线,我们使用历史重复进线数据(每通电话客服都会确定会员名,“电话号码-会员名”数据会入库)进行匹配,有一大半能被识别,而对于那些经常识别错误的固话号码(可能是公用电话),我们设置了黑名单不进行识别。

针对剩下大量的手机进线,我们优先使用24小时内的重复进线数据,因为一天内用同一手机号码重复进线大概率是同一会员。剩下就直接走会员平台接口了吗?不,我们使用模型进行筛选。简单来说先通过同人识别模型找到这个手机号关联的会员名,然后再通过会员识别模型从多个会员名里找到最有可能的那个(模型原理?比如找到A和B两个会员名,A最近一年都没买过东西,B最近下过单并且处于退款状态,这个时候会员名B的概率自然高些)。最后我们用会员平台服务兜底。

这一套组合拳下来还剩下少量来电检测不出会员账户,针对这种情景,我们会在IVR阶段(进线前语音交互)提示用户输入注册的手机号码(用户可选),如果用户输入,这个号码将作为参数传递进来。经过几轮迭代,目前会员识别到且识别正确的比例从之前的55%提升到90%。

image.png

5.2订单识别

我们希望会员一进线,助手就能猜中会员哪笔订单遇到问题并展示给客服,避免客服询问会员订单编号带来的耗时。

小蜜机器人之前已经有订单识别基础,我们优先使用小蜜机器人的订单识别能力,发现能覆盖30%。如何进一步提升覆盖度?继续向数据要红利,如多渠道的重复进线数据(某会员昨天进线咨询过一个订单,今天他如果再次进线大概率(超过90%)问的是同一订单),这些数据也反哺到订单识别模型。经过多次迭代,目前进线前订单识别覆盖度达到50%,准确度90%以上。

剩下没覆盖到的怎么办?继续让客服问订单编号?仔细思考,与其让客服问订单编号这种获取费力度非常高的信息,还不如问商品名、价格、购买时间等会员回答起来不费力的信息,这些信息也能很好的帮助确定订单,这就引申出我们在服务过程中订单识别的工作。

怎么做?简单来说,会员说的每句话都通过达摩院强大的智能语音服务实时转为文本,然后通过实体识别模型(BILSTM+CRF)提取出品类、品牌、日期等实体特征,最后通过排序学习模型计算与所有订单的匹配值,并取top的订单展示出来。经过多次迭代,目前服务过程中订单识别覆盖度20%,准确度89%。

image.png

5.3场景识别

前面讲到客服除了要理解读会员说的话外,还需要查看各类业务视图等更多维度的信息来还原会员真正的诉求,之后又要通过关键词搜索来筛选出解决方案。为了简化这些环节,我们打造了服务场景识别引擎,在客服服务过程中,实时监听语料消息,并自动抓取订单、工单、历史进线相关等上下文数据,完成会员意图、数据因子自动识别,最终实现解决方案自动匹配和开启。

这里的难点在于业务的复杂度:1)以淘系为例,客服使用的解决方案几百个,原来解决方案上往往会出现交集、父子关系等问题,直接做分类存在识别准确率低的问题;2)除淘系外,我们希望引擎具备白盒特性,能快速扩展给目前已经使用阿里巴巴智能客服工作台的经济体bu以及外部大企业。

为解决准确度问题,引擎采用了分层场景识别模式:1)和业务一起定义梳理出服务的主场景,由于主场景数目较少,我们可以通过训练主场景模型来保障准确率;2)在子场景(槽位)识别上,我们基于轻量级语义匹配、相似度计算等简单的方式来实现。

为解决扩展性的问题,我们使用流程引擎来实现配置,针对一些租户或一些业务,有时候仅通过配置一些数据因子或意图因子就能精确识别出场景,无需开发同学介入。

image.png

对于主场景模型最基本的要求是将实时语聊等文本特征与订单这类业务特征进行融合,如图是我们早期的一个尝试。

image.png

经过多次迭代,目前场景识别在淘系的覆盖度达到75%,准确度90%以上。

6.部分功能展示(非真实数据)

image.png

7.小结

通过与业务同学一起努力,客服助手率先在淘系bu被大量使用,实现了人机交互到人机协同这一范式的转变。从业务指标平均通话时长(ATT)来看提效明显,正朝着提效30%的目标靠近。更为可喜的是,客服对工作台的产品满意度有了质的提升,直接提升了11%,创历史新高。

技术的价值不是要取代人,而是要协作人,让人去做更有温度的事情。未来,我们会在技术上持续积累,在产品上不断进化,围绕着经济体、商家、企业沉淀出商业能力并输出,让人机协同成为服务行业的普惠能力。

最后打下招聘广告,阿里巴巴新零售技术事业群CCO技术部招聘算法、JAVA,希望有越来越多同学和我们一起共创事业,有意向欢迎邮件简历:zhanlijun.zlj@alibaba-inc.com

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
阿里机器智能
使用钉钉扫一扫加入圈子
+ 订阅

关于阿里的机器智能创新技术均呈现于此

官方博客
官网链接