導讀： 從使用者角度我們看到的諮詢客服的過程，是機器人 -> 轉人工 -> 評價。整個過程中人工會話是 IM 通訊的核心。對於整個客服體系在使用者端觸達人工會話前會經歷哪些過程呢？客服人員又是怎樣保證精準又快速地匹配到使用者解答使用者的疑惑訴求，接下來一探究竟吧。
先來看下客服會話和對接系統的整體架構圖，如下所示：
- 訪客端： 使用者觸達端（c端），主要三個功能：人工會話、滿意度評價、機器人會話
- 客服端： 主要的對接平臺有：章魚一站式工作臺（人工會話聊天）、機器人管理後臺（機器人對話相關）、工單工作臺（與人工會話緊密相連）、線上客服工作臺（為人工會話服務）。
想要客服能夠接線到使用者，並且能準確的分配給指定的客服，我們開發了線上客服工作臺，經過了服務時間設定，人機互動，進線分配，排隊溢位會話流程設定一系列規則。
1. 先從服務時間設定說起
1.1 得物客服服務時間
首先有：得物常規服務時間，只有在限制的服務區間內，可以進行人工會話諮詢，超出常規服務時間的諮詢可以進行機器人問答或者留言，人工客服上線後可以進行響應的解答。
常規服務時間： 工作日和週末早上八點到次日凌晨
非常規服務時間： 當然除了常規時間還有特殊服務時間設定，比如雙十一、618等大促期間的使用者流量增加，訂單量增加在某一個時間段內服務時間需要提前或者延長時進行特殊設定。符合特殊時間進線時間的情況也可以正常進線到人工客服。
2. 分流規則
正如有網購經驗進行過客服諮詢的大家所知道的，想要諮詢的問題有下單前的疑問，下單後的疑問，對物流進度的疑問，對到貨商品尺碼顏色等問題的諮詢。
不僅這些，還有買不同的商品時候產生的針對性的問題比如：鞋類，化妝品，服裝，包包手錶， 3C類等等。這些問題都需要專業的客服進行解答，那就不能隨便分配一個客服去接線，所以在使用者進線諮詢之前要先進線分流規則的匹配，這是一個複雜的邏輯。
使用者有從不同渠道來的，從配置維度先按渠道做一個區分：
得物有哪些進線渠道？
目前得物的進線渠道有多個，包括得物App和小程式等等。
根據渠道如何做進線分配？
舉例說明：比如從得物App的商品詳情頁進線客服
根據渠道（得物App）+來源（商品詳情）+分流維度 +分配方式 可以分配到指定的客服組。（分流維度可以設定機器人優先規則）
3. 排隊溢位規則
如上所說符合了進線時間，又滿足了渠道來源分配終於要進線到人工聊天了，但是來的稍微晚了一步，假設只有10個客服，每個客服的同時接線量是10，剛好你是第101個怎麼辦了。一不小心就觸發了排隊規則。
3.1 排隊流程
為了避免客服接線到已經離開等待的排隊使用者，首先要判斷使用者是否在客服頁面，不線上的情況給使用者push 排隊即將結束的提示，線上的情況正常進入排隊進線流程。
App端排隊進線示意圖：
3.2 溢位留言
客服業務高峰大量諮詢排隊的時候，會出現排隊量不均衡，無法調控。為了確保各組排隊量、使用者等待時長均衡，通過溢位規則，合理調配人工客服資源。
3.3實時資料監控
在監控大屏有監控資料保留排隊人次，來回進出保留佇列只計算一次，但是如果使用者多次進線發生多次排隊，則計算多次。
實時資料： 為當日資料。根據所選客服組檢視不同佇列的保留排隊人次
根據監控正在排隊人數和排隊時長判斷使用者行為和客服接線能力是否符合當前使用者數量
4. 進線人工客服
經過前面一系列的規則匹配進線分配，終於來到了人工會話，到了人工客服聊天的階段，客戶和我們的客服是怎麼進行聊天互動的呢？用過得物App的且諮詢過人工客服的同學應該都知道客戶端的使用情況那麼客服是怎麼接線怎麼跟使用者溝通的呢？前後我們開發了兩代系統。
4.1 線上客服系統
這個系統是IM客服系統的第一代系統，功能不僅包括線上聊天，聊天相關的配置使用者管理都這裡統一管理。
4.2 章魚一站式工作臺
也就是現在客服使用的一站式工作臺。因為客服聊天不僅要準確快速，還有複雜的會話切換資訊快取等等 和配置相關放在一起會影響客服的使用，進而開發了章魚一站式工作臺，專供客服接線相關的功能使用。
三欄佈局的形式：
左側區域： 線上、離線、留言使用者列表
- 中間聊天區域： 會話內容，客服聊天區域，包括表情、圖片視訊邀評等等傳送的功能
- 右側區域： 使用者相關的資訊功能區，包括使用者資訊、得物先知、訂單查詢、建立工單(工單資料會同步在工單系統便於對工單專門處理)，商品推薦。
4.2.1 資料的觸達雙端的過程
資料主要包括了普通文字訊息、富文字、圖片、視訊、檔案等等。保證訊息能準確的實時的送達到客服和客戶端長連結是一個不錯的選擇 ， 這些資料先到後端-後端推給 閘道器 -閘道器通過長鏈推送到 章魚工作臺，當前長連結可用的情況下，每一次請求都只是簡單的資料傳送和接受。
說到這裡，大家可能會有疑問，如果傳送訊息過程中出現了 網路 抖動等問題導致問題無法觸達怎麼辦？
目前客服系統用的ACK三次重連機制，在一定時間內如果沒有收到閘道器的返回會進行重試，進行三次重連確保在有偶發的意外網路等狀況時訊息能夠傳送成功。同時為了避免持續重試，大面積重試造成網路堵塞三次嘗試之後依然失敗的會顯示傳送失敗。訊息不落庫。
4.2.2 坐席輔助能力SOP
SOP，是 "Standard Operating Procedure" 三個單詞中首字母的大寫 ，即標準作業程式，指將某一事件的標準操作步驟和要求以統一的格式描述出來，用於指導和規範日常的工作。
針對聊天的過程，有很多重複的問題，客服是如何更快地去解決使用者的問題？早期得物沉澱和完善了很多客服須知的知識文件，其中900+個問題是需要掌握的。為了提高客服側服務效率，繼而延伸出坐席輔助工具。
根據聊天中資訊內容自動匹配相應的知識內容，再由客服根據匹配內容決定否符合當前聊天場景，符合則傳送給使用者即可。把儘可能多的流程化、客服頻繁關注的業務邏輯收納到以sop為基礎的“智慧客服坐席助手”，提供一個統一的一站式查詢、決策、操作入口（工具），簡化客服操作提高客服接待效率。
5. 結束會話
5.1 會話過程有幾個階段
5.2 會話關閉
會話關閉有幾種途徑
- 當客服回覆了使用者之後 在一定的時間內沒有收到使用者的訊息，會先進行會話結束倒數計時，並且push會話會在XX之後結束的提示語。在倒數計時結束之前使用者沒有回覆，觸發預設關閉會話邏輯，推送結束語，會話關閉。
- 在確認使用者疑問已經得到解答，不再有問題諮詢時，push結束語，會話結束。
- 使用者已得到解答，不再有問題諮詢主動結束會話。
5.3 邀評
結束會話前，客服可以傳送邀評調研使用者 滿意度，會話結束後如果沒有進行過邀評的情況下，系統會自動推送邀評。在會話的階段使用者也可以主動發起評價對此次會話的滿意度做一個反饋。為了不過度邀評，讓使用者 體驗 降低，一個會話只有一次邀評機會，不管使用者有沒有評價都不再推送邀評資訊。
6. 總結
客服的演進從開始的初始的平臺到現在的成熟系統，在整個得物客服組成員的共同努力下，一步步的不斷完善優化才有了在巨多會話量壓力下，仍然穩定好用的系統。
以上所述的是得物IM通訊鏈路中的一些主要內容的概覽，讀到這裡已經對客服的運作環境和流程有一個初步的瞭解。除了這些內容以外還有很多細節的技術性的內容，歡迎留言交流討論。
文/Jun
@得物技術公眾號