一文读懂智能客服：发展历程、系统搭建、市场推广

在人工智能领域，智能客服是比较容易落地，且技术比较成熟的一项应用实践。本文以智能客服为对象，梳理了它的发展历程、系统搭建、市场推广。enjoy~

2018 I/O开发者大会上，谷歌演示了对话机器人Duplex。

Duplex完成了两项任务：

• 第一项任务，预定理发服务；
• 第二项任务，一个预定就餐的电话接待。

实际上，Duplex扮演的就是智能客服的角色。

在人工智能领域，智能客服应该是比较容易落地，而且技术比较成熟，这是因为客服领域的场景路径具有相对明确的特征，决定了基于全量数据进行高并发需求处理的人工智能在客服领域将大有可为。

目前，基于大数据、云计算和深度学习等领先的人工智能技术，智能客服已经可以实现自主问答、业务办理、故障诊断等一系列复杂操作，实现客服行业中大部分的应答需求，快速高效的解决用户问题。

据2018年5月发布的《中国智能客服行业研究报告》统计，中国大约有500万全职客服，以年平均工资6万计算，再加上硬件设备和基础设施，整体规模约4000亿元。

如此巨大的市场，当然会使得众多企业对于智能客服趋之若鹜。但是为什么到现在还没有一家独角兽公司出现？

虽说这是人工智能中最容易落地、技术相对成熟的项目，但相关企业如果想开发和构建一套人工智能客服系统，到底要投入多大的成本？

一家企业是自己搭建一套智能客服系统，还是找到一家合适的智能客服平台厂商，站在“巨人”的肩膀上，利用它们赋予的能力，搭建自己的智

能客服解决方案。

今天我们好好聊聊。

一、客服系统的发展历程

中国客服软件市场大致经历了三个发展阶段：传统呼叫中心软件、PC网页在线客服+传统客服软件、云客服+客服机器人的智能客服阶段。

• 2000年以前，互联网尚未普及，客服主要以电话沟通为主。
• 2000-2010年间，得益于计算机技术、计算机电话集成技术（CTI）、网络技术、多媒体机技术以及CRM、BI、ERP、OA等企业信息化应用的集成，客服系统跳出单一的电话沟通出现了网页在线客服等多种客服渠道。
• 而过去近十年，移动互联网、云计算、大数据和AI技术的发展又将传统呼叫中心和客服软件带入了SaaS和智能化时代。一方面全新的SaaS模式使得企业搭建客服中心的成本大大降低，SaaS模式逐渐普及，早期提供呼叫中心硬件设备的厂商已经延伸到中下游，为外企、国企等大型客户提供本地客服中心解决方案。

从当前客服产业链构成情况来看，上游基础设施环节已经发展成熟，少数巨头垄断市场。未来，他们会继续向下游延伸，构建企业服务生态。

中游客服产品提供商中，云客服厂商经过几年竞争，头部几家已脱颖而出，但仍未长出巨头，竞争依然激烈。产品功能更加丰富，应用场景也从客服延伸到了销售、营销等多个环节，另一方面，客服机器人通过辅助人工，以及回答简单重复性问题，大大提高了人工客服的工作效率。同时，AI也在从各个环节上变革着企业客服的交互方式，加速线上线下客服的智能化升级。

二、智能客服系统搭建

智能客服系统主要基于自然语言处理、大规模机器学习、深度学习技术，使用海量数据建立对话模型，结合多轮对话与实时反馈自主学习，精准识别用户意图，支持文字、语音、图片等富媒体交互，可实现语义解析和多形式的对话。
任务对话服务：
定制化服务，通过与用户的多轮交互，实现快递查询、订餐、医生预诊等服务类功能。
业务咨询服务：
通过QA知识库，快速回复用户问题咨询服务。解决常见问题的解答。

2. 智能客服系统的技术构架

（1）基于知识库回答的智能客服系统

基于知识库回答的智能客服系统，
使用的检索或者分类模型来实现的。

检索式回答的流程是：

• 首先对用户的输入问题做处理，如分词、抽取关键词、同义词扩展、计算句子向量等；
• 然后基于处理结果在知识库中做检索匹配，例如利用BM25、TF-IDF或者向量相似度等匹配出一个问题集合，这类似推荐系统中的召回过程；
• 由于我们是一个问答系统，最终是直接返回给用户一个答案，因此需要从问题集合中挑出最相似的那个问题，这里会对问题集合做重排序，例如利用规则、机器学习或者深度学习模型做排序，每个问题会被打上一个分值，最终挑选出top1，将这个问题对应的答案返回给用户，这就完成了一次对话流程。

在实际应用中，我们还会设置阈值来保证回答的准确性，若最终每个问题的得分低于阈值，会将头部的几个问题以列表的形式返回给用户，最终用户可以选择他想问的问题，进而得到具体的答案。

（2）基于槽位填充的多轮对话系统

搭建基于槽位的对话系统是一个相对专业而复杂的过程，通常分三个主要的阶段。首先是需求分析，然后是使用平台搭建 BOT，最后是持续优化。

了解该系统我们先熟悉一下几个名词的释义：

1）意图

意图是指用户在语音交互中发出的主要请求或动作。

意图示例：

• 肯定意图：是；对的；正确；Ok；
• 否定意图：不是；不对；错了；NO；
• 取消意图：退出；停止；关闭；结束；

2）技能

技能是满足用户特定需求的一个应用。例如用户说“查询我的洗发水快递到哪里了”时，会进入快递查询的技能。

3）问答型技能

通过Q（用户问法）和A（机器人回答）的配置，可以实现简单的用户与机器人的对话。

任务型技能：在问答型技能的基础上，增加槽位、API（接口）调用等高级功能，可以通过配置，来实现用户查询信息、问题搜索或者其他功能。

4）词典

某个关键词可能变化的内容，例如时间词典，位置词典。

语义槽：语义槽是用户说法中包含的关键词，它可以帮助系统准确识别意图，例如星座语义槽包含12星座的名称。语义槽和词典一般会同时使用，语义槽通常用来指代词典。一个语义槽可以同时绑定多个词典，一个词典也可以与不同的语义槽相关联。

5）追问

当用户问法中没有提供该语义槽值时，机器人要对其自动发起追问。

例如用户问：天气怎么样？我们无法获取到查询天气的地点的语义槽值，就需要机器人追问，您想获取哪里的天气信息？，追问话术一般设置多条，随机追问。

在国内开放的bot系统中，百度UNIT和微信的对话开放平台就是应用的该技术框架。

一个自然语言对话系统，理解的核心任务是对意图的解析和对词槽的识别。

例如：订明天早上8点北京到石家庄的火车，在这个例子中，对于用户表达的一句话， 它的意图是要订火车票，其中涉及的词槽包括出发地、目的地、时间 。当这个时间有多趟车次的时候，就需要进行追问用户，是要订哪一个。

以百度UNIT平台为例，搭建一个买票智能回复的流程。

1. 需求分析：订火车票需要知道时间、出发地、目的地
2. 新建一个BOT，命名为：火车票
3. 新建对话意图：命名订票
4. 添加词槽：出发时间、选择系统词槽词典，选择然后选择系统词典 sys_time(时间)，出发地词槽、目的地词槽，这两个都可以选择系统词典，这些都是必填项。
5. 设置词槽与意图关联属性，这里火车票的出发时间是订票里必须的关键信息，所以选择必填。澄清话术就是当用户表达订票需求的语句里缺少出发时间时 bot 主动让用户澄清的话术。还可以设置让用户澄清多少轮后放弃要求澄清，默认是 3 次。
6. 设置 BOT 回应，BOT 回应就是当 BOT 识别出用户的意图和所有必填词槽值时给用户的反馈。对于订票回复一般对接API接口，实现自动生成方式。

当然，这只是火车票中的一个场景，在火车票这个场景中还有退票、改签、查询等功能。这些都是需要我们在需求梳理中要确定的。

3. 如何评判一个智能客服系统的好坏

（1）基于人工标注的评价

基于问答知识库来回答的系统，回答能力受限于知识库的丰富程度，也就是说知识库对用户问题的覆盖率，覆盖率越高，准确性越高。

因此并非能回答用户的所有问题，系统最佳的状态是将能回答的全部回答准确，不能回答的全部拒识，即拒绝回答。

因此这里的评价指标包括有问题解决率、拒识率、召回率和准确率等，我们的目标是让系统的有结果率无限接近数据的真实有结果率，召回率和准确率尽量高。

• 召回率 = 机器人能回答的问题数 / 问题总数
• 准确率 = 机器人正确回答的问题数 / 问题总数
• 问题解决率 = 机器人成功解决的问题数 / 问题总数
• 拒识率=机器人未回答问题数/用户问题数

通过从每日的全量数据集中抽样出一个小数据集，保证小数据集的数据分布尽量符合全量数据集，然后由标注团队对数据集做标注，标注出每个问题的实际答案，一般标注完成后还有质检的环节，以保证标注结果尽量准确，这样便生成了每日数据的标准评测集。

基于该标准评测集我们会去评价系统的好坏，并且每次做新模型迭代时都会使用标准评测集去评价新模型，只有新模型达到某个指标才可以上线。

（2）基于用户反馈的评价

人工评价能够评价智能客服系统的准确率，但是答案是否合理，能否为用户解决问题，需要用户去反馈评价，整个智能客服系统的最终目标是帮助用户解决问题。

我们会在产品上设计智能客服和在线客服的评价功能，例如会让用户评价智能客服的每个答案或者某次会话，在和人工客服聊天完毕会发送评价卡片给用户去评价满意度，如下图所示。

最终我们会统计参评比例、满意度等指标，这些指标能够真正反应智能客服系统的好坏。实际中往往用户参评比例低，我们会使用各种方法去刺激用户评价。

三、智能客服遇到的那些问题

1. 做通用智能客服系统还是垂直行业智能客服系统

智能客服系统的都是2B的，通用型智能客服系统意味着市场更大，用户更多。而垂直领域的客服系统用户就少的多了。

以保险行业为例，全国保险公司一共一百多家。而且做垂直领域的智能客服系统，AI团队必须充分理解行业。了解业务需求，了解业务流程还需要跨部门沟通。

做垂直领域的智能客服系统，往往会陷入一两个大项目，不断满足用户的个性化需求上。最终系统很“定制”，同时市场也很小。做几个项目之后就会碰到透明的天花板。

然而做通用型智能客服系统最然市场很大，但是和做垂直领域的智能客服系统的团队相比，没有了优势，技术优势现阶段各家差距不大，小公司可以给用户定制化，但是通用化系统不可以，最终变成市场很大，但是被一个个一句突起的做垂直领域的智能客服系统小公司蚕食了。

那怎么办呢？

互联网刚开始的时候，门户网站率先突起，能够服务大多数人的需求，接下来，微信公号可以订阅，每个人的阅读内容都不一样了，这就是一种定制版的资讯平台。从用户角度来说，定制化是演进方向，最终通用型客服会被垂直行业智能客服所取代。

2. 做SAAS服务还是私有化部署

传统行业银行、保险、证券、房地产等大企业往往有很强的客服需求，对引入智能客服系统的意愿很强，但同时其对自身数据安全性的要求也很高，因此只会同意本地化部署的解决方案。

这类大客户做本地化部署解决方案，就只能采用项目制的商业模式，做一个项目收一次费用。好处是一个项目就能收到几十至上百万元的收入，创业初期就能有盈利；坏处是私有化部署客户需要定制化需求比较多，会占用大量人力成本而且难以规模化复制，长久来看增长空间有限。

那怎么办呢？

单从数据安全角度来讲，会随着技术发展来解决，移动支付刚开始的时候大家还很害怕，绑定自己银行卡会不会被盗。会不会有黑客黑进我的支付宝。现在来看是杞人忧天了。有足够的投入才会有足够的资金支撑技术开发，SAAS服务服务的用户更多，技术漏洞更容易被找出来，系统的安全性会进化的更快。私有化部署不是一个好的选择。

3. 服务大客户还是中小客户

创业之初选择目标客户时所有智能客服创业公司都需要面临一个选择：究竟是主攻大企业客户，还是一开始切入中小企业市场？

主切中小企业客户 则可以用标准化的SaaS产品来满足其需求，不仅模式轻占用人力成本低可实现规模化复制，而且能通过每年续费的方式获得持续的收入，还能不断得到数据循环反馈建立起技术壁垒。

但缺点是前期获客难度大，需要做大量市场教育工作，并且中小企业的死亡率高，整体的续费率难以保障，创业初期很难实现盈利。

但是主攻大客户的话 ，一些定制化需求难以满足，而且大客户流程比较长，一般具有长期服务的服务商，对产品成熟性要求比较高，创业公司很难打进去。定位于服务几个大客户，对于创业公司风险比较大。

那怎么办？

做垂直领域的SAAS系统，就需要有更多的用户使用，才能更快的迭代系统，只有一两个大客户，很难提出建设性的改进建议，所以说做中小客户，尽快的找到第一批用户，把系统跑起来然后不断优化迭代。

3. 智能客服销售难点

大家都在说传统客服行业有很多痛点，智能客服可以很好地解决这些痛点。例如：

（1）人工成本高

人口红利消失，用人单位的用人成本会越来越高。

这个是真实需求吗？首先客服并不是一个企业的核心部门，大多企业对于客服部门并不是很重视。在中小企业，客服人员并不太多，真正能节省的人力成本并不高，所以企业的替换的动力并不大。在大企业中，人力成本的确是一个大的成本支出部门，但是也正基于此，大企业有足够的支出来自己做智能客服系统。因为他们的投入产出比是合适的。就像是滴滴这类拥有大客服部门的企业，更倾向于自己来做。

（2）决策悖论

智能客服系统要解决的就是人类客服做的事情，当替换掉他们的工作后，就意味着部门裁员。

这样当然对于企业来说是节流的好办法，但对于客服部门领导来说就不那么好，部门人说减少就意味着自己在企业中的权重降低。

虽然长远来看这是大势所趋，但现如今销售过程中基本是还是从上到下的销售过程，而不是部门提出的迫切需求，并且有部门人员持续跟进。

总结

太阳底下没有新鲜事，大公司应用底层技术框架，搭建自己的智能客服系统。也许会是一个趋势，既能够保证数据的安全性，也能够控制成本。对于一些SAAS智能客服系统来说，当技术形不成寡头优势，产品推广和服务能力就会变得尤为重要。

智能客服公司有壁垒吗？什么才是智能客服公司的壁垒呢？

客服系统的使用习惯，和数据的积累，以及知识库的完善，是智能客服系统的行业壁垒，用户切换智能客服系统的成本太高，也就懒得替换。

所以尽快拓展自己用户，这就是智能客服公司的壁垒。只做智能客服未来的业务增长会非常有限，找到自己的第二增长曲线，是决定智能客服公司走多远的关键。

作者：老张，微信ID：zjl12224。智能保险产品经理，运营军师联盟创始人之一，《运营实战手册》作者之一。

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

题图来自Unsplash，基于 CC0 协议。

作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。


Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: