一文看懂“业务定制智能客服”的产品设计_团员分享_@苍狼剑歌

前言：本文作者是“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类知识库，可组合使用来构建核心业务知识库，以结合相互的优点。一般常见用法如下表所示：

问题二：支持同一场景维护多解决方案

针对该问题，在知识库构建上，一般可以用多答案方式解决。如上文的状态机结构化知识库，即可以如下图所示来引入多答案模式。后续在应答过程中，需要结合其他对话模块来实现多解决方案应答的效果。本文第五部分中将继续介绍。

问题三：支持突发性信息的知识构建

由于生产过