前言:本文作者是“AI产品经理大本营”团员@苍狼剑歌,现任某一线大厂AI产品经理。另外,文末还有2个“hanniman读者专属福利”,1)优惠券 for 三节课的核心课程——产品经理P1(入门)、P2(进阶)、P3(高阶)、策略、数据。2)优惠券 for 上海产品经理大会(10月19、20日)by 人人都是产品经理/起点学院。
目录
一、一线客服服务的业务架构
二、业务定制智能客服的特点
三、(重点)“知识”的产品化方案
四、(重点)“服务”的产品化方案
五、(重点)“人”的产品化与运营方案
六、结语
1
一线客服服务的业务框架
客户服务是一项包含甚广的宏观概念。根据MBA百科的解释,企业为了建立、维护并发展顾客关系而进行的,目标顾客满意与顾客忠诚的各项服务工作,均可以被认定为客户服务工作的范畴。
狭义上的智能客服直面用户,本质上是承担了客服角色中承接用户主动咨询的一线客服的职能。对于一线客服服务的业务框架,可以拆解为下图:
图中的客户服务的业务框架中,存在四项核心要素:
1、知识:企业生产、销售过程中的各项信息的合集。客户服务的结果,最终一般可以归结为与用户的信息同步或用户认可下的信息修改。智能客服的语料、答案等信息均属于知识的范畴。
2、服务:客服活动的最终产出物。对于一线客服而言,一般为有声(电话媒介)或无声(网页媒介)的实际对话与系统操作过程。智能客服为用户提供的服务,也是同样的表现形态。
3、人:具备客户服务能力的人的劳动,是转化知识、提供服务的具体执行过程。智能客服通过具备对话能力、学习能力等,使之具备了“人”的特性。
4、企业价值:提供客户服务的主体的利益点,约束另外三项要素。客户服务最终需要帮助其达成利益,智能客服也不例外。
2
业务定制智能客服的业务特点
本文中的业务定制智能客服,指由于存在强业务特性,无法通过市面SaaS智能客服方式直接满足,而需要以项目形式进行端到端开发与持续维护的智能客服产品。该类产品一般存在于具备较强自研能力,且拥有较庞大的自有客服团队或需付出较高客服成本的企业中。
业务定制智能客服与基于SaaS服务搭建的智能客服,在知识、服务、人与企业价值等四大业务要素上,均有所不同。
1、在知识层面,业务定制智能客服的答案与业务系统的耦合性一般较强,大量的答案甚至需要与人工的标准作业程序进行对齐。同时,需要引入更多的常识知识。
例如,对退款时长的问题,SaaS智能客服一般仅准备通常情况下退款时长范围政策,近年来开始逐步实现从财务系统中获取判断参数或者答案。
而业务定制智能客服的业务系统耦合要求会更强,判断顺序、分支粒度等需要与人工客服一致,对该问题需要建立囊括商品类型、订单类型等完整的内部影响因子,以及银行属性、银行卡状态等常识知识的知识体系。
2、在服务层面,业务定制智能客服往往需要向人工客服的服务效果看齐,实现足够灵活、自然、友好的对话的效果。
智能客服通过系统接口对接方式即可实现系统操作的服务,因此不同类型智能客服间在服务上的差异,主要表现在对话层面。例如,普通的SaaS智能客服一般只能提供单轮政策解释问答,近年来开始逐步普及针对某项任务的对话服务,通过多次交互执行某项系统操作。
而业务定制智能客服,在此基础上,往往还需要从人工对话效果中吸收更多的元素,为智能客服进行专门化的服务设计,实现正常回答外附加补充提醒、针对用户情绪变化话术、向用户确认是否已解决问题等,甚至逐步搭建出符合企业期望的,可接近于人工服务效果的、具备机器人特点的服务流程。
3、在人的层面,由于在知识、服务两个层面中更高的要求,因此一方面需要智能客服具备更强的业务理解、学习与转换能力,另一方面在对话引擎上也需要有额外设计。
落地在实践中,首先,相较SaaS智能客服,业务定制智能客服对训练师团队的需求更强烈,对训练师的业务掌握程度也有更高要求。同时,也往往需要为知识转换这一环节设计专门性的工具。
其次,一般对话机器人常用的检索式、填槽式、生成式对话架构,往往还不足以应对业务上进行专门服务设计,以及知识库改造后对对话引擎的要求,需要从产品与技术层面考虑更多的外围模块与定制化策略来解决。
4、在企业价值层面,企业对业务定制智能客服的利益期望会与人工客服逐步对齐。
不同于SaaS智能客服较为单纯的成本考量,人工客服考核中常见的服务满意度、问题解决程度、业务知识掌握程度、服务态度、服务流程准确度、投诉比例等指标也会出现在企业对业务定制智能客服的考核指标中。在一些对智能客服较为成熟的企业,客服管理层甚至会将智能客服与人工客服一并纳入业务管理范畴内。
究其本质原因,是随着智能客服能力的逐步提升与流量的逐步承接,智能客服已经成为企业服务过程中不可或缺的一环。客户服务这项企业工作所蕴含的“体验”、“企业形象”等本质要素,也必然在智能客服上得以呈现。
综上所述,业务定制智能客服与普通的SaaS智能客服,在业务要素上的区别总结如下:
3
“知识”的产品化方案
“知识“的产品化,最核心的部分即是对知识库的构建。
如同《如何构建客服机器人的知识体系_@Wing》一文中分享的内容,智能客服的知识库可分为QA类结构化知识库,KBQA类半结构化知识库与基于聊天日志的非结构化知识库三类。对业务定制智能客服而言,知识库需要在三类知识库基础上,重点解决以下四项问题:
1、支持大量引入业务系统信息与常识知识后,知识库仍可具备良好的可解释性;
2、支持同一场景维护多解决方案;
3、支持突发性信息的知识构建;
4、训练师的维护成本可控。
问题一:支持大量引入业务系统信息与常识知识后,知识库仍可具备良好的可解释性
客服组织作为直面用户的重要渠道(尤其在售后),天然具备风险规避的倾向(无论是基于减少投诉的考虑,还是由于需要依赖其他职能部门真实解决的限制)。因此,这直接导致在客服知识库核心部分的构建中,在业务上会偏好可控的结构化、半结构化知识库,一方面初始构建过程更加可控,另一方面也能帮助在运行中出现知识缺陷时快速修复。
为了解决业务系统信息与常识知识引入后的可控性问题,一般会引入可解释性最强的状态机类结构化知识库对客服业务知识进行构建。可解释性,核心体现在状态机输出的任何答案,智能客服训练师可通过逻辑的分支结构,明确地对其解释输出理由,从而达成可控目标。其本质与人工客服进行回答时,清晰明白回答理由,语出有因,是同样的道理。例如下面这个case——
状态机类知识库,与QA、KBQA类知识库,可组合使用来构建核心业务知识库,以结合相互的优点。一般常见用法如下表所示:
问题二:支持同一场景维护多解决方案
针对该问题,在知识库构建上,一般可以用多答案方式解决。如上文的状态机结构化知识库,即可以如下图所示来引入多答案模式。后续在应答过程中,需要结合其他对话模块来实现多解决方案应答的效果。本文第五部分中将继续介绍。
问题三:支持突发性信息的知识构建
由于生产过程中的不可控因素影响(如突发热点事件、天气变化、政策变动、内部信息同步不及时等),时常需要客服应答在一天左右的响应时间内完成变更,且持续时间常无法准确评估。在如此短的时间内,人工一般无法完成对知识的结构化梳理与定义,而只能完成较原始的问答内容堆砌。
对应的,知识库也需要构建一类临时知识库,一般采用QA方式组织,以适应此类知识来源情况。在应答时,临时知识库一般先于核心知识库被对话引擎调用,且在相似度阈值等参数设定上要求更为严格。
问题四:训练师的维护成本可控
知识库维护工作同样符合二八定律:20%的长尾流量问题,如果需要训练师来人工维护,需要花费数倍于常见问题维护的时间与精力。所以长尾问题一般需要通过强自动化手段来协助,以减轻训练师人员的负担。此外,临时、核心两类知识库,一类往往事出突然,一类需要杜绝风险,自动化发挥的空间均有限。
因此,长尾知识库自动化,成为了当前知识库构建中,AI深度介入较易推行与有较高可能性的产品领域。例如基于自动挖掘聊天日志或其他数据来源生成的非结构化知识库,即是长尾知识库的常见选型方案。在对非结构化知识库的直接应答效果不够有把握时,也可以通过协助挖掘QA,最终由人工配置或审批的方式来快速构建QA知识库。
最后特别补充一点,在实际业务场景中,客服知识并不一定完全掌握在客服部门。通过系统对接方式引入外部已封装的知识库,也是有效的解决临时、核心知识库的方案。
总体来看,为了解决上述四类问题,业务定制智能客服常常需要构建如下的知识库体系,并根据知识的结构情况选择适合的技术方案:
4
“服务”的产品化方案
服务的产品化,本质是通过有意识的服务设计,实现服务标准化的过程。而智能客服产品的“服务”,核心最终需要以对话得以体现。因此,基于服务设计理念进行对话设计,也成为AI时代产品经理的必需工作。如同移动端的人机交互设计,也是移动互联网时代C端产品经理的重要战场一样。
百度人工智能功能交互设计院(Baidu AIID)是在国内对话交互设计领域较为领先的专门机构。其发布的《会说话的人,一开口就赢了》一文中提出了当前国内比较完整的(对话)话术设计原则:
由于无论是客服行业,还是对话机器人领域,标准化话术体系的建设都尚处于早期。因此,笔者目前先参考上述会话原则,并吸收人工客服的话术经验,谈一谈智能客服的对话设计中的关键点。这些话术设计原则,除了对产品设计有指导意义外,还会强作用于训练师的运营工作中:
1、以目标为中心:客服场景不是聊天场景,天然具有逐步收敛,直至解决用户诉求的特点。目标收敛是智能客服话术设计的中心。但是用户表达诉求时,必然出现表达不清、表达不足等情况,若不加以处理,会话将最终失焦并混乱。
在日常的人-人对话中,我们会使用反问、确认等话术来解决这些问题。在智能客服对话设计中也同样需要考虑设计类似的澄清、引导话术(下图给出了一个常见的对话情况-话术结构图)。
2、准确&简洁:业务准确是客服服务的基本要求,而简洁则是从减轻用户理解负担出发的体验设计。但是,在实践中,这两点可能存在一定的冲突:准确的信息,往往会难以用简洁的方式完善地加以表达。人工客服为了免责考虑,往往采取的是复制大量文本,以不简洁的方式进行表达。
在智能客服对话中,可以考虑采取一些改善手段以同时达成两个目标:将长文本分句输出,对于大段政策场景往往比较适用;简化对话文本,附带参考信息链接,在部分复杂业务情况下也可施行。
3、自然&个性:一般而言,口语化的文本更适合客服这一需要亲和力的场景。但是,体验自然的话术的可靠产出方式,常常是解决这一问题的核心难点。在个性层面,客服领域大多偏好采用年轻女性形象。
“NLG生成”方式,目前已可以较好的解决闲聊话术自然性、个性化的问题。但由于客服服务的业务性要求,不可能完全采用无人工介入的(客服业务方也很难完全信任)生成方式解决这一问题。
笔者认为,将NLG作为话术工具,人工审核是一项可行方案。若NLG效果不佳,纯人工编辑答案时,区分业务答案编辑组与话术编辑组,相互结合生产最终答案,也可以达成比单一小组更好的话术自然度与个性化效果。
话术重复也是影响话术自然度的重要问题。在NLG手段使用受限的客服场景,一般采用策略性的方案解决,本文第五部分将具体提及。
4、友好:客服服务直面企业的顾客或潜在顾客,天然存在友好性的要求。AIID的文章中,对于友好原则列举了三点建议:错误归于机器;避免要求用户按照特定方式表达;体现关注用户需求的服务态度。
在客服的日常培训中,也可以找到类似目的的具体话术或者流程方案建议。例如,无论是什么原因,服务中先道歉再解答,匹配的是“错误归于自身”的建议;向用户确认需求而非告知用户方案,匹配的是“避免要求用户规范表达”的建议;在用户诉求被解决后,向用户确认是否有额外需求,以及补充相关事项信息,匹配的是“关注用户需求”的建议。诸多客服手册中强调的情绪安抚,也可以归入关注用户需求的范畴。
因此,各位产品经理可以多深入了解下所在公司的客服业务规范或培训指南,其中很可能存在解决智能客服服务友好度问题的答案。
最后需要特别强调的是,在客服场景中,感性原则的重要性会较比IOT等场景有较大提升。核心原因在于在客服场景中,用户诉求中的情感诉求往往不亚于问题解决诉求(大家可以想想,自己是不是也有“找客服,就是去讨个解释”的情况)。因此,自然、优化、个性等话术设计的感性原则,应该被产品经理们纳入重要考虑因素中。
从实践来看,优质的对话设计,可以有效提升用户触达最终答案的可能性,并反映在满意度等调研指标中。究其原因,笔者认为一方面是优质话术可以规范用户的言语表达并缩短对话轮次(短且规范就不容易出错),另一方面则是在用户感知到是机器人服务并得到解决时,对话技巧或者关键时刻的应用提升了用户对机器人的好感。
5
“人”的产品化与运营方案
人,在客服业务中的价值是转化知识、提供服务。因此“人”的因素,落脚在智能客服的产品设计中,即转变为知识转化机制(工具、团队与流程)以及对话引擎两方面。
1、知识转化机制
如《MBA智库:客户服务管理》(https://wiki.mbalib.com/wiki/客户服务管理 )所言,客户服务的外延可以囊括企业的几乎所有服务内容。以电信运营商的客服服务范围为例,即包括了号码、话费、手机、积分、宽带、增值服务等几大领域的购买、充值、查询、消费等各项业务。面对如此繁杂的业务,业务定制智能客服一般需要在客服业务方组建一个专门的智能客服训练师团队,专门进行客服知识向机器人知识的转化。该部门的人员选择、培训与工作流程可以专门著文介绍,此处就不再展开。
知识转化的过程,可以区分为事前转化与事后转化。事前转化主要出现在构建一个新场景的知识,或者需要对一个场景进行知识重构时。事前转化产出的结果,是根据业务逻辑或业务流程,对于业务场景的客服应答方案的结构化完整展示,可命名为业务蓝图。下图表示了业务蓝图的一种展示方式:
对业务蓝图的梳理是构建对话方案的基础,但由于是一项严重依赖经验的工作,在大多数情况下难以承担一次性梳理完整的人员与时间成本。因此,知识转化离不开事后转化的帮助。
事后转化,主要指场景在正常应答后的持续调优中,所进行的知识补充。知识补充可以从知识的生产端与消费端两处入手:
生产端入手,也就是从人工客服的知识来源中获取知识。大型客服中心都有自身不断在运营维护的知识库。但常见的知识库,都是文章等非结构化的状态,难以被智能客服直接利用。同时,人工客服的大量知识来来源于邮件等非正式渠道。因此,机器阅读工具是该类转化方式中所必须依赖的工具。通过机器阅读工具自动将客服新增知识点转化为简易QA,或简单的知识图谱,再转由训练师完善智能客服的现有知识库。
消费端入手,也就是从实际应答的聊天日志中获取知识。通过日志挖掘工具,同时在人工、机器的聊天日志中进行挖掘,可以有效发现现有智能客服知识点的覆盖盲区以及人工的可用回答,从而再转由训练师进行知识更新。
由于事前转化面临的各项困难,事后转化的完善程度可能将会是未来业务定制型智能客服的核心竞争优势。在这一领域,笔者尚未了解到市面上存在完整的解决方案,还有待继续探索。
2、对话引擎
在智能客服的产品体系中,对话引擎扮演了将知识根据“服务设计下的对话效果”进行应答的关键角色。发展至目前,工业界中对话机器人的主流对话框架仍为检索式、填槽式与生成式三类,智能客服也不例外。因此,笔者在此主要就智能客服对话实现中涉及的、因知识库与对话设计要求产生的几个对对话引擎的特殊需求,介绍其产品设计要点。
1)可控对话流程
面对知识库中,同场景多解决方案的情况,一般需要设计专门的会话状态体系,与意图识别模块配合应答。
例如,当输出答案A后,设定会话状态为“业务应答”,并定义优先识别项目;此时若用户下句表达了符合条件的语句,则在不变动会话状态的情况下优先从知识库内寻找新答案。由此,可实现在业务应答中的流程可控。
对业务应答外,也可能存在可控流程需求。如上文提到话术设计中,“确认额外需求”的语句需求,可以通过定义会话状态与专门答案的方式实现(如定义业务应答后用户首次反馈肯定句,变化会话状态为“其他需求确认”)。
2)基于知识库答案粒度的澄清与引导
一个业务认定为合理的知识库切分粒度,与根据NLU准确率最优所得到的意图粒度,可能并非完全一致。这是算法与人对业务的处理偏向不同所必然产生的结果。常见情况,一般是算法认定的清晰意图,尚未达到人工应答所需要的意图清晰程度。
因此,一般需设定一专门的意图澄清模块,根据算法输出的意图,针对所关联的知识库,以答案粒度来进行反问引导,方可串通整个业务应答流程。下图中演示了一个案例:
当然,也可以通过细化NLU识别结果的方式达成无需澄清的目标(暂不考虑算法能否实现)。但由于知识库会跟随业务变动不断更新,如果NLU识别跟随知识库不断调整,消耗的训练师成本会进一步放大。反倒是算法后退,辅助一定的工程逻辑,从总体运营效率上会更高。
3)话术变化
话术设计中,存在自然度的要求。但由于难以直接使用NLG方式解决重复话术问题,因此,一般在对话框架中,需要设计专门的话术处理模块,在最终应答环节进行处理。常见的处理方案,一般设定为循环输出预制的多套话术,或固定在答案内附加一定语句。
4)情绪感知与应用
感性原则是智能客服话术设计中的重要因素。因此,一旦可对用户的情绪变化进行感知,与用户意图相结合,即可在答案选择、话术变化、安抚等方面发挥价值。目前市面上多分类情绪模型已较为成熟,可以满足工业应用的准确率与粒度要求。
结合上述特殊策略后,可大致将面向解决复杂、全面业务问题的业务定制智能客服的对话引擎梳理如下:
6
结语
笔者在本文中,从对客服业务框架的拆解出发,对业务定制型智能客服各方面的产品设计要点做了简要介绍。在未来一段时间内,业务定制智能客服将仍是真正能帮助大型客服中心达成业务目标的重要系统之一,也是AI落地的主战场之一。希望越来越多的同学一起加入到对该领域的探索之中。
附:团员@苍狼剑歌的相关文章
《「超越问答」关于智能客服产品中引入“流程”要素的一点思考_20190603》(https://shimo.im/docs/23cX9f4JE1khfvzh )
----hanniman读者专属福利----
优惠券 for 三节课 5门核心课程
1、《产品经理P1(入门)系列课程》(开课10月24日,20:00 ,第46期)
2、《产品经理P2(进阶)系列课程》(开课时间10月31日,20:00,第29期 )
3、《产品经理P3(高阶)系列课程》(开课时间 11月15日,20:00,第5期 )
4、《策略产品经理课》(开课时间10月31日,20:00,第20期 )
5、《互联网业务数据分析实战》(开课时间10月17日,20:00,第17期 )
(注:如果大家下单时间已晚于开课时间,只要没超过1~2天,还可以通过我来申请插班)
具体课程详情、优惠券获取及使用方式,可见 https://shimo.im/docs/99GwY9H8QXGHD83r (复制链接到浏览器打开,或点击最后的“阅读原文”入口)
简单说,申请方式是
已加过我微信的读者,可直接微信联系我;
未加过我微信的读者,本微信公众号后台回复你的申请信息:公司+职位+微信号+手机号,我再直接联系你。
优惠券 for 上海产品经理大会(10月19、20日)
活动名称:2019产品经理大会·上海站
主办方:人人都是产品经理、起点学院
时间:10月19日(本周六)-20日(本周日)9:40-17:30
地点:上海东方万国宴会中心(上海市浦东新区新金桥路1599号)
hanniman读者专属福利:普通票-原价499元,hanniman读者优惠价349元,便宜了150元~
大会分享嘉宾及获取福利方式,详见:https://shimo.im/docs/Cd3R3vdYwjXj3pYr (复制链接到浏览器打开)
JD-杭州-一知智能-AI产品经理(对话平台方向)
杭州地区不多的高潜AI创业公司“一知智能”,正在寻找机器人对话平台方向的AI产品经理,有QA/智能客服/知识图谱/VUI/语音交互产品相关从业经验者优先,JD详情、公司介绍及投递简历方式,可见:https://shimo.im/docs/qj8Vj8XD9CYcYghx (复制链接到浏览器打开)
-END-
- hanniman往期精选 -
一、AI产品分析
【重点】如何从“品类”角度做AI产品(2C)的需求定位
【重点】产品视角看智能客服
【重点】智能音箱上的语音技能市场,能否对标手机上的应用市场?
【重点】进击的人工智能:产品视角解析“对话机器人”
【重点】如何从零开始搭建智能外呼系统
现阶段实践“拿着锤子找钉子”的六个步骤
二、AI产品经理
【重点】【重磅福利】人工智能产品经理的新起点(200页PPT下载)(注:后台回复“200”,可获取PPT下载链接)
【重点】AI产品经理的定义和分类
【重点】AI产品经理的价值和未来 | 学习俞军老师分享有感
团员分享_AI小白如何拿到AI产品经理offer
深度报告 | AI新职位“人工智能训练师”
福利 | 《从互联网产品经理到AI产品经理》PPT下载及讲解(58P)
三、AI技术
【重点】AI产品经理需要了解的语音交互评价指标
【重点】语音合成TTS | AI产品经理需要了解的AI技术概念
【重点】一文看懂“语音识别ASR” | AI产品经理需要了解的AI技术概念
【重点】值得收藏 | 关于机器学习,这可能是目前最全面最无痛的入门路径和资源!
【重点】“AI芯片”通识_AI产品经理看这一篇就够了
【重点】人脸识别产品设计,AI产品经理需要了解的实战干货都在这里了_团员分享_@阳春柏樰
NLP基本功-文本相似度 | AI产品经理需要了解的AI技术通识
看AI产品经理如何介绍“计算机视觉”(基于实战经验和案例)
人脸识别 | AI产品经理需要了解的CV通识(二)
多目标跟踪 | AI产品经理需要了解的CV通识(三)
填槽与多轮对话 | AI产品经理需要了解的AI技术概念
AI产品经理需要了解的数据标注工作入门
语音识别类产品的分类及应用场景
四、AI行业及个人成长
【重点】【深度】工作5年以上,到底要不要进AI创业公司?
【重点】深度 | 人工智能让我们失业?不,这取决于我们自己
【重点】我们还没准备好和AI共生——柯洁和AlphaGo大战之观后感
【重点】AI产品经理视角下的V2X、车联网和自动驾驶
“人工智能与法律”对AI产品经理有何实际借鉴意义
稻盛和夫的这些话,是鸡汤还是干货?
跨过这十个误区,提前2年告别职场小白
【重点】如何分辨明师并遇到他 | 周日换频道(7)
---------------------
黄钊hanniman,前图灵机器人-人才战略官/AI产品经理,前腾讯产品经理,6年AI实战经验,9年互联网背景;垂直于“AI产品经理”的第一自媒体,微信公众号/知乎/在行ID“hanniman”;行业内第一个AI产品经理的成长交流社区-饭团“AI产品经理大本营”的创建者(已运营2年,活跃成员700人);200页PPT《人工智能产品经理的新起点》被业内广泛好评,下载量1万+。