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