如何基于自然语言,优化美团外卖客服机器人产品?

1 评论 6461 浏览 70 收藏 14 分钟

客服机器人承接的是上游服务的问题,自身业务需求是对问题的自动化处理,向下游输出的是用户反馈信息的整合。那要如何基于自然语言,优化美团外卖客服机器人产品?

产品设计概述:

客服机器人在应用层隶属于智能客服范畴,从业务流程上看,智能客服是APP端上业务与人工客服的中间层。APP端上游分发的服务出现了问题,用户通过智能客服进行咨询投诉反馈,如果解决不了问题,再将用户及问题引导到人工客服进行处理。

整体上看,客服机器人承接的是上游服务的问题,自身业务需求是对问题的自动化处理,向下游输出的是用户反馈信息的整合。

所以产品设计上,会从三个方面概述:如何承接上游业务、自身业务设计、如何向下游输出。同时会简要的概述如何设计后端产品,对前端的机器人进行更好的辅助。

整体的框架设计如下:

前端产品

1. 承接上游业务

外卖业务由于时效性较高(餐品的质量问题、配送时效问题等)、参与的角色较多(用户、骑手、商家、平台),所以出现纠纷或者异议的情况会很多。

此外,由于外卖衍生的垂类业务较多(优惠券、准时达等),用户一次性接受较为困难,所以用户可能会咨询客服相关的知识问题,了解不同的细分垂类业务。

如果所有的用户都到人工客服咨询问题,会造成两个问题:

  1. 客服进行量大,增加人工客服成本,同样的问题,客服可能会一遍一遍的回答不同的用户,造成资源的浪费;
  2. 用户等待时间较长,人工客服资源有限,都进线咨询,等待客服接线的时间就变得很长,用户体验较差。所以为了承接上游业务产生的两类问题(服务问题、咨询问题),设计一款客服机器人,帮助用户解答问题。

2. 机器人自身业务

2.1 咨询问题

针对用户对于产品的使用困惑,比如说:不知道优惠券如何使用,我们可以针对这类咨询问题。用户进入人工客服,期待的结果也只会是客服告知使用优惠券、优惠券中心的入口在哪儿怎么查看等。

我们可以设计一问一搭的QA问题,或者常见问题分类进行展示。两者的区别在于用户主动和用户被动,QA形式,更多的是用户通过打字或者语音的方式输入,机器人后台识别问题之后进行回答。

而FAQ展示,是用户看见了FAQ问题分类的大类,认为里面可能有想要的解答,就点击进去寻找问题小类,最终找到答案。

两种交互方式的示意图如下:

两种模式应该并存,让有不同使用习惯的用户都可以按照自己的方式找到问题的答案。虽然两者交互上存在差异,但是后台的支持,都是相同的。都是通过知识库来支持两者,具体的知识库建设后面会提到。

2.2 服务问题

对于服务问题,可以根据历史的数据,整理出热点的top问题,再根据每一个top问题,梳理客服处理问题的流程,再从算法层面借助这样的流程形成规则,然后对用户的问题进行服务。

这里做一个大胆的猜测:“骑手提前点击送达”会是一个常见的问题。

这个场景在我点外卖的过程中经常会遇见,骑手为了不超时送达,提前点击了已送达。用户遇到不公平的对待,肯定会咨询客服反馈。但我们还是按照之前的咨询问题来看待,未免不能通过引导很好的解决问题。因为引导的话语,无非是让用户进入到人工客服进行咨询。

但我们可以假象一下人工客服的处理流程,用户进线投诉骑手提前点击送达,客服首先进行安抚,随后确认订单,之后进行核实,最后将核实的结果及处罚的措施告知用户,并给出相应的赔偿。

这一套流程我们可以通过整理形成一套流程,再通过算法的接入形成一个规则,以多轮交互的形式在机器人帮助用户解决问题。

具体的交互形式如下:

左图为美团外卖的现状,没有判断问题的流程复杂程度,只给出了大段的话术引导,易读性差且用户的成本变得很高,右图为理想的改进版本,只需用户逐步的按照规则提示,就可以快速的完成投诉。

这种服务问题的建设,在优化了用户体验、减少用户操作成本的同时,也可以对外输出能力。比如:针对骑手提前点击送达的问题,系统的判断环节可以输出为借口,为人工客服服务,这一部分会在后面详细阐述。

2.3 机器人整体风格

机器人的整体风格,可以从上下游承接的关系进行设计。上游出现服务问题或者咨询问题,进入到机器人询问。那么机器人就应该对这两类问题进行主动的发问,减少用户感知的成本。

而我们通过“骑手提前点击送达”这个场景判断,服务问题不能用简单话术引导,原因是需要不断地确认用户的信息(用户订单、订单状态等),而外卖的服务问题或者投诉,与订单的耦合很大,所以我们可以在进入到机器人的时候就弹出订单,并给出已经拥有的服务问题多轮交互,满足用户的服务问题诉求。

同时,针对于用户进行咨询问题的诉求,可以配置大类的问题,引导用户点选,逐步的找到问题答案。

改版后的机器人首页如下:

机器人首页推荐出最近一笔订单,下方配置的是具有多轮交互的场景问题,满足用户的服务问题。右侧是常见问题,配置的是大类的问题,用户点击后可以逐步展示细分分支,最终得到答案,满足用户的咨询问题。

3. 下游输出

机器人的交互形式,不会被所有的用户认可,部分用户更习惯传统的人工客服模式,认为人工更值得信赖。当用户从机器人转入人工的时候,如果可以尽可能多的带入信息,就可以免去客服与用户最初的信息核对流程,可以减少用户的等待时间,并降低客服平均每单服务时长。

同样的,信息的获取,也应该根据问题的类型分为两大类,服务问题及咨询问题。如果是服务问题,还需增加一步选择订单的步骤,让客服在接起的时候,就知道更多的用户信息。如果是咨询问题,选择完大类问题之后即可接入人工客服。

示意图如下:

后端产品

1. 知识库

机器人能够回答用户的问题,无论是一问一答的QA,还是具备多轮交互的服务问题,后台的支撑都是知识库。在前端页面展示的,是用户输入问题,机器人弹出对应的答案,在后台的流程比前端展示的要复杂的多。

首先,通过语义识别的技术对用户的语句进行分词处理,然后将关键词在知识库中搜索,如果匹配到对应的知识点,再将知识点对应好的答案弹出。知识点对应的答案,是人工通过对业务的认知,进行编写的。

这里的知识库,我理解应该通过知识图谱的方式进行数据的管理,即每个知识之间是有关联性的。之前提到的FAQ模式,首先展示出大类的问题,再逐步的细分,最后弹出对应的答案。

在后台数据层面,可以很好的理解成树状结构,树状结构模型可以自上而下的对问题进行分类整理,叶节点就是问题最终的答案。所以我们再通过后台数据结构来看FAQ与QA模式的差异,无非是首先进入这个树状结构的位置的差异。

  • FAQ的进入位置,可能更靠近根节点,走到叶节点的路径就长一些;
  • QA的模式,由于用户的输入更明确,分词之后的语义识别使得进入的位置更靠近叶节点,走到叶节点的路径也就更近。

而服务问题的结构,加入了节点的词性定义。知识点的词性不再都是名词,更多的加入了主谓语、主被动等词性。知识库的图谱结构可以较好地支持机器人的回答。同时,可以在知识库的基本能力之上进行赋能,可以作为标准知识对人工客服输出,作为人工客服的回答标准。

这样的做法有两个好处:

  1. 减少了人工客服查询规则的时间,提升服务效率;
  2. 人工侧与机器人侧统一答案,避免造成负面影响。

2. 智能辅助平台建设

“骑手提前点击送达”这个服务问题,我们提到了,可以将判责的环节作为能力输出。

算法可以生成模型,根据骑手的点击送达的位置与用户接餐的位置,进行系统的判断,加入规则之后输出为模型。人工客服只需要输入骑手的基本信息,就可以调用判断,智能高效的帮助用户,否则人工客服可能就得点击各种系统,查看骑手的当时位置,过程繁琐。

同样的,这种智能辅助平台的建设,也会有知识库建设的好处:

  1. 减少了人工客服查询规则的时间,提升服务效率;
  2. 人工侧与机器人侧统一答案,避免造成负面影响。

3. 工单系统

工单系统对于整体客服层面的建设有着至关重要的作用,无论一个用户的问题由机器人解答,还是由人工客服解答,亦或由机器人流转到人工客服。当我们后续对此case进行review的时候,我们需要工单系统的辅助。

此外,人工工单量和机器人工单量也可以作为后续的KPI考核指标进行评估,从宏观角度审视两者孰好孰坏。

#专栏作家#

Mitsuizq,微信公众号:画图码字实习生,人人都是产品经理专栏作家。关注AI领域。

本文原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!