摘要:明確了客服調度的核心問題,也知道了難點,更看到了目前的現狀后,我們決定打造一款自動智能的客服調度系統(tǒng)。對于社會化的云客服,我們可以做到,比如排隊數超過某值時,自動觸發(fā)云客服的應急放班。
背景
為什么客服需要調度?阿里集團客戶體驗事業(yè)群(CCO)目前承接了阿里集團以及生態(tài)體的客戶服務業(yè)務,我們的客戶通過各個渠道來尋求解決各類問題,每天的進線量巨大,而且經常伴隨著突發(fā)性進線,比如天貓代金券出了問題,在幾分鐘內就會造成幾千通熱線或在線咨詢。面對種類繁多、海量、突發(fā)的客戶問題,我們的服務能力往往難以滿足,常常造成用戶排隊,甚至放棄,自然我們產生了對調度的需求。
客服調度的核心問題是什么?提升客服資源的利用率和服務水平,用更少的客服資源獲得更佳的用戶體驗。如果我們招聘大量的客服,也能讓用戶獲得更好的體驗,但是容易造成人力浪費,更多的人手意味著更多的培訓成本、管理成本和人力成本。
與機器調度相比,客服調度有它的復雜點:
1)機房增加一臺新物理機,機器虛擬化后就可以快速被使用,而招募一個新客服,得需要長時間的培訓才能讓他具備線上服務能力;
2)客服間差別大,不同客服的業(yè)務技能有區(qū)別,很難直接讓B技能組的客服處理A技能組的任務,即使是掌握同一技能的客服,他們的服務能力也有大的差別,而機器差別不大,很多業(yè)務可以使用相同類型的機器;
3)客服是人,他有權利選擇上班、小休,他的工作效率、質量會隨著他的情緒、體驗、服務的會員、工作時長等波動,調度時需要考慮他們的感受,而調度機器時無需顧忌;
4)突發(fā)場景多,業(yè)務問題、系統(tǒng)故障等都是無規(guī)律爆發(fā),波動特別大,很難準確的提前排好一天的人力。
現場管理員是否能應對如此復雜的客服調度?答案是否定的。在沒有調度系統(tǒng)之前,現場管理員基本靠手工來調度,隨著體量越來越大,缺陷逐漸暴露:
1)響應慢:比如周末線上排隊時,現場管理員可能會收到電話反饋,然后再打開電腦去手工放個臨時班等等,從排隊發(fā)生到調度生效超過十幾分鐘很正常;
2)不精準:缺乏數據指導,統(tǒng)籌優(yōu)化能力弱。舉個例子,A技能組排隊時現場管理員想將A技能組的流量切一些到B里,切多少,分給誰,可能都是拍腦袋決定,決策結果也無法沉淀;
3)手段缺:可用的手段非常少,無非就是手動排班放班、手工切個流,管控下小休、發(fā)個公告等,沒有充分挖掘出客服的能力和潛力。
明確了客服調度的核心問題,也知道了難點,更看到了目前的現狀后,我們決定打造一款自動、智能的客服調度系統(tǒng)——XSigma。
1. XSigma大圖
XSigma調度系統(tǒng)按功能模塊可以分為手、腦、眼幾塊。手就是能提升客服資源利用率、客服服務水平以及提升客戶滿意度的手段,比如溢出分流、預約回撥、現場管控、激勵、排班、應急放班、培訓等。手段這么多,在不同業(yè)務不同場景下如何抉擇是一個難點,這里需要大腦也就是調度中心來做決策。決策產生的復雜調度邏輯如何能讓現場管理員、業(yè)務人員和開發(fā)人員更好地理解?我們通過可視化技術將復雜的調度邏輯轉化為可以理解的實時圖形界面,即調度系統(tǒng)的眼睛-調度大屏。手、腦、眼功能具備后,如何讓他們磨合得越來越好?我們通過仿真演練系統(tǒng)來錘煉。
下面會對圖里的模塊一一介紹。
2. 提前準備:排好班
如果能預測好需,準備好供,那客服調度就成功了一半。在我們業(yè)務中,不同類型的客服排班模式不同。云客服采用的是自主選班模式,管理員只需設置好每個時間段的選班人數,讓云客服根據自己的時間來自行選班。而SP(合作伙伴)采用的是排班模式,需要管理員根據每個時間段的話務量來安排每一個客服,既要能夠保證每個時間段的接通率達到最大,又要能夠協調好客服人員的休息和工作時間,保證每個客服人員的總工時大致相等,這非??简灩芾韱T的統(tǒng)籌能力,當客服數目變多后,人工排班給管理員帶來了巨大挑戰(zhàn)。
不管哪種模式,都需要提前預測未來兩周的需要服務量(業(yè)務上按1~2周的粒度排班),這其實是個標準的時間序列預測問題。結合歷史數據,我們可以按照部門-技能組的粒度預測出未來2周的服務量,當然,這種離線的預測只是一種近似,很難精準預測。
對于合作伙伴公司客服的排班,可以抽象為多約束條件下的優(yōu)化問題,在實際場景中,我們采用了組合優(yōu)化算法。
3. 水平擴容:預測式應急放班
提前排班很難精確預估服務量,我們不可能提前知道下周一13點25分會出現個代金券問題導致大量用戶進線咨詢。
對于這種突發(fā)性質的流量或者比上班服務量大的流量,我們能不能像調度機器一樣,快速水平擴容一批客服來上班。對于社會化的云客服,我們可以做到,比如排隊數超過某值時,自動觸發(fā)云客服的應急放班。通過實踐發(fā)現云客服從選班到上班一般需要十多分鐘時間,如何進一步節(jié)省這十多分鐘的黃金處理時間?將應急放班升級為預測式應急放班!提前幾分鐘預測到即將到來的大流量,提前放班。
這里涉及兩個模型,一個是服務量實時預測模型,該模型能根據實時數據如會員的操作行為,會員在小蜜的行為,故障場景,并結合歷史進線量來綜合預測某一技能組未來30分鐘每一分鐘的進線量。
有了服務量預測數據輸入后,應急放班模型就可以結合當前服務會員情況,未來30分鐘客服排班情況、會員消耗速度、溢出關系等綜合指標,來推斷出是否要觸發(fā)應急放班以及放班的服務量。一旦觸發(fā)應急放班后,線下通知模塊會通過電話、短信等手段來通知合適的客服來上班。
與調度機器不同,我們需要時刻考慮客服感受,為了避免打擾沒有上班意愿的客服,我們讓客服自主設置是否要接收通知。
4. 負載均衡:溢出、分流
盡管預測式應急放班效果不錯,但目前只針對云客服有效,對于SP類這種非選班類的客服怎么辦?我們發(fā)現,線上排隊時,往往是某幾個技能組出現大量排隊場景,比如商家線爆了,消費者線的客服可能處于空閑狀態(tài)。如何解決這種忙閑不均問題?一個直觀的極端想法就將所有的組變成一個大池子組,通過負載均衡分配讓每一個客服都處于繁忙狀態(tài),從而達到效率最大化。而事實上并不是所有的技能組之間都能互相承接,這里既要權衡業(yè)務,又要線下培訓讓客服具備多技能。
XSigma提供了技能組相互分流、溢出的配置功能,只要滿足觸發(fā)條件,就能實時分流溢出,解決了以往靠現場管理員手工改客服技能組的痛苦。
對于一些場景而言,技能組間的溢出粒度有點粗,比如設置了A技能組排隊可以溢出到B技能組,并不是B技能組的每一個客服都能承接A的業(yè)務,只有進行了培訓的客服才能承接,XSigma同樣提供了給客服打技能標簽的功能。
5. 垂直擴容:彈性+1
有些業(yè)務比較復雜,很難找到其他技能組進行溢出,我們將注意力轉到正在上班的客服上。在線客服可以同時服務多個會員,如果一個客服最大服務能力是3,那么他最多同時服務3個會員,這個值由管理員根據客服的歷史服務水平來設置。
我們發(fā)現盡管很多小二的最大并發(fā)能力是相同的,在他們滿負荷服務會員時,他們的服務水平有很大不同,他們的忙閑程度也有非常大的差異,為什么?
● 小二本身水平有差異
如下圖所示,某技能組的客服最大服務能力都是3,最近一個月這個技能組的客服在同時服務3個會員場景下的平均響應時間分布(平均響應時間正比于客服回復速度),可以看到數據呈一個大致正太分布,說明小二服務水平有差異。
● 場景不同
舉個例子,A和B兩個客服最大服務能力都是5,同樣都在處理5個會員,但是A的5個會員差不多都到會話結束尾聲了,B的5個會員都才剛剛開始,這個例子下A和B兩個客服當下的忙閑程度明顯不同。
既然小二的服務水平有差別,實際場景千差萬別,那能不能在技能組排隊時刻讓那些有余力的小二突破最大服務上限?
XSigma提供了兩種策略來讓小二突破服務上限。
1)主動+1模式
當技能組達到觸發(fā)條件時,XSigma會主動點亮客服工作臺的+1按鈕(如下圖紅框所示),客服可以點擊來主動增加一個會員進線,這種方式相當于是將擴容權利交給客服,因為只有客服自己知道目前忙不忙。
2)強制+1模式
如果某些技能組是強管控類型,可以選擇開啟強制+1模式,XSigma會結合數據自動選擇一些合適的客服來突破服務能力上限,比如他之前最大服務能力是5,我們會同時讓他服務6個會員。
6. 削峰填谷:預約回撥
對于熱線來說,小二不可能同時接好幾個電話,而且業(yè)務上可承接的線下客服也少,這時候如果出現大面積排隊怎么辦?
通過數據分析發(fā)現,很多技能組在一天內的繁忙度在波動,有高峰也有低峰,下圖所示展示了某技能組的剩余服務數,可以看到有兩個繁忙時間段,10~13點,17~21點,這兩個時間段的空閑服務數很多時候都是0,而其它時間段相對比較空閑,如果能將這些繁忙時間段的進線量騰挪到非繁忙時間段,這樣就能大大提升客服的人員利用率,也能避免客戶排隊的煩惱。
怎么做呢?通過預約回撥,將當下服務轉變?yōu)槲磥矸?。如下圖所示,主要有兩個模塊構成。
1)預約觸發(fā)器。用戶電話進來后,預約觸發(fā)器會根據技能組的繁忙情況,來判定是否要觸發(fā)預約;
2)回撥觸發(fā)器。采用系統(tǒng)主動外呼模式,一旦發(fā)現技能組繁忙度處于低峰,就會觸發(fā)回撥,只要用戶電話被接通,就會以高優(yōu)先級進入到分配環(huán)節(jié),從而讓客服人員在有效的工作時間內都在真正的與客戶通話。
7. 最優(yōu)分配
調度的目標是:“提升客服資源的利用率和服務水平,用更少的客服資源獲得更佳的用戶體驗”。前面這些策略的關注點更多是在提升客服資源利用率上,有沒有什么策略能提升用戶的滿意度?我們從分配這一環(huán)節(jié)入手。
本質上我們要解決的是“會員(任務)-客服匹配優(yōu)化”問題。在傳統(tǒng)模式下,分配就是從某技能組的排隊隊列中找到一個等待時間最長的會員,然后再找一個該技能組下最空閑的客服完成匹配。這種公平分配方式考慮維度單一,未能在全局層面上掌握和調度分配有關的會員、客服、問題等各類信息。
匹配優(yōu)化問題其實是二部圖匹配問題,如圖所示,在某一時刻,我們可以得到某技能組下未分配的客戶(任務)以及具備剩余服務能力的客服,如果能知道每個任務與每個客服之間的匹配概率,那就可以通過穩(wěn)定婚姻算法找到最佳匹配。
如何求得任務與客服之間的匹配概率?抽象為分類回歸問題,核心在于構建大量樣本(x1,x2,x3,…,xn)(y)。針對一通歷史會話任務,y是客戶評分或會話時長(目標可選),而x既包含了客服特征如過去30天的滿意度、平均響應時間等等離線指標,以及客服當前會話的服務會員數、最大會員數等實時指標,也包含了任務的特征,如問題類型、等待時間、訂單編號、重復咨詢次數等等。樣本有了后,下面就是選擇分類算法進行訓練,最終我們采用了CNN。
在迭代過程中發(fā)現,模型會將流量更多分配給好的客服,而指標相對較差的客服的流量則變少,為了避免少量客服上班接不到客反彈的情景,我們將公平性的指標引入到模型中。
8. 智能培訓:大黃機器人
通過最優(yōu)分配來提升滿意度的一個重要原因是將流量更多分給了能力強水平高的客服,而這部分客服的占比不高,為什么?為了應對11、12這兩個特殊月份的高流量,業(yè)務團隊要招募培訓大量的云客服。這些新手涌入必然會對滿意度帶來影響,換句話說,如果要想進一步提升滿意度指標,必須提升新手客服的服務水平。
對于新手,在上崗前提升他們水平的唯一方式就是培訓,傳統(tǒng)的培訓都是通過線下讓云客服看視頻等學習資料,然后進行筆試,通過后就直接上崗,帶來的問題是很多新客服對平臺的工具、解決方案都不熟悉就直接服務會員,會員體感較差。
對比練車場景,我們發(fā)現練車有科目1、科目2、科目3等不同流程,科目1學習理論,科目2和科目3實戰(zhàn)模擬,如果我們引入這種實戰(zhàn)模擬就能大大提升新客服的服務水平。
我們創(chuàng)新的提出了使用機器人(大黃)來培訓客服這一全新的客服培訓模式(已申請專利)。新客服在培訓租戶里,通過點擊大黃頭像,會產生一通非常真實的模擬會話,通過和會員聊天,不斷學習平臺工具使用,不斷提升解決客戶問題能力。一旦會話結束后,大黃機器人會對這通會話進行評價,并會告知應該使用某種具體的解決方案來回答用戶問題。
對于新客服,目前必須完成大黃80通會話后才能上崗,整個財年培訓客服幾萬人,服務會話量達到幾百萬輪次。abtest顯示通過大黃試崗的客服不管在滿意度、不滿意、平均響應時間、平均服務時長等各項指標上都有非常明顯提升。
9. 統(tǒng)一的調度中心
從上面可以看到我們的客服調度策略多且復雜,每種策略都起到了一定提升客服資源的利用率和服務水平的作用。現在的問題來了,不同場景下這么多策略如何選擇?比如現在技能組A突然排隊100個會員,這個時候是直接溢出到其他技能組,還是觸發(fā)主動+1或觸發(fā)應急放班呢?這里需要一個大腦來做決策。
如何讓這個大腦適用于各種復雜的業(yè)務場景是難點。我們平臺目前租戶就有幾十個,僅淘系這一個租戶就劃分了幾十個客服部門,每個部門下又細分了一系列技能組,不同部門間業(yè)務場景不同。在嚴重缺乏歷史數據積累情況下,很難直接通過訓練一個決策模型來適應多種業(yè)務。于是我們的思路就轉換為直接利用現場管理員的專家知識,讓他們將決策邏輯沉淀為一條條的規(guī)則。
目前平臺上已經配置了上萬條規(guī)則,每天生效的規(guī)則也有幾千條,這些數據的沉淀讓我們可以通過智能優(yōu)化技術實現真正的智能調度決策大腦。
10. 調度監(jiān)控大屏
客服調度策略繁多、邏輯復雜,調度結果會切實影響整個環(huán)節(jié)參與者的感受,因此我們搭建了XSigma調度大屏,方便大家理解。在實踐過程中發(fā)現調度大屏能建立起使用方對調度系統(tǒng)的信任感,降低開發(fā)人員和管理員發(fā)現、定位并解決系統(tǒng)問題的成本。舉個例子,管理員在XSigma平臺上設置一些規(guī)則,比如A技能組排隊數>=1觸發(fā)溢出到B技能組,設置完后他心里沒底,他也不知道設置的邏輯是否生效,往往會讓開發(fā)同學再次確定下有沒有生效,而現在有了可視化調度大屏,既能觀察到各個技能組的服務量、剩余服務量等實時監(jiān)控數據,也能看到實時調度各種策略生效的過程,以及每天調度的實時匯總明細數據。
11. 仿真演練
在調度優(yōu)化場景中,如何評估調度系統(tǒng)的好壞至關重要。有沒有一種手段能評估XSigma是否能適應各種場景?能提前證明在雙11這種大促期間也能順暢的調度?能及時發(fā)現調度過程中出現的問題?這不僅是我們也是業(yè)務同學迫切需要知道的。
仔細思考發(fā)現,要解決的問題和技術的全鏈路壓測要解決的問題很相似,我們要做的其實是業(yè)務上的全鏈路壓測,于是我們搭建了客服調度的仿真演練系統(tǒng)。
基于大黃機器人,我們已經能模擬會員進線,通過定制改造,機器人可以制造各種主題類型的題目,比如雙十一類型場景等。在此基礎上,結合業(yè)務同學的預估量,可以設置出各個技能組的進線量。
在雙十一之前,業(yè)務同學使用這套演練系統(tǒng)大規(guī)模演練過兩次,由于是基于真實服務量進行演練,而不是以前的口頭相傳的方式,讓調度上下游每一個參與的同學都有壓力感。在演練過程中發(fā)現的一些問題改進后,大大提升了我們應對大促突發(fā)流量的信心。
12. 小結
XSigma智能客服調度系統(tǒng)采用自動化配置、機器學習等技術,將復雜的調度問題分層處理,并在日益增長的會員任務基礎上,不斷精細化調度模型依賴的狀態(tài)預估數值,不斷提高調度模型的多目標規(guī)劃能力,同時通過大量運用平臺可視化技術,以實時、圖表化的方式將系統(tǒng)運行狀態(tài)呈現出來,最終在客服效率和用戶體驗時間上得到優(yōu)化效果。該系統(tǒng)上線后,相比于往年,服務不可用時長這一業(yè)務核心指標直接下降98%。
本文作者:力君
閱讀原文
本文來自云棲社區(qū)合作伙伴“阿里技術”,如需轉載請聯系原作者。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規(guī)行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://www.ezyhdfw.cn/yun/19807.html
摘要:今天,我們邀請阿里高級技術專家力君,為大家分享自動智能的客服調度系統(tǒng)。明確了客服調度的核心問題,也知道了難點,更看到了目前的現狀后,我們決定打造一款自動智能的客服調度系統(tǒng)。 小嘰導讀:提到調度,大家腦海中可能想起的是調度阿里云的海量機器資源,而對于阿里集團客戶體驗事業(yè)群(CCO)而言,我們要調度的不是機器,而是客服資源。今天,我們邀請阿里高級技術專家力君,為大家分享自動、智能的客服調度...
摘要:摘要據了解,借助阿里云,上汽乘用車實現了工程開發(fā)仿真能力升級,仿真計算效率提升了,使工程開發(fā)人員更加專注于產品設計和性能優(yōu)化,打造出世界級產品的高品質。 摘要: 據了解,借助阿里云,上汽乘用車實現了工程開發(fā)仿真能力升級,仿真計算效率提升了25%,使工程開發(fā)人員更加專注于產品設計和性能優(yōu)化,打造出世界級產品的高品質。今年北京車展上全球首秀的概念車MG X-Motion,其量產車的卓越整車...
摘要:嘉賓介紹張勁太云,阿里巴巴應用與基礎運維平臺產品與架構部高級開發(fā)工程師,主要負責測試環(huán)境研發(fā)和效能提升,喜歡開源。 摘要: 測試環(huán)境是研發(fā)/測試同學最常用的功能,穩(wěn)定性直接影響到研發(fā)效率,那如何提升測試環(huán)境的穩(wěn)定性?阿里巴巴應用與基礎運維平臺高級開發(fā)工程師張勁,通過阿里內部實踐,總結了一套測試環(huán)境穩(wěn)定性提升方法,供大家參考。 點此查看原文:http://click.aliyun.com...
摘要:今天的話題分四部分,第一個是小程序音視頻能拿來做什么,第二部分是將其內部是怎么做到的第三就是講騰訊視頻云的音視頻技術的一些技術細節(jié)第四個是介紹一下微信上做音視頻的應用的一些審核問題以及應對方案。 本文由云+社區(qū)發(fā)表 作者:常青 騰訊視頻云是做什么的?騰訊視頻云既不做數據庫,也不做存儲,也不做網絡,我們只做音視頻服務,也就是直播、點播、視頻通話、這類面向B類客戶的音視頻PAAS業(yè)務。 今...
摘要:昨天,阿里云又與神州數碼宣布達成戰(zhàn)略合作。胡曉明坦言,這兩年底層計算能力的爆發(fā)推動了阿里云人工智能技術的進步?;诖?,阿里云加大了對于人工智能的投入,并于去年開始將人工智能的服務和能力對外開放?! 」猸h(huán)新網日前公告已與亞馬遜在華子公司達成云服務運營協議。這意味著,作為國際巨頭的亞馬遜,正試圖借道本土公司在中國的監(jiān)管環(huán)境下運營公有云業(yè)務。然而,在阿里云總裁胡曉明看來,因受云計算重資產、重技術特...
閱讀 2200·2023-04-25 17:48
閱讀 3653·2021-09-22 15:37
閱讀 2990·2021-09-22 15:36
閱讀 6144·2021-09-22 15:06
閱讀 1696·2019-08-30 15:53
閱讀 1497·2019-08-30 15:52
閱讀 781·2019-08-30 13:48
閱讀 1187·2019-08-30 12:44