为什么客服需要中台战略（上）

最近从朋友圈到各种培训，大家到处都在谈论“中台”，阿里、腾讯、字节跳动、华为等知名互联网公司及科技公司都相继发布自己的中台战略。那么到底中台是个什么鬼？

其实最早的中台思想来自于美军，如果你没法理解中台，你可以先理解美军有这样一个常见的场景：中东战争期间，美军的作战单位大都是10人左右的小团队，而支持他们的是空军的轰炸、舰艇的精准打击、超强的救援与补给能力等等，而这些恰恰就是我们常说的“小前台，大中台”。

从企业端来讲，中台其实就是为了打破原来部门横向信息壁垒以及体系纵向层层壁垒，从全局考虑，建立一个信息通畅、能力统一、灵活创新的载体。中国的企业经过这些年的信息化建设，有不少已经积累了众多的系统、数据、制度等等，如今迫切地需要提高各系统、各业务系统、各业务条线的可复用性。企业可以聚焦于核心服务、能力、数据的统一建设，从而实现更加精确的调整和优化，全面动态调整资源利用，快速创新，从而打造数字化的运营能力。

所以，今天我们就简单聊聊在客服中心建设中，为什么也会需要中台战略的思维。

客服中心为什么需要中台

客服中心需要一个更宏大的视角。现在客服中心已经开始追求创新的视角、用户体验的视角、利润中心的视角等。

而真正客服中心业务的全局性视角，客服业务基本上面向的是企业的全部业务，所以往往跟企业内部的各类业务系统、业务部门等相关，一个孤立于企业的客服体系显然已经难以满足新时代客服的要求。更何况，如今我们还在倡导企业全员营销、全员客服，这就更需要客服中心的全局性视角。

客服中心业务的用户体验视角。现在有的企业比如美的将客服中心成为“用户体验中心”，这是一个很好的做法，因为客服最终的目标就是用户与企业各类业务接触时的体验优化。比如我们众所周知的滴滴客服事件，本质上我们很难归结为客服的原因，由于客服（滴滴大部分还是外包客服）所能拥有的解决问题的权限很小。在事件爆发之后，滴滴客服是以“用户体验”为中心而不是仅仅是以“受理咨询”为中心，去寻求了改变，但这终归是显得被动了。我们常说，最好的服务是将用户的被动服务诉求消解在未产生之前。电商平台如果用户常常咨询某个操作问题，我们应该尝试深究去分析数据看看是哪个环节导致用户不能顺畅地理解页面操作。所以有时候，客服即运营。

客服中心的利润视角。客服是天然面向客户的，所以很多企业也在探索如何将客服这样的成本中心转换成为利润中心。面向销售，我们便会对数据、对系统的要求更高更多样。

客服中心的创新视角。不论是综上我们所述的客服发展的趋势，还是客服本身的建设，没有创新肯定是已经不满足时代的要求了。

客服中心需要更敏捷的反应。现在社会技术、信息变化极快，我们客服中心需要不断适应，不断创新我们的业务。传统的客服中心需要看一个报表，定制开发可能会被排到半年以后，届时这个报表的意义可能都会被打折扣。比如我们服务过的某消费品客户，在遇到突发的舆论事故时缺乏时效性。对客服舆情的监控、智能客服遇到所有舆论相关事件的强制性干预策略等，都不可能等到第二天，这样就需要一个中台支持，才有办法通过快速的调用和配置而不是复杂的定制开发去实现。

我们在实施系统建设中，常常会因为之前的系统没开放接口，或者某个系统的数据拿不到，导致我们的速度响应慢，错失了良机。而不论是对客服更宏大视角的支持，还是对客服业务系统建设更敏捷化的响应，都已经无法依赖于原先的客服系统建设规律，所以无一不需要一个更快、更通畅、更全面的载体去支撑，这便是客服中心的中台化能力建设。

什么是客服中台？

客服的中台化建设其实也是一种指导思想，下文中我们提到的一个个中台模块亦可以描述为一个个能力中心。我们考虑到未来跟企业整体中台战略的融合，把各个共享单元抽象成一个个中台去描述。

其实本身仅仅是客服中心的话，中台的概念本身的确也显得稍微“大了一点”。但这并不影响我们以“中台思维”去思考客服中心的建设。有的人可能会问，我们以前也老提客服平台，那么客服中台和客服平台的区别又是什么？其实，平台更加侧重于系统应用，平台与平台之间是存在信息鸿沟的，而中台有时候甚至并不在意前端如何去应用，可以理解成是把所有平台的能力底层抽下去，统一成一个新的载体，并可以随时支持一个新的平台。

客服中心的中台架构

客服中心的业务中台

客服业务中台本质上就是将企业业务发展所拥有的各类与业务服务相关的能力变成一个个的共享单元。区别于客服的业务系统，客服业务中台不负责具体业务的实现，将业务与业务逻辑进行隔离，通过制定标准和规范，清楚的描述自己有哪些服务，提升协作效率，让任何一条客服业务线都具备整个公司的核心能力，同时向各业务方提供能够快速、低成本创新的能力。

一般来说，企业的业务中台有大的概念及小的概念。广义上的业务中台实际上基本涵盖了整个中台的要求，即“服务于业务的中台架构”。而我们这里主要取狭义上的业务中台含义，即与业务系统距离最近的一系列中台模块。

阿里巴巴的业务中台位置

我们以阿里的业务中台举例。阿里的前端业务多样，有2000多个应用，因为各个应用在核心业务层已经通过共享服务体系实现了统一和畅通，所以今天阿里内部没有类似ESB的组件。从阿里业务中台的位置中看，为了保障新业务的快速开发，阿里对业务系统的支撑体系进行了中台化的建设，形成了用户中心、商品中心、交易中心、评价中心、店铺中心、搜索中心、数据服务中心、营销中心等各类业务共享单元。

阿里的业务中台架构

比如以用户中心来讲。阿里前端的团队开发了一款新的应用，是能够也必须要接入阿里的统一会员体系的，会员中心本身并不作为一套系统去使用，每类系统、每个应用可以基于自己的业务去完成基于会员的各类功能化组件，但本身与阿里的统一会员体系是打通的。

这就相当于我们在客服系统中常说的统一用户身份体系。在客服系统中，我们就常常会碰到客服多渠道的会员服务记录不统一造成的困扰。电话打进来的客户又在微信留言了，如果这时候呼叫中心系统跟微信客服系统没有对接打通，便会相互去查找，非常不方便。而且往往其中某个系统更换，必须考虑到它和其他系统有没有身份信息等接口的依托关系，是动也不敢动，改也不敢改。

客服业务中台的共享服务单元

以一个电商企业的客服业务中台来看，一般由用户中心（用户中心、会员中心、企业客户中心等）、商品中心、订单中心、物流中心、支付中心等模块组成。我们在搭建一个呼叫中心系统的时候，需要基于我们这些模块去构建，所以我们可以希望反推企业IT部门在搭建这样的服务单元时，把相关的系统能打造成业务中台，客服的中台战略便可以与企业的中台战略契合，快速地完成客服系统的业务支撑体系搭建。

在客服的业务中台建设中，客服中台与客服前台是相辅相成的，前台依托于中台的支撑，中台同时也从前端获取各类信息的反哺。

客服中心的技术中台

引用IT博主十五楼亮哥的观点，在企业客服系统最早的开发实践中，我们一开始采用的是单体服务架构，就是将所有的功能模块(service)打包到一起并放在一个web容器中运行。随着企业系统变得庞大，开始出现微服务架构，就是将复杂臃肿的单体应用进行细粒度的服务拆分，每个微服务可以交给小的团队进行开发和维护，拆分出来的服务各自独立打包部署。

客服系统微服务架构升级过程示例

单体应用改造成微服务架构，需要各个功能模块服务化，通俗地讲，服务化，就是将传统的单体应用中通过jar包依赖方法调用，改造成通过RPC接口远程调用的方式。

而进一步发展的“中台服务架构”的思想是伴随着企业规模不断扩大、业务多元化而形成的，也可以说是是微服务架构的升级。

技术中台的能力：IM能力、通讯能力、AI能力等

在企业客服系统建设升级的许多年里，我们沉淀了大量的客服相关系统。呼叫中心电话系统、排班系统、在线客服系统、智能客服系统、订单系统、CRM系统、质检系统、知识服务系统等等，以满足客服业务的不断变化。

再往后我们将系统转化为平台，呼叫中心平台、全渠道客服平台等。而客服技术中台的建设就是要将这些平台的核心能力抽象化，从而更好、更快地服务与前台应用的不断创新。

技术中台就是将使用云或其他基础设施的能力以及应用各种技术中间件的能力进行整合和包装。过滤掉技术细节，提供简单一致、易于使用的应用技术基础设施的能力接口，助力前台（SOI）和业务中台数据中台的快速建设。

技术中台的建设不需要过多被前台的使用牵绊，只有这样才能打造出具有深度及广度的技术中台。

比如如果我们将IM的能力与通讯能力中台化。原来我们的客服中心建设实践中，经常去做在线全渠道的整合，而有些初创客服团队为了节省客服人力会将电话呼叫中心与在线的渠道应用整合，这时候就会有两个系统集成的问题，另外有些时候在线客服遇到问题时需要可以唤起打电话的能力，即可以直接发起呼叫，这便是把呼叫中心的通讯能力中台化去调用。如果仅仅是把这个看成是两个系统的对接就会陷入单个开发的局面中去。

举例，我们曾遇到一家在线教育机构，希望在客服系统基础上建立一套老师、家长、客服可以直接通话甚至可以电话去上课的模块，这时候如果是从系统层面去看，与原来的系统几乎是不能复用的。只有基于整个通讯能力、IM能力的技术中台角度去思考，才会为未来不断的应用拓展性提供可能。

我们在实施项目的过程中，常常会遇到之前厂商的系统接口不完善，甚至没有提供详细的接口文档等，实际上这也是可以从中台战略角度上考虑解决的。

客服AI能力的中台

提到技术中台的建设，在当前的客服系统技术实践中，就不得不提到人工智能。客服是个高频重复的场景，面对海量用户+海量数据，AI的建设是个必然的方向。所以我们把AI能力的中台单独拿出来介绍。

我们在实际的规划中，将客服AI分为几个不同方面，分别是：知识自动化、服务自动化、营销自动化、运营自动化。

知识自动化：知识收集、转化、构建、运营、服务、消费、推荐、反馈的自动化，如机器人和智能知识库等

服务自动化：自动化的服务办理、服务推荐等，如多轮会话办理业务等

营销自动化:  依据数据画像对营销的流程进行自动化或半自动化的执行，如电话机器人

运营自动化：内部运营流程和运营工作的自动化，如自动化工单分派等，这里除了AI的一些能力，还会用到RPA的技术

而客服AI能力的中台可以包含：算法层、模型层、能力层

注意我们在技术架构这里并没有将RPA与AI架构纳入在一起混为一谈，原因是RPA（Robotic Process Automation），机器人流程自动化：通过使用用户界面层中的技术，模拟人类手动操作，执行基于一定规则的可重复任务的软件解决方案。AI是模仿大脑去学习，RPA是机械地去重复手脚的动作，并不是一回事。但如果想真正用好RPA，AI能力的赋能是必不可少的部分，比如自动拍照填报销单，就需要OCR能力和一定的NLP对字段识别能力。

如果把AI能力都细讲一遍又需要一篇长文了，这里为了便于大家理解，我们以语义理解NLP的技术架构为例探讨客服AI能力中台建设的必要。

客服中心NLP能力的中台架构图（算法层、模型层、能力层）

首先底层上我们从算法层来看，NLP的许多能力，乃至训练这些能力的资源调度管理系统和数据训练系统，本质上不管是语义、语音数据训练还是图像数据训练，这样的训练平台都是通用的。所以有些客户希望搭建自己具有AI能力开发的技术团队，就可以整体考虑资源调度管理系统和数据训练系统的搭建，纳入到整个AI中台中去。

我们通过算法和不同的模型生成了NLP的能力，那么这些能力又可以干嘛呢？我们以其中一个能力——信息抽取来举一个例子：

文本信息抽取的能力含义是：它从自然语言文本中自动抽取指定类型的实体（entity）、关系（relation）、事件（event）等事实信息，并形成结构化数据输出。例如，从关于上市公司的新闻报道中抽取事件的信息一般包括如下几个主要方面：公司类型、时间、地点、融资金额、营收、净利润等。总体来说，文本信息抽取主要包括三方面的内涵：①自动处理非结构化的自然语言文本；②选择性抽取文本中指定的信息；③就抽取的信息形成结构化数据表示。

假如我做一套文本机器人系统，我需要用到信息抽取的能力去做用户问句的解析进而收集信息。比如我要订珠江路附近的华住酒店大床房，八点入住。那么时间、地点、房型、品牌就是我们需要抽取的信息元素。这个信息抽取能力，电话机器人多轮会话提交信息需要，客服助手帮助填单也需要。

甚至假如我是社区客户运营需要去做一些社区评论去分析，我就可以调用客服的中台能力里的信息抽取能力去运营，包括舆情的分析、评论分析等等，营销画像等。而信息抽取完全可以做成一个通用的模块，不管你什么应用，我都可以根据数据去训练、去标注并给予调用。理论上，每一种NLP能力都可以抽象成底层的支撑能力。以我们自己的产品开发举例，我们把底层的机器学习（包含深度学习）能力和NLP能力都打造成了自己的中台，基于这个能力中台，我们将之应用在各类客服智能化系统中实现赋能。以后关于AI能力中台的建设我会重点去介绍。

客服中心数据中台

数据的建设与服务统一

阿里的数据人员曾提到过，阿里的数据中台是一个倒三角形。“第一是数据技术。没有数据中台的时候，不管是阿里内部还是各商家，大家都有自己的数据中心、机房、小数据库。但当数据积累到一定体量后，这方面的成本会非常高，而且数据之间的质量和标准不一样，会导致效率不高等问题。因此，我们需要通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。”“第二是数据资产。数据中台把阿里系的数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而保证为集团各业务和商家提供高效服务。”“第三和第四都是数据服务，包括服务商家和服务小二。例如生意参谋和阿里指数，就是数据中台中面向商家端提供的数据服务。”

我们在客服系统建设中也是一样，常常会涉及到各种数据的沉淀，而数据格式不统一就会导致很多数据无法进行完整的分析或使用。比如以前的在线客服数据、录音数据客户拿过来想要直接用于建立问答机器人的知识库。这个诉求往往对技术的要求非常高，如果在建立数据维度的时候就能统一，对于AI的应用会很有帮助。

再比如我们现在常常强调的营销型客服，当然，实际应用中很多变数导致我们没法统一规划，但是指导思想不就是这样吗，定义一套标准，尽可能考虑到统一性，新系统再建的时候便不会是完全的推翻重来了，老系统好的地方一样可以保留。

数据的服务模型统一

我们在做数据分析时，常常会用到各类的工具和各类的方法，这些方法的沉淀如果有中台思维会更加清晰全面。比如我们常常遇到的话务量预测模型、排班的预测模型等，而这些预测方法里是否用到同类的数学模型乃至机器学习的算法？我们去统一建设方法：影响因素、基础数据选择、数据清洗方法（清洗规则、统一数据口径等）、预测的数据模型，等等。

电商场景下的客服数据中台（会员数据部分）

数据中台的建设甚至还可以衍生各种创新的项目，可以基于数据中台的能力去做创新，不用依赖各种系统的数据局限。

客服中心知识中台

在客服中心的建设中，知识建设是必要部分。尤其是对产品体系复杂、产品应用繁琐的企业来说，一套有效的知识体系建设，往往是客服服务效率保障的基石。而目前很多企业的现状是知识建设很分散、很零乱。在客服中心向一个更高效、更全面的服务体验迈进过程中，无论是支撑智能化的各类系统还是传统的客服培训、话术管理等，无一不需要有效的知识支撑。而如果知识管理的战略思维不够，就容易导致知识收集困难、知识格式与细粒度不统一、知识构建效果不好、知识重复建设、知识消费场景不方便等各类问题。

从客服中心的服务支撑型知识管理来看，知识的消费场景是多样的，但是知识的来源和加工方式确实有共同之处的。比如我对文档的知识结构，以图谱的形式进行知识图谱数据库的搭建，那么整套知识资产可以用到方方面面。

知识构建的工具

知识是服务的资源，要把资源开发好，才可能提供更好的服务。在知识挖掘、构建的智能化方面，有许多可以辅助人工，将企业各类内部文档、内部网页等直接作为知识输入类型构建与诊断知识的智能化工具。在知识关系抽取、知识图谱构建、图谱关系挖掘、图谱问答等方面，行业也取得了突破和创新，不断在升级知识价值深度挖掘技术，节省企业人力，将企业服务自动化。挖掘和构建出有价值的知识，不断补充知识库，建立知识关联，同时也构建出强大的知识关系网，才能为精准&细致服务提供可能性。

而不同的系统应用对知识的需求，虽然不一样，但从知识的本质构建工具角度看是可以统一去思考的，所以其实都不应当把其知识建设独立开来去看。

知识构建的方法

构建一个客服体系乃至企业服务整体的知识架构，需要从知识边界、知识分类、知识梳理、知识标准、知识属性、知识渠道、知识类型等多个维度定义一种标准，这种标准包含了多个方面。例如，我们在构建智能机器人知识的时候，需要考虑知识的来源、知识的类型、知识的被访问形式、用户体验知识消费的场景和表达特点、知识的关联以及知识的生产、评估、拆解、合并等等多类方法，而这些如果我们做了一套知识中台，便可以轻松地进行搭建，还可以支持客服在服务中的多类应用，比如客服服务助手、培训助手，智能机器人，智能工单质检，智能电话等等。

知识中台架构图

客服中心组织中台

客服中心的建设主要分为系统、人员与制度建设。除了系统的中台战略以外，为方便客服组织创新，方便客服灵活地调整架构，比如在建设组织的管理制度时，便可以以中台的思维去考虑。尤其对于最近新的一些智能客服，在已有的其他中台能力支撑的情况下，客服可以以一两个或者几个人的小团队去快速创新，比如机器人训练师的构建、用户体验智能分析员的培养等。

当然，由于各类软硬件系统的复杂度，构建一套完整的客服中心中台系统绝非易事。限于篇幅我们不能一一尽述。

下一篇，我们一起聊聊构建企业客服中心各类中台的具体挑战与方法，企业客服中心中台与企业整体中台战略的关系，以及我们应当如何培养这样的客服中心业务与系统人才，以达到客服中心中台战略的要求。

欢迎加入我们一起继续剖析客服中心的中台战略，请关注“云问科技”公众号哦~

     作者：Astor阿童木

     云问研究院 解决方案专家

2018年，云问参与了两项国家人工智能标准制定工作：《人工智能标准化与开源研究》、团体标准《信息技术 人工智能 智能助理智能能力等级评估》；

同时获得50多项机构评奖：中国信通院《2018年度中国人工智能创新奖》、中国软件行业协会《2018最具投资发展潜力软件企业》、《人工智能》杂志《2018年度中国人工智能商业价值TOP100》、赛迪研究院CCID《2018年度雷克卓越产品/解决方案奖》、亿欧《2018中国商业落地榜单100强》、创业邦《2018人工智能创新应用50强 》、极客网《2018年度最值得关注的50家应用型AI公司》、创业黑马《2018年中国企业服务产业独角兽榜单TOP100》、江苏省经信委《江苏省腾云驾数优秀软件企业、优秀融合案例》等。