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