作者简介
本文作者为携程基础业务研发部呼叫中心团队，其在传统呼叫中心基础上，结合软交换、智能分配、自动语音语义处理等技术，为携程用户提供人性化、人机互动、便捷的电话语音服务。
一、背景
随着中国经济的发展，在线旅游服务商和传统的旅行社服务商面向不同年龄层次的客户群体竞争，越来越多的人选择携程旅行，享受更快捷更优质的服务体验。而在旅行的过程中，尤其是国外游、自助游比率日益增大的情况下，旅行途中遇到突发状况时，往往需要随时随地、便捷高效的联系客服，快速解决问题。
庞大的客户群体激发的需求，也让携程基础业务呼叫中心团队有了更多的思考：如何将互联网的技术优势延伸融合到传统客服服务中，更好的支持携程客服，让用户能享受到方便、快捷的在线服务。
二、客服系统现状
目前各大互联网企业的客服系统，沟通模式可分为两大类：一类以电话实时语音通信为主，例如携程、中国电信的呼叫中心，以电话为切入，用户和客服实时通话，沟通一对一，用户问题能及时得到反馈；另一类以即时通讯为主，例如淘宝、京东等支持文本、图片和语音消息。前者能为用户提供实时的支持、后者能提供更为丰富的沟通方式，两者各有优缺点。
某些场景下，现有的两种模式都无法满足用户的需求。
- 如果用户在海外遇到突发情况要联系客服，而此时无法拨打普通电话，纯在线聊天工具即使便捷，但是不够及时，无法缓解用户焦虑的状况。此时，则需要纯网络电话来提供及时的服务，快速解决问题
- 纯电话场景：用户拨打电话描述问题的时候，有时需要提供一些凭证，比如产品截图、位置等，此时用户只能挂断电话后，再从某些入口重新提供，客服人员再处理，这个过程会大大增加了处理的环节，降低了效率
- 同一个用户针对同一个事情通过在线客服和电话方式咨询客服，来回多次需要重复描述问题，客人体验会很差。
基于以上的一些场景，携程IM 客服系统应运而生，将实时通讯和即时技术融合一体，打造全媒体多渠道客服服务平台，提升携程服务质量，给用户以最佳的服务体验。
三、携程IM 客服系统简介
1、平台优势
IM 平台主要优势：
- 打通电话与在线聊天的模式，同一个用户咨询，可以保证分配到最优的客服（上次咨询过），避免用户多次重复问题描述，提升体验
- 详情完整的历史服务轨迹，保证客服第一时间快速了解用户诉求，帮助其快速解决问题；
- 用户可以通过纯电话、免费网络电话、在线聊天三种方式任意切换，多渠道进行沟通，提升沟通效率和用户体验。
- 当客服需要联系客人的时候, 尤其在海外用户手机不可用的情况下，IM 可以提供VOIP外呼功能， 帮助客服触达用户，解决紧急的问题（比如机票航变通知等）
IM 系统基于呼叫中心及IM技术，将实时通讯与即时通讯融合到一起，同时支持传统电话、网络电话、图片、文字、语音短信息和图像，用户与客服根据需要在这不同的通讯方式中进行无缝切换，满足沟通中的不同需求。
基于上图的设计架构，客人可以使用传统电话拨打携程客服电话，或使用手机客户端使用网络电话、即时消息（文字、语音短消息、图片、位置等）接入携程呼叫中心，经过智能分配系统，将客人的服务请求分配到最优的座席服务人员。
手机客户端提供传统电话、网络电话和即时消息的交互界面，客人可以根据自己的需求选择合适的沟通方式。
为适应客服日常经常使用的功能，客服座席应用中提供的功能信息更为丰富，帮助客服第一时间获取用户的全面信息，以便针对性的提供优质的服务方式。除包含即时消息的同时还具备电话控制能力，可以支持接听、外呼、转接等功能。
2、实现难点
客服系统实现过程中都会存在以下难点：
- 客服座席应用的发布与更新。
- 电话功能与业务功能的耦合。
- 如何将无限的用户与有限的客服资源进行及时匹配。
- 如何快速支持多种多样的分配规则。
- 如何将实时通讯与即时通讯两种不同的通信方式无缝的整合到一起。
IM 系统通过以下几个方面，解决了这些问题。
1）客服座席的应用架构
一个应用的交互界面与相关的业务会更为紧密的结合，交互形式的变化相对也更为频繁。对于携程拥有2万 坐席，每次客户端的更新发布都将是一个巨大的挑战。与此同时，作为一个与电话紧密相关的应用，需要实现与电话交换机TCP&UDP的通讯， Web技术又无法做到这点 。
结合Hybrid技术架构，IM 客服座席应用采用了原生程序框架内嵌Webkit容器的Hybrid架构。
- 原生程序框架（Windows或Linux应用）负责与操作系统及电话交换机通讯，Webkit容器负责用户UI端的展示。
- 原生应用框架与Webkit容器还能相互通信，实现Web页面对电话业务的控制。
- 原生应用框架只需要关注底层的通信功能，实现功能的高度聚合，具体的业务功能由Web站点提供，与Native框架实现解耦。
2）分布式的智能分配系统
传统的客服分配服务由于需要保证数据一致性，大部分采用有状态服务，而有状态的服务一般都是以主备的方式部署，无法做到负载均衡。但是我们的目标是携程上亿客户群，没有一台机器是能扛住这样的用户量。
通过对客服业务分析，我们发现客服业务有个显著特点，就是客户请求的数量是不固定的，并且可能远大于客服数量，而客服数量是固定的并且相对较少。针对这个特点，我们将分配服务拆分成2块：分配服务与客服状态服务。
- 分配服务是典型的无状态服务，采用集群部署，负责处理用户的分配请求与执行分配策略。这样就不用担心分配请求量大了。
- 客服状态服务则负责与管理客服座席应用保持长连接，管理其状态，并向其推送消息。当有分配请求过来时，分配服务会执行分配策略，并通知客服状态服务。
3）通用策略模型与规则引擎
在如何分配的问题上，可谓是千人千面，每个BU都有对应自己业务逻辑的要求。为了应对变化多样的业务分配需求，我们将分配模型抽象出4个维度，分别是条件、行为、目标、顺序。并以这四种维度，组成脚本化的分配策略。这里我们使用到了开源的Drools规则引擎，它使得我们的分配策略可动态修改并即时生效而不需要调整服务代码。
4）通讯方式的整合统一
在IM 的业务场景中，客户发起服务请求的入口可分为两大类。一类是即时消息发起，另外一种则是从电话发起。如何将这两种类型的通讯方式整合到一起，一直是困扰我们的难题。
最终IM 系统采用了会话的概念来统一管理，不论服务请求的发起入口即时通讯还是电话的实时通讯都视为一个会话。相同的用户ID和服务类型在客服座席应用只会显示一个会话。用这样一个概念将这两种不同的通讯方式实现统一管理，从此沟通无障碍。
