蒲成，攜程云客服平臺研發(fā)部資深研發(fā)經(jīng)理。2015年底加入攜程從事呼叫中心相關(guān)產(chǎn)品的研發(fā)工作，主導(dǎo)建設(shè)了攜程呼叫中心智能語音平臺、統(tǒng)一配置中心，目前正在努力推進(jìn)云客服平臺的設(shè)計研發(fā)工作。
本文來自蒲成在“2018攜程技術(shù)峰會”上的分享。
一、背景及設(shè)計理念
自攜程創(chuàng)立以來，呼叫中心就一直伴隨著公司業(yè)務(wù)一同發(fā)展壯大。經(jīng)過近20年的迭代，目前攜程的呼叫中心系統(tǒng)已經(jīng)演進(jìn)為第五代呼叫中心系統(tǒng)了，也就是我們完全自主研發(fā)的基于FreeSwitch的軟交換與IVR、微信Server、郵件系統(tǒng)、無線IMServer的全渠道全媒體客服系統(tǒng)。
那么，基于現(xiàn)有可擴(kuò)展架構(gòu)的這套客服系統(tǒng)為攜程的客服業(yè)務(wù)提供了什么樣的支撐呢？我們可以從以下幾個方面一窺全貌。
- 多渠道
目前支持傳統(tǒng)電話、VOIP電話、IM、微信公眾號、郵件等通信渠道的接入。
- 多地域
目前攜程的客服坐席分布在全國及海外各地，其中包括國內(nèi)的上海、南通、合肥、如皋、信陽，以及海外的愛丁堡、韓國、日本等地。
- 多業(yè)務(wù)
本系統(tǒng)目前支撐著攜程200多條業(yè)務(wù)線以及15000+坐席的服務(wù)業(yè)務(wù)落地。
- 多語種
目前提供中文、英語、日語、韓語、法語、俄語等多語種支持。
- 海量會話
目前電話日均通話量約100萬通以上，而IM會話日均消息量約1000萬條以上。
上述場景的背后是一套什么樣的架構(gòu)體系在提供服務(wù)支撐呢？我們又為何會選擇建設(shè)這樣一套架構(gòu)體系呢？后文將給出答案。
傳統(tǒng)的客服運(yùn)營通常面臨六大痛點(diǎn)，即溝通單一、信息碎片化、智能化程度低、效率低下、移動性不足、成本高昂。在企業(yè)發(fā)展壯大的過程中，傳統(tǒng)的客服運(yùn)營就逐漸成為制約企業(yè)業(yè)務(wù)發(fā)展的瓶頸。有鑒于此，我們研發(fā)了一套基于云和容器化的軟呼叫中心及客服平臺，并且引入了場景化的AI能力，從而在源頭上消除了前面所說的六大痛點(diǎn)。
現(xiàn)在，我們的客服系統(tǒng)是這樣的：
云客服平臺=軟交換云平臺（公有云/私有云）
+全渠道座席（Call/Chat/IM/SNS)
+全媒體座席（Voice/Txt/Pic/Video）
+多模式（集中/在家/移動）
+AI引擎（客服機(jī)器人/語義解析…）
+CRM、工單系統(tǒng)、知識庫
二、核心架構(gòu)
2.1系統(tǒng)結(jié)構(gòu)
我們先來看看整體的系統(tǒng)結(jié)構(gòu)，如下圖所示。
從上圖可以看出我們云客服平臺的整體鏈路結(jié)構(gòu)，其中最核心的就是中間的渠道服務(wù)和通信分配層，這一層中的每個節(jié)點(diǎn)都可按需進(jìn)行水平擴(kuò)展，從而支撐未來的業(yè)務(wù)發(fā)展。
通過這一中間層的轉(zhuǎn)換，我們就將上圖左側(cè)來自各個渠道的客人服務(wù)請求整合為統(tǒng)一的服務(wù)請求，并通過右側(cè)的全渠道坐席界面統(tǒng)一分配給客服人員進(jìn)行服務(wù)響應(yīng)。這樣一來，也就實(shí)現(xiàn)了多個通信渠道融合的目的。下一節(jié)我們來看看其背后的處理邏輯。
2.2邏輯架構(gòu)
通信渠道由我們自研的各渠道Server構(gòu)成，其中也包括無線平臺研發(fā)部所研發(fā)的IMServer。坐席所使用的全渠道通信端（XAgent/APP）使用WebSocket協(xié)議與這些渠道Server保持通信，同時也使用WebSocket協(xié)議與統(tǒng)一通信分配服務(wù)保持通信。
其余諸如分配服務(wù)、業(yè)務(wù)數(shù)據(jù)服務(wù)、AI能力服務(wù)等，均以微服務(wù)API的方式在平臺內(nèi)部暴露。為此，我們搭建了一套名為方塔尖的微服務(wù)框架來提供基礎(chǔ)設(shè)施的支持。
2.3方塔尖微服務(wù)框架
這套框架是基于SpringCloud搭建的，分別采用consul、zuul來實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)和服務(wù)路由。此外，在方塔尖中我們還加入了一些功能級服務(wù)，比如用戶/權(quán)限管理、短信驗(yàn)證碼、數(shù)據(jù)加解密、數(shù)據(jù)訪問層封裝等等，以便讓其上的邏輯層僅關(guān)注業(yè)務(wù)實(shí)現(xiàn)即可。
2.4統(tǒng)一分配
下面我們來看看核心的統(tǒng)一通信分配服務(wù)的實(shí)現(xiàn)，其架構(gòu)如下：
顧名思義，這個核心組件的目標(biāo)就是實(shí)現(xiàn)各通信渠道的會話統(tǒng)一分配，其核心邏輯如下：
LinkServer是坐席服務(wù)端，坐席端通過WebSocket連接到LinkServer。
LinkServer負(fù)責(zé)維護(hù)坐席連接、收發(fā)坐席請求和反饋、傳遞坐席狀態(tài)。其處理流程如下：
StatusManager是狀態(tài)管理服務(wù)，負(fù)責(zé)處理LinkServer傳遞來的坐席狀態(tài)變化，負(fù)責(zé)對外提供坐席狀態(tài)查詢。其處理流程如下：
ACD是IM+系統(tǒng)的核心模塊，其主要功能是實(shí)現(xiàn)客人坐席分配，ACD指令和消息的收發(fā)、ACD會話管理等。其處理流程如下：
其中的分配邏輯是基于抽象的業(yè)務(wù)規(guī)則表達(dá)式來進(jìn)行處理的，為此，我們采用了開源的表達(dá)式運(yùn)算器EvalEx，其好處在于：
- 使用BigDecimal進(jìn)行計算和返回結(jié)果
- 不依賴于外部庫
- 可以設(shè)置精度和舍入模式
- 支持變量
- 支持標(biāo)準(zhǔn)布爾和數(shù)學(xué)運(yùn)算符
- 支持標(biāo)準(zhǔn)的基本數(shù)學(xué)和布爾函數(shù)
- 可以在運(yùn)行時添加自定義函數(shù)和操作符
- 函數(shù)可以用變量數(shù)量的參數(shù)來定義(參見最小和最大函數(shù))
- 支持十六進(jìn)制數(shù)字和科學(xué)的數(shù)字符號
- 支持函數(shù)中的字符串文字
- 支持隱式乘法，例如(a+b)(a-b)或2(x-y)，等于(a+b)*(a-b)或2*(x-y)
基于此，我們提供了一些基礎(chǔ)分配邏輯，并且也支持第三方分配邏輯的對接。
- 上次服務(wù)優(yōu)先
優(yōu)先分配給上次服務(wù)的客服
- 熟客優(yōu)先
優(yōu)先分配給為該客戶服務(wù)次數(shù)最多的客服
- 均衡分配
按客服工作量平均分配
- 最閑分配
優(yōu)先分配給空閑最長時間的客服
- 指定分配
指定分配給某幾個客服
- 第三方分配
調(diào)用第三方接口分配
2.5智能化
人工智能現(xiàn)在很火，但是在人工智能眾多細(xì)分領(lǐng)域中，其實(shí)NLP技術(shù)的發(fā)展和應(yīng)用才是人工智能“皇冠上的明珠”，它也是眾多AI大廠持續(xù)投入的領(lǐng)域。
而就目前的市場環(huán)境和技術(shù)條件而言，客服業(yè)務(wù)的智能化是最有希望落地NLP技術(shù)的場景。因此，我們也著力構(gòu)建了云客服平臺的智能化應(yīng)用框架。該框架結(jié)構(gòu)如下：
其中智能質(zhì)檢和對話機(jī)器人是兩大重點(diǎn)應(yīng)用場景，這兩個場景的落地能夠極大地提升客服業(yè)務(wù)運(yùn)營效率并且顯著降低運(yùn)營成本。
對話機(jī)器人在我們的客服平臺中分為語音機(jī)器人和在線IM機(jī)器人。語音機(jī)器人的服務(wù)對象是IVR（交互式語音應(yīng)答），即電話的呼入呼出IVR場景。其處理流程如下：
在線IM機(jī)器人主要對接的是IM、微信等即時通信和社交媒體渠道，從廣義上可以理解為我們常見的聊天機(jī)器人范疇，只不過在客服系統(tǒng)中，其模型是針對專有業(yè)務(wù)場景進(jìn)行訓(xùn)練的。因此，相較于通用聊天機(jī)器人，在線IM機(jī)器人其實(shí)更容易達(dá)到比較好的智能交互效果。其整體模塊結(jié)構(gòu)如下：
智能質(zhì)檢對于客服運(yùn)營管理而言是一項(xiàng)非常重要的功能，借助ASR語音轉(zhuǎn)文字的能力，它能將非結(jié)構(gòu)化的音頻、文本數(shù)據(jù)轉(zhuǎn)換成客服運(yùn)營甚至企業(yè)運(yùn)營統(tǒng)計分析所需的結(jié)構(gòu)化數(shù)據(jù)，最終形成對業(yè)務(wù)管理運(yùn)營的良性反饋閉環(huán)。下面兩張圖分別是我們云客服平臺中智能質(zhì)檢的場景順序圖和處理流程圖。
三、平臺級能力輸出
客服系統(tǒng)不同面向C端的應(yīng)用，我們的目標(biāo)并非尋求用戶的長時間駐留。相反，在客服領(lǐng)域，我們希望能夠以最快的時間去響應(yīng)客戶的需求，這樣才能提升客戶滿意度并最大限度降低運(yùn)營成本。所以，我們客服平臺的每個模塊、每項(xiàng)功能都是圍繞這一主旨而設(shè)計構(gòu)建的。
那么，基于前面的核心基礎(chǔ)架構(gòu)和上述考量，我們的客服平臺能夠?qū)ν廨敵瞿男┠芰δ兀?/div>
3.1外呼
外呼通常是呼叫中心會高頻使用的業(yè)務(wù)場景，傳統(tǒng)的外呼都是坐席人工發(fā)起外呼，費(fèi)時費(fèi)力且成本高昂。因此，我們圍繞外呼應(yīng)用研發(fā)了四種外呼形態(tài)，以滿足不同業(yè)務(wù)場景的需要。這四種外呼形態(tài)是，自動外呼、預(yù)測外呼、預(yù)覽外呼和智能外呼。
篇幅所限，就不一一講解每種形態(tài)的具體特性了，但它們的核心都是以自動外呼系統(tǒng)為基礎(chǔ)的，其業(yè)務(wù)處理簡圖如下：
以此為基礎(chǔ)，結(jié)合云端基礎(chǔ)設(shè)施和容器特性，輔以我們自研的各種組件，我們的外呼系統(tǒng)就能提供以下特性：
- 支持高并發(fā)，吞吐能力可擴(kuò)展
- 高可靠外呼平臺，包含完善的保護(hù)機(jī)制
- 支持預(yù)測外呼、預(yù)約外呼、虛擬坐席外呼
- 提供智能呼叫算法，提升工作效率
3.2中轉(zhuǎn)
中轉(zhuǎn)即號碼埋名，也就是用虛擬號碼替換真實(shí)號碼的功能。這項(xiàng)功能的目的是讓通話雙方無法獲悉對方的真實(shí)號碼，從而實(shí)現(xiàn)隱私保護(hù)的目的。
作為該能力的配套，我們開發(fā)了配置界面、錄音模塊，以及對應(yīng)的查詢/統(tǒng)計報表等功能，用戶可以基于瀏覽器操作完成實(shí)時的配置生效操作，并瀏覽話務(wù)中轉(zhuǎn)結(jié)果。
3.3VOIP
VOIP也就是大家所熟知的IP網(wǎng)絡(luò)電話。我們的平臺提供了VOIPSDK，方便第三方應(yīng)用集成，并且自研了音頻編解碼和動態(tài)碼率技術(shù)，能夠滿足弱網(wǎng)下的正常語音通信。其特性如下圖所示：
3.4全渠道客服工作臺
我們?yōu)榭头藛T提供了一站式全渠道的客服工作臺，以便客服人員可以在統(tǒng)一的工作界面中為來自各個渠道的客人需求提供服務(wù)響應(yīng)。其特性如下：
全渠道統(tǒng)一，一站式服務(wù)體驗(yàn)
- 統(tǒng)一電話、網(wǎng)頁IM、APPIM、郵件、微信等多個渠道
- 快速響應(yīng)用戶咨詢
全媒體融合，服務(wù)形式更豐富
- 文本、圖片、電話、語音、視頻等多媒體融合
- 服務(wù)形式多樣化
數(shù)據(jù)整合，一目了然
- 完整用戶信息與服務(wù)軌跡記錄
- 提升服務(wù)質(zhì)量
3.5客戶支持
我們的客服平臺在核心客服業(yè)務(wù)能力支持之外還提供了以客戶為中心的服務(wù)周邊配套模塊，比如CRM、工單、知識庫等。這是為了給客服人員提供更為詳盡的客戶信息，以期為客戶提供全方位的服務(wù)支持。
CRM
客戶數(shù)據(jù)管理
- 完整記錄用戶數(shù)據(jù)
- 用戶信息統(tǒng)一管理
- 提高客戶留存率
- 提升企業(yè)獲客能力
工單
速流轉(zhuǎn)，協(xié)同處理
- 促進(jìn)企業(yè)內(nèi)外協(xié)作，共同處理用戶咨詢
- 企業(yè)服務(wù)更高效
知識庫
座席服務(wù)規(guī)范高效
- 常用問題
- 常用語
- 客服話術(shù)標(biāo)準(zhǔn)化
3.6報表監(jiān)控
作為客服業(yè)務(wù)運(yùn)營的日常管理手段，報表和監(jiān)控是必不可少的支持方式。我們的客服平臺自然也提供了相應(yīng)的運(yùn)營報表和監(jiān)控界面。具體特性如下：
實(shí)時報表
- 多維度、實(shí)時展示座席指標(biāo)數(shù)據(jù)
- 可按日、周、月等多條件查詢
- 圖表展示方式支持自定義
全面監(jiān)控預(yù)警
- 系統(tǒng)、服務(wù)、座席，全方位監(jiān)控
- 可設(shè)閾值告警與告警通知
話務(wù)預(yù)測
- 智能預(yù)測后續(xù)話務(wù)量
- 突發(fā)事件等因子對話務(wù)量的影響預(yù)測
四、結(jié)語
客服平臺是異常復(fù)雜和龐大的結(jié)構(gòu)化體系平臺，要在一篇文章中全面論述其技術(shù)體系架構(gòu)幾乎是不可能完成的任務(wù)。受篇幅限制，本文僅摘取了部分核心架構(gòu)和核心模塊功能略作闡述。如果讀者有興趣了解更多與我們客服平臺有關(guān)的信息，歡迎在留言區(qū)和我們互動。
【免責(zé)聲明】本文僅代表作者本人觀點(diǎn)，與CTI論壇無關(guān)。CTI論壇對文中陳述、觀點(diǎn)判斷保持中立，不對所包含內(nèi)容的準(zhǔn)確性、可靠性或完整性提供任何明示或暗示的保證。請讀者僅作參考，并請自行承擔(dān)全部責(zé)任。
相關(guān)閱讀：
- ·攜程：上萬坐席呼叫中心異地雙活架構(gòu)及系統(tǒng)設(shè)計2016-12-05 15:17:30
- ·攜程戰(zhàn)略：從呼叫中心到web到OTA到MTA2015-07-22 09:39:46
- ·變臉記：攜程CEO梁建章的勇氣和難題2015-01-06 09:45:12
- ·攜程高級技術(shù)副總裁：從呼叫中心到移動互聯(lián)網(wǎng)的演進(jìn)2014-11-20 10:43:08
- ·呼叫中心式的友情2019-01-04 16:22:44
- ·尹徐：2019, 我對聯(lián)絡(luò)中心發(fā)展趨勢的預(yù)測2019-01-04 09:19:41
- ·CTI論壇總經(jīng)理秦克旋：主動服務(wù)2019-01-04 09:06:26
- ·呼叫中心內(nèi)訓(xùn)師管理規(guī)范2019-01-02 09:52:50
- ·呼叫中心網(wǎng)絡(luò)安全 在Teleperformance上驗(yàn)證用戶身份2018-12-26 10:26:44
- ·呼叫中心如何處理呼叫升級？2018-12-25 09:51:54
