背景
爲什麼客服需要調度？阿里集團客戶體驗事業羣（CCO）目前承接了阿里集團以及生態體的客戶服務業務，我們的客戶通過各個渠道來尋求解決各類問題，每天的進線量巨大，而且經常伴隨着突發性進線，比如天貓代金券出了問題，在幾分鐘內就會造成幾千通熱線或在線諮詢。面對種類繁多、海量、突發的客戶問題，我們的服務能力往往難以滿足，常常造成用戶排隊，甚至放棄，自然我們產生了對調度的需求。
客服調度的核心問題是什麼？提升客服資源的利用率和服務水平，用更少的客服資源獲得更佳的用戶體驗。如果我們招聘大量的客服，也能讓用戶獲得更好的體驗，但是容易造成人力浪費，更多的人手意味着更多的培訓成本、管理成本和人力成本。
與機器調度相比，客服調度有它的複雜點：
1）機房增加一臺新物理機，機器虛擬化後就可以快速被使用，而招募一個新客服，得需要長時間的培訓才能讓他具備線上服務能力；
2）客服間差別大，不同客服的業務技能有區別，很難直接讓B技能組的客服處理A技能組的任務，即使是掌握同一技能的客服，他們的服務能力也有大的差別，而機器差別不大，很多業務可以使用相同類型的機器；
3）客服是人，他有權利選擇上班、小休，他的工作效率、質量會隨着他的情緒、體驗、服務的會員、工作時長等波動，調度時需要考慮他們的感受，而調度機器時無需顧忌；
4）突發場景多，業務問題、系統故障等都是無規律爆發，波動特別大，很難準確的提前排好一天的人力。
現場管理員是否能應對如此複雜的客服調度？答案是否定的。在沒有調度系統之前，現場管理員基本靠手工來調度，隨着體量越來越大，缺陷逐漸暴露：
1）響應慢：比如週末線上排隊時，現場管理員可能會收到電話反饋，然後再打開電腦去手工放個臨時班等等，從排隊發生到調度生效超過十幾分鍾很正常；
2）不精準：缺乏數據指導，統籌優化能力弱。舉個例子，A技能組排隊時現場管理員想將A技能組的流量切一些到B裏，切多少，分給誰，可能都是拍腦袋決定，決策結果也無法沉澱；
3）手段缺：可用的手段非常少，無非就是手動排班放班、手工切個流，管控下小休、發個公告等，沒有充分挖掘出客服的能力和潛力。
明確了客服調度的核心問題，也知道了難點，更看到了目前的現狀後，我們決定打造一款自動、智能的客服調度系統——XSigma。
1. XSigma大圖
XSigma調度系統按功能模塊可以分爲手、腦、眼幾塊。手就是能提升客服資源利用率、客服服務水平以及提升客戶滿意度的手段，比如溢出分流、預約回撥、現場管控、激勵、排班、應急放班、培訓等。手段這麼多，在不同業務不同場景下如何抉擇是一個難點，這裏需要大腦也就是調度中心來做決策。決策產生的複雜調度邏輯如何能讓現場管理員、業務人員和開發人員更好地理解？我們通過可視化技術將複雜的調度邏輯轉化爲可以理解的實時圖形界面，即調度系統的眼睛-調度大屏。手、腦、眼功能具備後，如何讓他們磨合得越來越好？我們通過仿真演練系統來錘鍊。
下面會對圖裏的模塊一一介紹。
2. 提前準備：排好班
如果能預測好需，準備好供，那客服調度就成功了一半。在我們業務中，不同類型的客服排班模式不同。雲客服採用的是自主選班模式，管理員只需設置好每個時間段的選班人數，讓雲客服根據自己的時間來自行選班。而SP（合作伙伴）採用的是排班模式，需要管理員根據每個時間段的話務量來安排每一個客服，既要能夠保證每個時間段的接通率達到最大，又要能夠協調好客服人員的休息和工作時間，保證每個客服人員的總工時大致相等，這非常考驗管理員的統籌能力，當客服數目變多後，人工排班給管理員帶來了巨大挑戰。
不管哪種模式，都需要提前預測未來兩週的需要服務量（業務上按1~2周的粒度排班），這其實是個標準的時間序列預測問題。結合歷史數據，我們可以按照部門-技能組的粒度預測出未來2周的服務量，當然，這種離線的預測只是一種近似，很難精準預測。
對於合作伙伴公司客服的排班，可以抽象爲多約束條件下的優化問題，在實際場景中，我們採用了組合優化算法。
3. 水平擴容：預測式應急放班
提前排班很難精確預估服務量，我們不可能提前知道下週一13點25分會出現個代金券問題導致大量用戶進線諮詢。
對於這種突發性質的流量或者比上班服務量大的流量，我們能不能像調度機器一樣，快速水平擴容一批客服來上班。對於社會化的雲客服，我們可以做到，比如排隊數超過某值時，自動觸發雲客服的應急放班。通過實踐發現雲客服從選班到上班一般需要十多分鐘時間，如何進一步節省這十多分鐘的黃金處理時間？將應急放班升級爲預測式應急放班！提前幾分鐘預測到即將到來的大流量，提前放班。
這裏涉及兩個模型，一個是服務量實時預測模型，該模型能根據實時數據如會員的操作行爲，會員在小蜜的行爲，故障場景，並結合歷史進線量來綜合預測某一技能組未來30分鐘每一分鐘的進線量。
有了服務量預測數據輸入後，應急放班模型就可以結合當前服務會員情況，未來30分鐘客服排班情況、會員消耗速度、溢出關係等綜合指標，來推斷出是否要觸發應急放班以及放班的服務量。一旦觸發應急放班後，線下通知模塊會通過電話、短信等手段來通知合適的客服來上班。
與調度機器不同，我們需要時刻考慮客服感受，爲了避免打擾沒有上班意願的客服，我們讓客服自主設置是否要接收通知。
4. 負載均衡：溢出、分流
儘管預測式應急放班效果不錯，但目前只針對雲客服有效，對於SP類這種非選班類的客服怎麼辦？我們發現，線上排隊時，往往是某幾個技能組出現大量排隊場景，比如商家線爆了，消費者線的客服可能處於空閒狀態。如何解決這種忙閒不均問題？一個直觀的極端想法就將所有的組變成一個大池子組，通過負載均衡分配讓每一個客服都處於繁忙狀態，從而達到效率最大化。而事實上並不是所有的技能組之間都能互相承接，這裏既要權衡業務，又要線下培訓讓客服具備多技能。
XSigma提供了技能組相互分流、溢出的配置功能，只要滿足觸發條件，就能實時分流溢出，解決了以往靠現場管理員手工改客服技能組的痛苦。
對於一些場景而言，技能組間的溢出粒度有點粗，比如設置了A技能組排隊可以溢出到B技能組，並不是B技能組的每一個客服都能承接A的業務，只有進行了培訓的客服才能承接，XSigma同樣提供了給客服打技能標籤的功能。
5. 垂直擴容：彈性+1
有些業務比較複雜，很難找到其他技能組進行溢出，我們將注意力轉到正在上班的客服上。在線客服可以同時服務多個會員，如果一個客服最大服務能力是3，那麼他最多同時服務3個會員，這個值由管理員根據客服的歷史服務水平來設置。
我們發現儘管很多小二的最大併發能力是相同的，在他們滿負荷服務會員時，他們的服務水平有很大不同，他們的忙閒程度也有非常大的差異，爲什麼？
-
小二本身水平有差異
如下圖所示，某技能組的客服最大服務能力都是3，最近一個月這個技能組的客服在同時服務3個會員場景下的平均響應時間分佈（平均響應時間正比於客服回覆速度），可以看到數據呈一個大致正太分佈，說明小二服務水平有差異。
-
場景不同
舉個例子，A和B兩個客服最大服務能力都是5，同樣都在處理5個會員，但是A的5個會員差不多都到會話結束尾聲了，B的5個會員都纔剛剛開始，這個例子下A和B兩個客服當下的忙閒程度明顯不同。
既然小二的服務水平有差別，實際場景千差萬別，那能不能在技能組排隊時刻讓那些有餘力的小二突破最大服務上限？
XSigma提供了兩種策略來讓小二突破服務上限。
1）主動+1模式
當技能組達到觸發條件時，XSigma會主動點亮客服工作臺的+1按鈕（如下圖紅框所示），客服可以點擊來主動增加一個會員進線，這種方式相當於是將擴容權利交給客服，因爲只有客服自己知道目前忙不忙。
2）強制+1模式
如果某些技能組是強管控類型，可以選擇開啓強制+1模式，XSigma會結合數據自動選擇一些合適的客服來突破服務能力上限，比如他之前最大服務能力是5，我們會同時讓他服務6個會員。
6. 削峯填谷：預約回撥
對於熱線來說，小二不可能同時接好幾個電話，而且業務上可承接的線下客服也少，這時候如果出現大面積排隊怎麼辦？
通過數據分析發現，很多技能組在一天內的繁忙度在波動，有高峯也有低峯，下圖所示展示了某技能組的剩餘服務數，可以看到有兩個繁忙時間段，10~13點，17~21點，這兩個時間段的空閒服務數很多時候都是0，而其它時間段相對比較空閒，如果能將這些繁忙時間段的進線量騰挪到非繁忙時間段，這樣就能大大提升客服的人員利用率，也能避免客戶排隊的煩惱。
怎麼做呢？通過預約回撥，將當下服務轉變爲未來服務。如下圖所示，主要有兩個模塊構成。
1）預約觸發器。用戶電話進來後，預約觸發器會根據技能組的繁忙情況，來判定是否要觸發預約；
2）回撥觸發器。採用系統主動外呼模式，一旦發現技能組繁忙度處於低峯，就會觸發回撥，只要用戶電話被接通，就會以高優先級進入到分配環節，從而讓客服人員在有效的工作時間內都在真正的與客戶通話。
7. 最優分配
調度的目標是：“提升客服資源的利用率和服務水平，用更少的客服資源獲得更佳的用戶體驗”。前面這些策略的關注點更多是在提升客服資源利用率上，有沒有什麼策略能提升用戶的滿意度？我們從分配這一環節入手。
本質上我們要解決的是“會員（任務）-客服匹配優化”問題。在傳統模式下，分配就是從某技能組的排隊隊列中找到一個等待時間最長的會員，然後再找一個該技能組下最空閒的客服完成匹配。這種公平分配方式考慮維度單一，未能在全局層面上掌握和調度分配有關的會員、客服、問題等各類信息。
匹配優化問題其實是二部圖匹配問題，如圖所示，在某一時刻，我們可以得到某技能組下未分配的客戶（任務）以及具備剩餘服務能力的客服，如果能知道每個任務與每個客服之間的匹配概率，那就可以通過穩定婚姻算法找到最佳匹配。
如何求得任務與客服之間的匹配概率？抽象爲分類迴歸問題，核心在於構建大量樣本（x1,x2,x3,…,xn）(y)。針對一通曆史會話任務，y是客戶評分或會話時長（目標可選），而x既包含了客服特徵如過去30天的滿意度、平均響應時間等等離線指標，以及客服當前會話的服務會員數、最大會員數等實時指標，也包含了任務的特徵，如問題類型、等待時間、訂單編號、重複諮詢次數等等。樣本有了後，下面就是選擇分類算法進行訓練，最終我們採用了CNN。
在迭代過程中發現，模型會將流量更多分配給好的客服，而指標相對較差的客服的流量則變少，爲了避免少量客服上班接不到客反彈的情景，我們將公平性的指標引入到模型中。
8. 智能培訓：大黃機器人
通過最優分配來提升滿意度的一個重要原因是將流量更多分給了能力強水平高的客服，而這部分客服的佔比不高，爲什麼？爲了應對11、12這兩個特殊月份的高流量，業務團隊要招募培訓大量的雲客服。這些新手湧入必然會對滿意度帶來影響，換句話說，如果要想進一步提升滿意度指標，必須提升新手客服的服務水平。
對於新手，在上崗前提升他們水平的唯一方式就是培訓，傳統的培訓都是通過線下讓雲客服看視頻等學習資料，然後進行筆試，通過後就直接上崗，帶來的問題是很多新客服對平臺的工具、解決方案都不熟悉就直接服務會員，會員體感較差。
對比練車場景，我們發現練車有科目1、科目2、科目3等不同流程，科目1學習理論，科目2和科目3實戰模擬，如果我們引入這種實戰模擬就能大大提升新客服的服務水平。
我們創新的提出了使用機器人（大黃）來培訓客服這一全新的客服培訓模式（已申請專利）。新客服在培訓租戶裏，通過點擊大黃頭像，會產生一通非常真實的模擬會話，通過和會員聊天，不斷學習平臺工具使用，不斷提升解決客戶問題能力。一旦會話結束後，大黃機器人會對這通會話進行評價，並會告知應該使用某種具體的解決方案來回答用戶問題。
對於新客服，目前必須完成大黃80通會話後才能上崗，整個財年培訓客服幾萬人，服務會話量達到幾百萬輪次。abtest顯示通過大黃試崗的客服不管在滿意度、不滿意、平均響應時間、平均服務時長等各項指標上都有非常明顯提升。
9. 統一的調度中心
從上面可以看到我們的客服調度策略多且複雜，每種策略都起到了一定提升客服資源的利用率和服務水平的作用。現在的問題來了，不同場景下這麼多策略如何選擇？比如現在技能組A突然排隊100個會員，這個時候是直接溢出到其他技能組，還是觸發主動+1或觸發應急放班呢？這裏需要一個大腦來做決策。
如何讓這個大腦適用於各種複雜的業務場景是難點。我們平臺目前租戶就有幾十個，僅淘系這一個租戶就劃分了幾十個客服部門，每個部門下又細分了一系列技能組，不同部門間業務場景不同。在嚴重缺乏歷史數據積累情況下，很難直接通過訓練一個決策模型來適應多種業務。於是我們的思路就轉換爲直接利用現場管理員的專家知識，讓他們將決策邏輯沉澱爲一條條的規則。
目前平臺上已經配置了上萬條規則，每天生效的規則也有幾千條，這些數據的沉澱讓我們可以通過智能優化技術實現真正的智能調度決策大腦。
10. 調度監控大屏
客服調度策略繁多、邏輯複雜，調度結果會切實影響整個環節參與者的感受，因此我們搭建了XSigma調度大屏，方便大家理解。在實踐過程中發現調度大屏能建立起使用方對調度系統的信任感，降低開發人員和管理員發現、定位並解決系統問題的成本。舉個例子，管理員在XSigma平臺上設置一些規則，比如A技能組排隊數>=1觸發溢出到B技能組，設置完後他心裏沒底，他也不知道設置的邏輯是否生效，往往會讓開發同學再次確定下有沒有生效，而現在有了可視化調度大屏，既能觀察到各個技能組的服務量、剩餘服務量等實時監控數據，也能看到實時調度各種策略生效的過程，以及每天調度的實時彙總明細數據。
11. 仿真演練
在調度優化場景中，如何評估調度系統的好壞至關重要。有沒有一種手段能評估XSigma是否能適應各種場景？能提前證明在雙11這種大促期間也能順暢的調度？能及時發現調度過程中出現的問題？這不僅是我們也是業務同學迫切需要知道的。
仔細思考發現，要解決的問題和技術的全鏈路壓測要解決的問題很相似，我們要做的其實是業務上的全鏈路壓測，於是我們搭建了客服調度的仿真演練系統。
基於大黃機器人，我們已經能模擬會員進線，通過定製改造，機器人可以製造各種主題類型的題目，比如雙十一類型場景等。在此基礎上，結合業務同學的預估量，可以設置出各個技能組的進線量。
在雙十一之前，業務同學使用這套演練系統大規模演練過兩次，由於是基於真實服務量進行演練，而不是以前的口頭相傳的方式，讓調度上下游每一個參與的同學都有壓力感。在演練過程中發現的一些問題改進後，大大提升了我們應對大促突發流量的信心。
12. 小結
XSigma智能客服調度系統採用自動化配置、機器學習等技術，將複雜的調度問題分層處理，並在日益增長的會員任務基礎上，不斷精細化調度模型依賴的狀態預估數值，不斷提高調度模型的多目標規劃能力，同時通過大量運用平臺可視化技術，以實時、圖表化的方式將系統運行狀態呈現出來，最終在客服效率和用戶體驗時間上得到優化效果。該系統上線後，相比於往年，服務不可用時長這一業務核心指標直接下降98%。