蒲成，携程云客服平台研发部资深研发经理。2015年底加入携程从事呼叫中心相关产品的研发工作，主导建设了携程呼叫中心智能语音平台、统一配置中心，目前正在努力推进云客服平台的设计研发工作。

　　本文来自蒲成在2018携程技术峰会上的分享。

　　一、背景及设计理念

　　自携程创立以来，呼叫中心就一直伴随着公司业务一同发展壮大。经过近20年的迭代，目前携程的呼叫中心系统已经演进为第五代呼叫中心系统了，也就是我们完全自主研发的基于FreeSwitch的软交换与IVR、微信Server、邮件系统、无线IMServer的全渠道全媒体客服系统。

　　那么，基于现有可扩展架构的这套客服系统为携程的客服业务提供了什么样的支撑呢？我们可以从以下几个方面一窥全貌。

　　目前支持传统电话、VOIP电话、IM、微信公众号、邮件等通信渠道的接入。

　　目前携程的客服坐席分布在全国及海外各地，其中包括国内的上海、南通、合肥、如皋、信阳，以及海外的爱丁堡、韩国、日本等地。

　　本系统目前支撑着携程200多条业务线以及15000+坐席的服务业务落地。

　　目前提供中文、英语、日语、韩语、法语、俄语等多语种支持。

　　目前电话日均通话量约100万通以上，而IM会话日均消息量约1000万条以上。

　　上述场景的背后是一套什么样的架构体系在提供服务支撑呢？我们又为何会选择建设这样一套架构体系呢？后文将给出答案。

　　传统的客服运营通常面临六大痛点，即沟通单一、信息碎片化、智能化程度低、效率低下、移动性不足、成本高昂。在企业发展壮大的过程中，传统的客服运营就逐渐成为制约企业业务发展的瓶颈。有鉴于此，我们研发了一套基于云和容器化的软呼叫中心及客服平台，并且引入了场景化的AI能力，从而在源头上消除了前面所说的六大痛点。

　　现在，我们的客服系统是这样的：

　　云客服平台=软交换云平台（公有云/私有云）

　　+全渠道座席（Call/Chat/IM/SNS)

　　+全媒体座席（Voice/Txt/Pic/Video）

　　+多模式（集中/在家/移动）

　　+AI引擎（客服机器人/语义解析…）

　　+CRM、工单系统、知识库

　　二、核心架构

　　2.1系统结构

　　我们先来看看整体的系统结构，如下图所示。

　　从上图可以看出我们云客服平台的整体链路结构，其中最核心的就是中间的渠道服务和通信分配层，这一层中的每个节点都可按需进行水平扩展，从而支撑未来的业务发展。

　　通过这一中间层的转换，我们就将上图左侧来自各个渠道的客人服务请求整合为统一的服务请求，并通过右侧的全渠道坐席界面统一分配给客服人员进行服务响应。这样一来，也就实现了多个通信渠道融合的目的。下一节我们来看看其背后的处理逻辑。

　　2.2逻辑架构

　　通信渠道由我们自研的各渠道Server构成，其中也包括无线平台研发部所研发的IMServer。坐席所使用的全渠道通信端（XAgent/APP）使用WebSocket协议与这些渠道Server保持通信，同时也使用WebSocket协议与统一通信分配服务保持通信。

　　其余诸如分配服务、业务数据服务、AI能力服务等，均以微服务API的方式在平台内部暴露。为此，我们搭建了一套名为方塔尖的微服务框架来提供基础设施的支持。

　　2.3方塔尖微服务框架

　　这套框架是基于SpringCloud搭建的，分别采用consul、zuul来实现服务发现和服务路由。此外，在方塔尖中我们还加入了一些功能级服务，比如用户/权限管理、短信验证码、数据加解密、数据访问层封装等等，以便让其上的逻辑层仅关注业务实现即可。

　　2.4统一分配

　　下面我们来看看核心的统一通信分配服务的实现，其架构如下：

　　顾名思义，这个核心组件的目标就是实现各通信渠道的会话统一分配，其核心逻辑如下：

　　LinkServer是坐席服务端，坐席端通过WebSocket连接到LinkServer。

　　LinkServer负责维护坐席连接、收发坐席请求和反馈、传递坐席状态。其处理流程如下：

　　StatusManager是状态管理服务，负责处理LinkServer传递来的坐席状态变化，负责对外提供坐席状态查询。其处理流程如下：

　　ACD是IM+系统的核心模块，其主要功能是实现客人坐席分配，ACD指令和消息的收发、ACD会话管理等。其处理流程如下：

　　其中的分配逻辑是基于抽象的业务规则表达式来进行处理的，为此，我们采用了开源的表达式运算器EvalEx，其好处在于：

　　基于此，我们提供了一些基础分配逻辑，并且也支持第三方分配逻辑的对接。

　　优先分配给上次服务的客服

　　优先分配给为该客户服务次数最多的客服

　　按客服工作量平均分配

　　优先分配给空闲最长时间的客服

　　指定分配给某几个客服

　　调用第三方接口分配

　　2.5智能化

　　人工智能现在很火，但是在人工智能众多细分领域中，其实NLP技术的发展和应用才是人工智能皇冠上的明珠，它也是众多AI大厂持续投入的领域。

　　而就目前的市场环境和技术条件而言，客服业务的智能化是最有希望落地NLP技术的场景。因此，我们也着力构建了云客服平台的智能化应用框架。该框架结构如下：

　　其中智能质检和对话机器人是两大重点应用场景，这两个场景的落地能够极大地提升客服业务运营效率并且显着降低运营成本。

　　对话机器人在我们的客服平台中分为语音机器人和在线IM机器人。语音机器人的服务对象是IVR（交互式语音应答），即电话的呼入呼出IVR场景。其处理流程如下：

　　在线IM机器人主要对接的是IM、微信等即时通信和社交媒体渠道，从广义上可以理解为我们常见的聊天机器人范畴，只不过在客服系统中，其模型是针对专有业务场景进行训练的。因此，相较于通用聊天机器人，在线IM机器人其实更容易达到比较好的智能交互效果。其整体模块结构如下：

　　智能质检对于客服运营管理而言是一项非常重要的功能，借助ASR语音转文字的能力，它能将非结构化的音频、文本数据转换成客服运营甚至企业运营统计分析所需的结构化数据，最终形成对业务管理运营的良性反馈闭环。下面两张图分别是我们云客服平台中智能质检的场景顺序图和处理流程图。

　　三、平台级能力输出

　　客服系统不同面向C端的应用，我们的目标并非寻求用户的长时间驻留。相反，在客服领域，我们希望能够以最快的时间去响应客户的需求，这样才能提升客户满意度并最大限度降低运营成本。所以，我们客服平台的每个模块、每项功能都是围绕这一主旨而设计构建的。

　　那么，基于前面的核心基础架构和上述考量，我们的客服平台能够对外输出哪些能力呢？

　　3.1外呼

　　外呼通常是呼叫中心会高频使用的业务场景，传统的外呼都是坐席人工发起外呼，费时费力且成本高昂。因此，我们围绕外呼应用研发了四种外呼形态，以满足不同业务场景的需要。这四种外呼形态是，自动外呼、预测外呼、预览外呼和智能外呼。

　　篇幅所限，就不一一讲解每种形态的具体特性了，但它们的核心都是以自动外呼系统为基础的，其业务处理简图如下：

　　以此为基础，结合云端基础设施和容器特性，辅以我们自研的各种组件，我们的外呼系统就能提供以下特性：

　　3.2中转

　　中转即号码埋名，也就是用虚拟号码替换真实号码的功能。这项功能的目的是让通话双方无法获悉对方的真实号码，从而实现隐私保护的目的。

　　作为该能力的配套，我们开发了配置界面、录音模块，以及对应的查询/统计报表等功能，用户可以基于浏览器操作完成实时的配置生效操作，并浏览话务中转结果。

　　3.3VOIP

　　VOIP也就是大家所熟知的IP网络电话。我们的平台提供了VOIPSDK，方便第三方应用集成，并且自研了音频编解码和动态码率技术，能够满足弱网下的正常语音通信。其特性如下图所示：

　　3.4全渠道客服工作台

　　我们为客服人员提供了一站式全渠道的客服工作台，以便客服人员可以在统一的工作界面中为来自各个渠道的客人需求提供服务响应。其特性如下：

　　全渠道统一，一站式服务体验

　　全媒体融合，服务形式更丰富

　　数据整合，一目了然

　　3.5客户支持

　　我们的客服平台在核心客服业务能力支持之外还提供了以客户为中心的服务周边配套模块，比如CRM、工单、知识库等。这是为了给客服人员提供更为详尽的客户信息，以期为客户提供全方位的服务支持。

　　CRM

　　客户数据管理

　　工单

　　速流转，协同处理

　　知识库

　　座席服务规范高效

　　3.6报表监控

　　作为客服业务运营的日常管理手段，报表和监控是必不可少的支持方式。我们的客服平台自然也提供了相应的运营报表和监控界面。具体特性如下：

　　实时报表

　　全面监控预警

　　话务预测

　　四、结语

　　客服平台是异常复杂和庞大的结构化体系平台，要在一篇文章中全面论述其技术体系架构几乎是不可能完成的任务。受篇幅限制，本文仅摘取了部分核心架构和核心模块功能略作阐述。如果读者有兴趣了解更多与我们客服平台有关的信息，欢迎在留言区和我们互动。