攜程基於雲的軟呼叫中心及客服平臺架構實踐

背景及設計理念

自攜程創立以來,呼叫中心就一直伴隨着公司業務一同發展壯大。經過近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,方便第三方應用集成,並且自研了音頻編解碼和動態碼率技術,能夠滿足弱網下的正常語音通信。其特性如下圖所示:

全渠道客服工作臺

我們爲客服人員提供了一站式全渠道的客服工作臺,以便客服人員可以在統一的工作界面中爲來自各個渠道的客人需求提供服務響應。其特性如下:

  1. 全渠道統一,一站式服務體驗。
  • 統一電話、網頁IM、APPIM、郵件、微信等多個渠道;
  • 快速響應用戶諮詢。
  1. 全媒體融合,服務形式更豐富
  • 文本、圖片、電話、語音、視頻等多媒體融合;
  • 服務形式多樣化。
  1. 數據整合,一目瞭然
  • 完整用戶信息與服務軌跡記錄;
  • 提升服務質量。

客戶支持

我們的客服平臺在覈心客服業務能力支持之外還提供了以客戶爲中心的服務周邊配套模塊,比如CRM、工單、知識庫等。這是爲了給客服人員提供更爲詳盡的客戶信息,以期爲客戶提供全方位的服務支持。

CRM

客戶數據管理:

  • 完整記錄用戶數據
  • 用戶信息統一管理
  • 提高客戶留存率
  • 提升企業獲客能力

工單

速流轉,協同處理

  • 促進企業內外協作,共同處理用戶諮詢
  • 企業服務更高效

知識庫

座席服務規範高效

  • 常用問題
  • 常用語
  • 客服話術標準化

報表監控

作爲客服業務運營的日常管理手段,報表和監控是必不可少的支持方式。我們的客服平臺自然也提供了相應的運營報表和監控界面。具體特性如下:

實時報表:

  • 多維度、實時展示座席指標數據
  • 可按日、周、月等多條件查詢
  • 圖表展示方式支持自定義

全面監控預警:

  • 系統、服務、座席,全方位監控
  • 可設閾值告警與告警通知

話務預測:

  • 智能預測後續話務量
  • 突發事件等因子對話務量的影響預測

結語

客服平臺是異常複雜和龐大的結構化體系平臺,要在一篇文章中全面論述其技術體系架構幾乎是不可能完成的任務。受篇幅限制,本文僅摘取了部分核心架構和核心模塊功能略作闡述。


作者簡介

蒲成,攜程雲客服平臺研發部資深研發經理。2015年底加入攜程從事呼叫中心相關產品的研發工作,主導建設了攜程呼叫中心智能語音平臺、統一配置中心,目前正在努力推進雲客服平臺的設計研發工作。本文來自蒲成在“2018攜程技術峯會”上的分享。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章