文章以物业客服的人工智能为例，从业务流程、语音收集、知识库、设计四个方面分析了产品的需求，简述了智能客服落地的全部过程。

写完题目感觉起大了，其实感觉现在也还是个人工智障：)

一、前提

随着人工智能的兴起，机器人客服也开始成为互联网公司在线服务的标配前置。我所在公司当前的业务范围涵盖物业和业态（电商、到家、广告、保险等）多维的服务，原来APP端只接入了业态相关的在线，每天的会话量级只有几百左右。

物业服务在公司呼叫中心的占比大约是业态服务量的几十倍，因此业务方希望在APP端开通物业在线的功能，同时前置智能客服机器人，实现对呼叫中心话务量的分流，同时也满足部分习惯使用在线进行交流的用户的需求。

1.1 价值预估

通过下面的电话和在线的漏斗图可以看到期望的拦截路径。通过对工单频次进行分析，已经在电话端上线了高频分类的IVR功能，日均可以实现30-40%左右的人工拦截量。

其中门禁、代收包裹电话自助功能用户的使用黏性和评价都较高。对于在线服务，期望初期能分流20%的电话量，并逐步提升到50%。同时机器人能够实现40%左右的在线拦截率。

 电话漏斗图

在线漏斗图

1.2 实现路径

先开通APP端物业在线服务积累用户语料，从电话端引流到在线端，培养用户通过在线进行物业咨询和报事习惯。后续通过灰度发布，逐步开通各个社区的智能客服，实现机器人的7*24小时服务。

1.3 场景选择

智能客服应该优先解决哪些问题，支持哪些交互方式，用户有哪些高频的问题和场景，这些需要通过对历史的工单数据进行分析来提取。

从呼叫中心工单分类报表和APP端服务访问频次，我们提取出来四个高频操作场景：访问通行、园区报事、房屋急修（户内报事）、生活缴费。

物业咨询相关的问题通过QA和FAQ来实现：

二、语料收集

物业相关的语料较为垂直，同时和自身的业务耦合较高，放弃了从公开语料库获取的思路，打算从积累的电话录音和在线的语料中进行提取。

2.1 在线语料

获取历史的在线会话记录，抽样进行语料标注，作为测试集。

2.2 语音标注

呼叫中心记积累了百万级别的通话录音，通过语音转写和人工标注，作为语料喂养给NLP训练使用。

（这部分成本较高，使用了科大讯飞电话专用版进行预转写，平均转写成本0.1元/条，人工标注成本3元/条。每次购买服务的时候都感觉心在滴血）

2.3 业务&AI产品编造

根据业务场景，编造部分语料进行机器人训练。

三、 知识库

前面已经根据业务场景，梳理出机器人一期支持的场景为操作类和问答类，这两种分类的区别度较大，分类设计知识库维护后台。

3.1 知识库维护后台

1) QA类型知识库：

查询

新建

2) 操作类知识库：

查询

新建

3.2 维护方式

业务可以通过Excel按照模板收集后，批量导入。也可以通过编辑后台对单个知识进行新增和维护。

3.3 寒暄

由于用户问法的发散性，机器人无法命中所有问题，如果出现无法识别的情况就反馈无法理解，对于用户来说就像和智障（大误）在交流，很快就回失去耐心。

通过寒暄库可以提升机器人聊天的体验，设置部分有意思的对话内容，也能让用户感受到机器的幽默和温暖。

毕竟，我们的slogon是：做有温度的机器人。

寒暄库这块使用了图灵机器人，可以方便的定义问法和回答，还支持天气等查询的功能。

四、设计

4.1 交互方式

针对当前的业务场景，一期做了简化，不支持富文本，样式只支持文本，链接和操作类。后期规划增加地址卡片等视图。

1. 文本
2. 链接
3. 操作
4. 反馈

反馈的功能很必要，相当于在线客服中的评价，因为AI后台只能识别出用户问题是否命中了具体的回答，但不知道回答有没有解决用户的诉求。

加入反馈的功能，可以让用户进行自主的反馈。

反馈占用一定的页面空间，理论上所有的回答全部加上反馈最好，但是这样对于用户的交互体验上就会大大降低。

因此需要业务人员分析哪些问题不确定需要反馈，一次会话中不超过3次的反馈为宜。

4.2 页面设计

确定基准色：

视觉给出两版色彩稿，冰蓝色和橙色。冰蓝代表机器和智能的冷酷感，橙色是APP主色调，温暖。

经过调研后大家最后选取橙色进行UI设计，保持和主APP色调一致，同时体现出温度感（Slogan默默的招手）。

根据原型和UED的同事沟通机器人的目的和期望的形象。在定义上我们希望用户能直接意识到是和机器人在交互，而不是误导用户在和人工客服对话。

所以在顶部展示了机器人的头像，点击可以进入到介绍页。

Q：是否展示头像？

A：使用用户头像，用户感知上更加友好，但是聊天框会较短。APP端产品给出用户自定义账户头像的比例比较低。通过和设计同学沟通，对比有无头像两版设计稿，最终选取不使用用户头像的设计方案。

Q：输入方式是先语音还是先文本？

A：希望引导用户使用语音作为第一交互方式，同时普通话短句的文字识别率达到90%以上，采用先语音的方式。用户可以切换键盘输入。

Q：用户语音输入之后，是展示转写结果等待确认还是直接发送？

A：直接发送，减少交互步骤数。缺点是转写错误无法修改，对于后台自动纠错能力要求比较高。为什么不保留语音，因为机器人交互的后台最终还是通过文字进行识别，语音对于AI是没有意义。

Q：人工客服入口如何设置？

A：人工客服的入口过于明显，会导致用户跳过机器人直接使用人工客服，无法起到机器人分流作用。人工客服入口过深，用户无法找到人工入口，机器人无法解决用户问题时导致用户体验急剧下降。采用方式：右上角常驻转人工入口图标，但是不使用文字说明，减少直接曝光度。用户交谈过程出现3次无法识别，会话内容提示转人工。

下面的问题留个大家思考，最后的实现方式上，我们也因为资源等问题做了不同程度的取舍，有机会在细谈这部分：

• Q：如何定义会话？
• Q：如何展示聊天会话的时间？
• Q：语音输入的长度限制？
• Q：历史会话如何加载？

4.3 异常情况处理

• 弱网环境提示
• 服务器长时间无返回提示
• 无录音和麦克风权限提示

五、埋点和效果回收

智能客服需要不断的迭代优化，知识库也需要不断的补充和修改，因此需要对命中效果和用户反馈做统计，支撑后续业务部门和机器人产品对于智能客服的不断优化。

这部分展示通过后台的数据库进行分析统计，没有前端页面，不做过多介绍。

通过关键词正则匹配-NLP模型匹配两层命中，上线前在训练集达到了100%的准确率和召回率，测试集综合能有70%以上的准确率。

六、成果

这篇主要讲了整个智能客服落地的全部过程，其中有对业务和竞品的思考，也有受限于资源的妥协。后面有时间再拆分详细讲其中的某些点。

本文由 @还酹江月 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash ，基于 CC0 协议