智慧診斷在客戶服務中心的應用

邊江濤 葉暉 汪亮

（中國電信安徽公司 安徽省合肥市 230000）

1 引言

客戶是企業生存的基石，如何為廣大客戶打造更加便捷、高效、更有溫度的產品服務，是企業面臨的重要任務?？头藛T在日常處理客戶投訴時，首先需要查詢客戶信息，然后分析判斷導致客戶投訴的原因，進而給出相應的處理建議。通過近年來統一客服信息門戶的建設，客戶信息查詢的便捷性已有很大提升，不再需要登錄到不同的業務系統查詢，但對于用戶問題原因的分析判斷仍依賴人工，而由于電信業務的復雜性，人工分析判斷耗時長，對人員業務能力要求高，且易出現誤判、不同人回復口徑不一致等問題。

針對上述問題，智慧診斷從具體業務場景切入，提供了一套從客戶信息查詢，到問題原因判斷，再到給出處理建議的端到端解決方案。其基本思路是：首先利用數據挖掘技術，分析輸出當前的熱點服務場景，然后針對具體場景，梳理固化處理流程和規則，實現問題原因的自動分析定位，最后匹配相應的處理建議，以診斷報告形式反饋給客服人員。

本文內容組織如下：第2 章是智慧診斷系統的整體介紹；第3章是智慧診斷系統設計的關鍵技術；第4 章是智慧診斷系統的應用效果；第5 章是總結和展望。

2 智慧診斷系統

2.1 智慧診斷業務流程

傳統的話務流程是用戶來電后，客服代表首先與用戶溝通，獲取用戶訴求，然后自行判斷用戶問題點，利用自身知識和經驗給出解決方案。本文提出的智慧診斷系統，可在獲取用戶訴求后，一鍵完成對用戶的問題定位，輸出全面準確的診斷報告，客服代表可根據診斷報告，對用戶問題做出快速處理，業務流程如圖1所示。

（1）10000 號話務員與客戶溝通，了解客戶的訴求。

（2）如客戶問題屬于智慧診斷支持的場景范圍，則選擇相應場景啟動診斷。例如手機上網資費爭議（流量診斷）、寬帶障礙、ITV（Interactive Television）障礙等，如圖2所示。

（3）智慧診斷系統根據場景的預設流程和規則，自動進行診斷，輸出診斷報告，給出客戶問題原因和處理建議。

如圖3所示為寬帶障礙診斷報告，通過自動診斷，系統判斷出導致客戶寬帶問題的原因是聯創平臺撥號報錯，并在相應的診斷問題環節提供遠程重置密碼或解除綁定的操作按鈕。

（4）10000 號客服代表根據診斷報告與客戶解釋溝通或進行相關業務處理。

2.2 智慧診斷系統模型

智慧診斷系統由診斷場景、診斷流程和環節、診斷因子、診斷規則、診斷報告5 個部分組成，智慧診斷系統模型各部分組成及關系如圖4。

圖1：智慧診斷業務流程

圖2：診斷場景分類示例圖

圖3：寬帶障礙診斷報告示例圖

2.2.1 診斷場景

即某個特定的業務場景，如手機上網、增值業務、寬帶障礙等。

2.2.2 診斷流程和環節

每個業務場景有一個針對該場景定制的診斷流程，流程包括多個診斷環節，流程可存在多個環節分支。

2.2.3 診斷因子

每個診斷環節可以調用1 個或多個診斷因子。診斷因子是診斷的最小單元，是組成一個診斷流程的原子服務，是判斷邏輯的具體實現。診斷因子可以在不同的場景復用。如“付費模式判斷”因子在各個資費類場景中均會用到。

圖4：智慧診斷系統模型

圖5：智慧診斷系統技術架構

診斷因子運行機制，首先是通過調用CRM（Customer Relationship Management）、計費等后臺服務，查詢到所需的客戶信息，然后調用規則組件，輸出診斷結果。

2.2.4 診斷規則

診斷規則是對業務邏輯的固化，診斷因子根據設定規則輸出診斷結果。結果包括診斷因子正常或異常的狀態描述，匹配診斷規則給出的問題原因和用戶建議，最后將每條診斷結果做拼接，作為診斷報告中的輸入信息。

2.2.5 診斷報告

診斷流程和環節執行完畢后，輸出相應的診斷報告，報告主要包括三個組成部分，一是客戶問題和處理建議，二是每個環節的診斷信息及是否正常，三是相關聯的操作鏈接，如查詳情、發送短信、業務退訂等。

2.3 智慧診斷系統技術架構

客服24 小時在線，且忙時并發量較大，對系統的性能、可靠性和擴展性要求較高。綜合考慮上述系統模型和用戶需求，系統采用了服務化架構設計實現，解耦為應用、能力、數據3 層，以提升系統整體處理速度、可靠性和擴展性，智慧診斷系統技術架構如圖5所示。

2.3.1 應用層

采用極簡化設計，系統按具體業務進行場景封裝，如手機上網、分月返還等，核心頁面包括診斷場景選擇、診斷過程展示和診斷報告，各診斷過程環節的診斷詳情按照一定規則組合，形成診斷報告，診斷報告放在頁面的最上方。應用層可以擴展，根據客戶投訴熱點的變化，封裝新的業務場景。

表1：流量特征期望信息

表2：停機特征期望信息

表3：返還特征期望信息

表4：流量樣本概率

表5：停機樣本概率

表6：返還樣本概率

表7：三種特征條件熵

表8：流量場景各環節特征增益計算結果

2.3.2 能力層

包括服務、流程、規則3 個核心模塊，服務模塊通過調用各業務系統的數據接口，查詢所需的各類客戶信息；流程模塊用于診斷環節的實現和診斷流程的編排；規則模塊用于診斷規則的配置。

2.3.3 數據層

表9：系統3 個月應用指標

包括數據庫和分布式緩存[1]，數據庫用于基礎數據的持久化存儲，分布式緩存用于加載診斷過程中頻繁使用的數據、規則、業務字典、流程配置等，以提升數據存取速度和流程執行性能，實現單個流程環節秒級運算。

3 智慧診斷系統設計的關鍵技術

3.1 通過ID3算法確定業務診斷場景并設計診斷流程

構建診斷場景前，首先需分析運營商業務和用戶投訴的相關性，確定哪些業務或者環節最易引發用戶的投訴，優先把這些相關性較高的業務建設成為智慧診斷的場景，本系統選用決策樹作為分析算法。

ID3[2]是決策樹學習的其中一種算法，ID3 算法認為“信息增益”高的屬性是好屬性，通過計算歷史數據中每個類別或屬性的“信息熵”獲得“信息增益”，并選擇“信息增益”最高的類別或屬性作為決策樹中的決策節點。因此我們利用ID3 算法計算每個特征的信息增益，以增益大小作為選擇某些業務作為診斷場景，以及場景中診斷流程和相關診斷環節編排的依據。下面我們以流量、停機、返還3 個特征與用戶投訴的相關性為例，說明如何根據不同特征的增益來選擇診斷場景，并設計流程的診斷環節。

我們取某客服中心6 個月的話務數據共193 萬條作為樣本數據集，按如下步驟分步計算熵值。

步驟一：計算信息熵。

193 萬條話務數據中包含投訴話務數據共225810 條，計算得到投訴概率為225810/1930000=11.7%，非投訴概率為1704190/1930000=88.3%。

根據信息熵計算公式：

得到結果為：

E(S)=-0.883*log20.883-0.117*log20.117 ≈0.522

步驟二：計算條件熵。

計算流量、停機、返還三種業務特征與用戶投訴一起出現的期望信息[3]，計算結果如表1、表2、表3所示。

再計算3 類特征劃分的各屬性樣本在總體數據中出現的樣本概率，其中P(c)=頻率/話務總量，計算結果如表4、表5、表6所示。

通過以上兩組值，根據決策樹條件熵計算公式：

以流量特征為例，E（投訴，流量）=0.566*×0.474+0.434×0.575≈0.5179，依次計算得到三種特征的條件熵如表7所示。

步驟三：根據信息增益計算公式：

Gain(T,X)=E(S)-E(T,X)

得到流量對投訴的信息增益為：Gain(投訴，流量)=0.522-0.5179=0.0041

依次計算可得停機信息增益是0.0005，返還信息增益是0.0001；可以看出流量與投訴的相關性遠高于停機和返還，因此我們優先選擇流量作為一種診斷場景，提高診斷場景與投訴業務的匹配度。

在流量場景的診斷流程中，我們根據詞頻再選取大流量、流量包、套餐、漫游、欠費、訂購、短信提醒等特征作為診斷環節，重復上述步驟，分別計算各個特征對流量投訴的增益值，所得結果如表8所示。

根據結果我們選擇欠費、漫游、流量包、套餐、短信提醒這5個與流量增益較大的特征作為診斷環節，因診斷流程為串行流程，我們選擇相關性較大的特征在流程前段診斷，可有效過濾大量異常用戶，避免進入不必要的診斷環節以及額外診斷環節查詢對接口性能的消耗，所以我們根據增益大小作為環節編排順序，從而提高診斷效率。

3.2 快速準確定位客戶問題原因

話務代表與用戶每次交互，等待服務時長不應超過15s，這就要求一個業務診斷場景需在15s 內完成分析，并提供診斷報告。這對于環節較少的簡單流程不是問題，但對于復雜流程（20 個環節以上），想滿足這一目標極其困難，需要把單個環節平均執行時間降到1s 以內，而大多數診斷環節都有數據接口調用操作，需獲取數據后再通過計算公式做邏輯判斷，且某些判斷規則復雜，計算量大，因此我們需要通過合理的技術手段，提升各環節執行效率。

3.2.1 基于流程引擎的多路分支，實現并行計算

為提升流程執行速度，針對流程中可能有多個走向的環節，且各個走向條件不互斥時，采取并行計算的方式，將流程按照并行多環節進行任務分解，每個環節按照配置的業務規則啟動各自線程并行計算，減少串行計算等待時間，提高流程的整體處理效率。

3.2.2 動態腳本語言實現靈活配置

智慧診斷系統使用Groovy[4]動態腳本語言實現故障原因自動診斷。通過梳理故障可能涉及的原因，將其拆分成一個一個的診斷元數據和故障原因判斷的診斷規則，元數據可以是欠費金額、用戶狀態、用戶余額或手機上網累積量等用戶故障可能的要素點，而故障原因判斷的診斷規則包括是否有省外流量、是否超出流量在訂購可選包之前等用戶故障判斷規則；通過服務、接口從外系統獲取元數據，與診斷規則組裝成診斷因子。診斷因子的條件腳本決定流程走向，結果腳本判斷診斷結果，異常腳本定位故障點；最后根據流程報告腳本對各診斷因子的診斷結果進行收集整理，得出流程診斷報告。使用Groovy 腳本可實現智能診斷的快速、靈活配置。

3.2.3 大數據助力提升海量數據查詢效率

運營商的流量話單數據規模在每月百億條左右，針對如此海量數據，傳統數據庫已無法滿足系統快速查詢的要求。因此我們采用Hadoop 開源框架，打通傳統關系型數據庫到Hbase 的轉儲接口，話單數據實時入庫，利用Hbase[5]對海量數據可快速查詢的優點，建立數據訪問接口，實現查詢的秒級響應。

3.3 清晰易懂的診斷報告

診斷報告是智慧診斷的最終輸出，通過一系列的診斷環節后，系統最終會將它判斷的結果以報告的形式展現給客服代表，如何提高報告的可讀性和準確性是一個關鍵技術。

我們對診斷報告采用了模板化和定制化結合的配置方式，首先根據用戶關注的熱點問題，將問題涉及業務信息配入報告模板，然后定制化地針對各診斷場景報告內容用自然語言重新組織，最后將展示結構重新分布，讓話務員一眼即可關注到自己最關心的問題。

4 系統實際應用效果

我們采集了手機上網資費爭議、增值業務資費爭議兩個場景的基礎數據，用以分析系統的實際使用效果。分析結果主要體現在平均通話時長、手機上網資費爭議的預處理率、增值業務資費爭議的預處理率這三個重要指標上。其中，預處理率指用戶咨詢或投訴問題在客服中心直接辦結，無需再向后臺部門派單的成功率，通過后臺監控系統取數，得到系統使用前后三個月各指標的值，詳見表9。

從表9 可看出，系統上線后業務投訴的解決效率有明顯提升，較好地滿足了客服中心提升服務效率的需求，為客服代表的日常工作提供了很好的工具支持。

5 總結與展望

智慧診斷系統有效集成各系統能力，設計出場景化智慧診斷流程，實現客戶熱點難點服務問題的快速解決，降低客服中心人工學習和培訓成本，有效推進了企業服務的智慧化。后期可結合WEB、微信等互聯網服務渠道，將診斷能力向用戶開放，實現用戶問題的自助診斷和處理，進一步降低客服人工服務壓力，提升服務效率。