背景
為什麼客服需要排程？阿裡集團客戶體驗事業群（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%。
原文釋出時間為：2018-09-5
本文作者：力君
本文來自雲栖社群合作夥伴“
阿裡技術”，了解相關資訊可以關注“
”。