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

产品设计概述：

客服机器人在应用层隶属于智能客服范畴，从业务流程上看，智能客服是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协议