邊江濤 葉暉 汪亮

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

1 引言

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

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

本文內(nèi)容組織如下：第2 章是智慧診斷系統(tǒng)的整體介紹；第3章是智慧診斷系統(tǒng)設(shè)計(jì)的關(guān)鍵技術(shù)；第4 章是智慧診斷系統(tǒng)的應(yīng)用效果；第5 章是總結(jié)和展望。

2 智慧診斷系統(tǒng)

2.1 智慧診斷業(yè)務(wù)流程

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

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

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

（3）智慧診斷系統(tǒng)根據(jù)場景的預(yù)設(shè)流程和規(guī)則，自動進(jìn)行診斷，輸出診斷報(bào)告，給出客戶問題原因和處理建議。

如圖3所示為寬帶障礙診斷報(bào)告，通過自動診斷，系統(tǒng)判斷出導(dǎo)致客戶寬帶問題的原因是聯(lián)創(chuàng)平臺撥號報(bào)錯，并在相應(yīng)的診斷問題環(huán)節(jié)提供遠(yuǎn)程重置密碼或解除綁定的操作按鈕。

（4）10000 號客服代表根據(jù)診斷報(bào)告與客戶解釋溝通或進(jìn)行相關(guān)業(yè)務(wù)處理。

2.2 智慧診斷系統(tǒng)模型

智慧診斷系統(tǒng)由診斷場景、診斷流程和環(huán)節(jié)、診斷因子、診斷規(guī)則、診斷報(bào)告5 個(gè)部分組成，智慧診斷系統(tǒng)模型各部分組成及關(guān)系如圖4。

圖1：智慧診斷業(yè)務(wù)流程

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

圖3：寬帶障礙診斷報(bào)告示例圖

2.2.1 診斷場景

即某個(gè)特定的業(yè)務(wù)場景，如手機(jī)上網(wǎng)、增值業(yè)務(wù)、寬帶障礙等。

2.2.2 診斷流程和環(huán)節(jié)

每個(gè)業(yè)務(wù)場景有一個(gè)針對該場景定制的診斷流程，流程包括多個(gè)診斷環(huán)節(jié)，流程可存在多個(gè)環(huán)節(jié)分支。

2.2.3 診斷因子

每個(gè)診斷環(huán)節(jié)可以調(diào)用1 個(gè)或多個(gè)診斷因子。診斷因子是診斷的最小單元，是組成一個(gè)診斷流程的原子服務(wù)，是判斷邏輯的具體實(shí)現(xiàn)。診斷因子可以在不同的場景復(fù)用。如“付費(fèi)模式判斷”因子在各個(gè)資費(fèi)類場景中均會用到。

圖4：智慧診斷系統(tǒng)模型

圖5：智慧診斷系統(tǒng)技術(shù)架構(gòu)

診斷因子運(yùn)行機(jī)制，首先是通過調(diào)用CRM（Customer Relationship Management）、計(jì)費(fèi)等后臺服務(wù)，查詢到所需的客戶信息，然后調(diào)用規(guī)則組件，輸出診斷結(jié)果。

2.2.4 診斷規(guī)則

診斷規(guī)則是對業(yè)務(wù)邏輯的固化，診斷因子根據(jù)設(shè)定規(guī)則輸出診斷結(jié)果。結(jié)果包括診斷因子正?；虍惓５臓顟B(tài)描述，匹配診斷規(guī)則給出的問題原因和用戶建議，最后將每條診斷結(jié)果做拼接，作為診斷報(bào)告中的輸入信息。

2.2.5 診斷報(bào)告

診斷流程和環(huán)節(jié)執(zhí)行完畢后，輸出相應(yīng)的診斷報(bào)告，報(bào)告主要包括三個(gè)組成部分，一是客戶問題和處理建議，二是每個(gè)環(huán)節(jié)的診斷信息及是否正常，三是相關(guān)聯(lián)的操作鏈接，如查詳情、發(fā)送短信、業(yè)務(wù)退訂等。

2.3 智慧診斷系統(tǒng)技術(shù)架構(gòu)

客服24 小時(shí)在線，且忙時(shí)并發(fā)量較大，對系統(tǒng)的性能、可靠性和擴(kuò)展性要求較高。綜合考慮上述系統(tǒng)模型和用戶需求，系統(tǒng)采用了服務(wù)化架構(gòu)設(shè)計(jì)實(shí)現(xiàn)，解耦為應(yīng)用、能力、數(shù)據(jù)3 層，以提升系統(tǒng)整體處理速度、可靠性和擴(kuò)展性，智慧診斷系統(tǒng)技術(shù)架構(gòu)如圖5所示。

2.3.1 應(yīng)用層

采用極簡化設(shè)計(jì)，系統(tǒng)按具體業(yè)務(wù)進(jìn)行場景封裝，如手機(jī)上網(wǎng)、分月返還等，核心頁面包括診斷場景選擇、診斷過程展示和診斷報(bào)告，各診斷過程環(huán)節(jié)的診斷詳情按照一定規(guī)則組合，形成診斷報(bào)告，診斷報(bào)告放在頁面的最上方。應(yīng)用層可以擴(kuò)展，根據(jù)客戶投訴熱點(diǎn)的變化，封裝新的業(yè)務(wù)場景。

表1：流量特征期望信息

表2：停機(jī)特征期望信息

表3：返還特征期望信息

表4：流量樣本概率

表5：停機(jī)樣本概率

表6：返還樣本概率

表7：三種特征條件熵

表8：流量場景各環(huán)節(jié)特征增益計(jì)算結(jié)果

2.3.2 能力層

包括服務(wù)、流程、規(guī)則3 個(gè)核心模塊，服務(wù)模塊通過調(diào)用各業(yè)務(wù)系統(tǒng)的數(shù)據(jù)接口，查詢所需的各類客戶信息；流程模塊用于診斷環(huán)節(jié)的實(shí)現(xiàn)和診斷流程的編排；規(guī)則模塊用于診斷規(guī)則的配置。

2.3.3 數(shù)據(jù)層

表9：系統(tǒng)3 個(gè)月應(yīng)用指標(biāo)

包括數(shù)據(jù)庫和分布式緩存[1]，數(shù)據(jù)庫用于基礎(chǔ)數(shù)據(jù)的持久化存儲，分布式緩存用于加載診斷過程中頻繁使用的數(shù)據(jù)、規(guī)則、業(yè)務(wù)字典、流程配置等，以提升數(shù)據(jù)存取速度和流程執(zhí)行性能，實(shí)現(xiàn)單個(gè)流程環(huán)節(jié)秒級運(yùn)算。

3 智慧診斷系統(tǒng)設(shè)計(jì)的關(guān)鍵技術(shù)

3.1 通過ID3算法確定業(yè)務(wù)診斷場景并設(shè)計(jì)診斷流程

構(gòu)建診斷場景前，首先需分析運(yùn)營商業(yè)務(wù)和用戶投訴的相關(guān)性，確定哪些業(yè)務(wù)或者環(huán)節(jié)最易引發(fā)用戶的投訴，優(yōu)先把這些相關(guān)性較高的業(yè)務(wù)建設(shè)成為智慧診斷的場景，本系統(tǒng)選用決策樹作為分析算法。

ID3[2]是決策樹學(xué)習(xí)的其中一種算法，ID3 算法認(rèn)為“信息增益”高的屬性是好屬性，通過計(jì)算歷史數(shù)據(jù)中每個(gè)類別或?qū)傩缘摹靶畔㈧亍鲍@得“信息增益”，并選擇“信息增益”最高的類別或?qū)傩宰鳛闆Q策樹中的決策節(jié)點(diǎn)。因此我們利用ID3 算法計(jì)算每個(gè)特征的信息增益，以增益大小作為選擇某些業(yè)務(wù)作為診斷場景，以及場景中診斷流程和相關(guān)診斷環(huán)節(jié)編排的依據(jù)。下面我們以流量、停機(jī)、返還3 個(gè)特征與用戶投訴的相關(guān)性為例，說明如何根據(jù)不同特征的增益來選擇診斷場景，并設(shè)計(jì)流程的診斷環(huán)節(jié)。

我們?nèi)∧晨头行? 個(gè)月的話務(wù)數(shù)據(jù)共193 萬條作為樣本數(shù)據(jù)集，按如下步驟分步計(jì)算熵值。

步驟一：計(jì)算信息熵。

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

根據(jù)信息熵計(jì)算公式：

得到結(jié)果為：

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

步驟二：計(jì)算條件熵。

計(jì)算流量、停機(jī)、返還三種業(yè)務(wù)特征與用戶投訴一起出現(xiàn)的期望信息[3]，計(jì)算結(jié)果如表1、表2、表3所示。

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

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

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

步驟三：根據(jù)信息增益計(jì)算公式：

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

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

依次計(jì)算可得停機(jī)信息增益是0.0005，返還信息增益是0.0001；可以看出流量與投訴的相關(guān)性遠(yuǎn)高于停機(jī)和返還，因此我們優(yōu)先選擇流量作為一種診斷場景，提高診斷場景與投訴業(yè)務(wù)的匹配度。

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

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

3.2 快速準(zhǔn)確定位客戶問題原因

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

3.2.1 基于流程引擎的多路分支，實(shí)現(xiàn)并行計(jì)算

為提升流程執(zhí)行速度，針對流程中可能有多個(gè)走向的環(huán)節(jié)，且各個(gè)走向條件不互斥時(shí)，采取并行計(jì)算的方式，將流程按照并行多環(huán)節(jié)進(jìn)行任務(wù)分解，每個(gè)環(huán)節(jié)按照配置的業(yè)務(wù)規(guī)則啟動各自線程并行計(jì)算，減少串行計(jì)算等待時(shí)間，提高流程的整體處理效率。

3.2.2 動態(tài)腳本語言實(shí)現(xiàn)靈活配置

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

3.2.3 大數(shù)據(jù)助力提升海量數(shù)據(jù)查詢效率

運(yùn)營商的流量話單數(shù)據(jù)規(guī)模在每月百億條左右，針對如此海量數(shù)據(jù)，傳統(tǒng)數(shù)據(jù)庫已無法滿足系統(tǒng)快速查詢的要求。因此我們采用Hadoop 開源框架，打通傳統(tǒng)關(guān)系型數(shù)據(jù)庫到Hbase 的轉(zhuǎn)儲接口，話單數(shù)據(jù)實(shí)時(shí)入庫，利用Hbase[5]對海量數(shù)據(jù)可快速查詢的優(yōu)點(diǎn)，建立數(shù)據(jù)訪問接口，實(shí)現(xiàn)查詢的秒級響應(yīng)。

3.3 清晰易懂的診斷報(bào)告

診斷報(bào)告是智慧診斷的最終輸出，通過一系列的診斷環(huán)節(jié)后，系統(tǒng)最終會將它判斷的結(jié)果以報(bào)告的形式展現(xiàn)給客服代表，如何提高報(bào)告的可讀性和準(zhǔn)確性是一個(gè)關(guān)鍵技術(shù)。

我們對診斷報(bào)告采用了模板化和定制化結(jié)合的配置方式，首先根據(jù)用戶關(guān)注的熱點(diǎn)問題，將問題涉及業(yè)務(wù)信息配入報(bào)告模板，然后定制化地針對各診斷場景報(bào)告內(nèi)容用自然語言重新組織，最后將展示結(jié)構(gòu)重新分布，讓話務(wù)員一眼即可關(guān)注到自己最關(guān)心的問題。

4 系統(tǒng)實(shí)際應(yīng)用效果

我們采集了手機(jī)上網(wǎng)資費(fèi)爭議、增值業(yè)務(wù)資費(fèi)爭議兩個(gè)場景的基礎(chǔ)數(shù)據(jù)，用以分析系統(tǒng)的實(shí)際使用效果。分析結(jié)果主要體現(xiàn)在平均通話時(shí)長、手機(jī)上網(wǎng)資費(fèi)爭議的預(yù)處理率、增值業(yè)務(wù)資費(fèi)爭議的預(yù)處理率這三個(gè)重要指標(biāo)上。其中，預(yù)處理率指用戶咨詢或投訴問題在客服中心直接辦結(jié)，無需再向后臺部門派單的成功率，通過后臺監(jiān)控系統(tǒng)取數(shù)，得到系統(tǒng)使用前后三個(gè)月各指標(biāo)的值，詳見表9。

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

5 總結(jié)與展望

智慧診斷系統(tǒng)有效集成各系統(tǒng)能力，設(shè)計(jì)出場景化智慧診斷流程，實(shí)現(xiàn)客戶熱點(diǎn)難點(diǎn)服務(wù)問題的快速解決，降低客服中心人工學(xué)習(xí)和培訓(xùn)成本，有效推進(jìn)了企業(yè)服務(wù)的智慧化。后期可結(jié)合WEB、微信等互聯(lián)網(wǎng)服務(wù)渠道，將診斷能力向用戶開放，實(shí)現(xiàn)用戶問題的自助診斷和處理，進(jìn)一步降低客服人工服務(wù)壓力，提升服務(wù)效率。