一種用戶滿意度管理系統(tǒng)及其進(jìn)行呼叫管理的方法
【專利摘要】本發(fā)明公開了一種用戶滿意度管理系統(tǒng)及其進(jìn)行呼叫管理的方法，所述方法包括：獲取核心網(wǎng)側(cè)檢測到的呼叫中心座席與用戶間異常呼叫的檢測消息；提取所述檢測消息中攜帶的失敗原因碼，并根據(jù)所述失敗原因碼判定本次異常呼叫的類型；基于所述異常呼叫的類型以及預(yù)先設(shè)定的回?fù)懿呗裕袛嗪艚兄行膫?cè)是否需要呼叫回?fù)?，?dāng)需要時(shí)，通知呼叫中心向所述用戶發(fā)起呼叫。本發(fā)明所述方法在不影響原有呼叫系統(tǒng)呼叫功能及流程的情況下，將用戶滿意度管理系統(tǒng)疊加到呼叫中心系統(tǒng)上，并通過用戶滿意度管理系統(tǒng)完成對異常呼叫的原因提取、分析等，實(shí)現(xiàn)對非用戶原因?qū)е碌暮艚兄袛噙M(jìn)行合理性的呼叫回?fù)?，很好的解決了用戶服務(wù)滿意度下降的問題。
【專利說明】一種用戶滿意度管理系統(tǒng)及其進(jìn)行呼叫管理的方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及通信【技術(shù)領(lǐng)域】，尤其涉及一種用戶滿意度管理系統(tǒng)及其進(jìn)行呼叫管理的方法。
【背景技術(shù)】
[0002]呼叫中心(Call Center)又稱為客戶服務(wù)中心，是一種基于計(jì)算機(jī)通訊集成技術(shù)、充分利用通信網(wǎng)和計(jì)算機(jī)網(wǎng)的多項(xiàng)功能集成，并與企業(yè)連為一體的綜合信息服務(wù)系統(tǒng)，是一組座席或公司的業(yè)務(wù)代表集中進(jìn)行來話處理、發(fā)出呼叫與用戶聯(lián)系的一個專門的系統(tǒng)。呼叫中心能向用戶提供電話、傳真、電子郵件等多種業(yè)務(wù)，主要用來處理用戶對企業(yè)提出的要求、投訴、建議和咨詢等，如電信業(yè)中的10000，金融業(yè)中的95555等。
[0003]隨首云計(jì)算技術(shù)的跨越式發(fā)展，云呼叫中心的應(yīng)用越來越廣泛，接入的網(wǎng)絡(luò)也較復(fù)雜，存在著因這樣那樣的網(wǎng)絡(luò)原因?qū)е碌暮艚兄袛?，進(jìn)而導(dǎo)致被服務(wù)的用戶體驗(yàn)差，用戶對服務(wù)不滿意等問題。

【發(fā)明內(nèi)容】

[0004]鑒于上述問題，提出了本發(fā)明以便提供一種克服上述問題或者至少部分地解決上述問題的用戶滿意度管理系統(tǒng)及其進(jìn)行呼叫管理的方法。
[0005]依據(jù)本發(fā)明的一個方面，提供了一種用戶滿意度管理系統(tǒng)進(jìn)行呼叫管理的方法，包括:
[0006]獲取核心網(wǎng)側(cè)檢測到的呼叫中心座席與用戶間異常呼叫的檢測消息；
[0007]提取所述檢測消息中攜帶的失敗原因碼，并根據(jù)所述失敗原因碼判定本次異常呼叫的類型；
[0008]基于所述異常呼叫的類型以及預(yù)先設(shè)定的回?fù)懿呗?，判斷呼叫中心?cè)是否需要呼叫回?fù)?，?dāng)需要時(shí)，通知呼叫中心向所述用戶發(fā)起呼叫。
[0009]進(jìn)一步地，本發(fā)明所述方法中，所述異常呼叫的類型包括:呼叫在核心網(wǎng)側(cè)中斷、被叫方接收到呼叫后中斷、以及通話過程中中斷。
[0010]進(jìn)一步地，本發(fā)明所述方法中，所述預(yù)先設(shè)定的回?fù)懿呗园?所述異常呼叫的類型為呼叫在核心網(wǎng)側(cè)中斷時(shí)，和/或，所述異常呼叫的類型為被叫方收到呼叫后中斷時(shí)，設(shè)定為呼叫中心側(cè)需要進(jìn)行呼叫回?fù)堋?br> [0011]進(jìn)一步地，本發(fā)明所述方法中，當(dāng)呼叫中心座席為主叫方時(shí)，所述預(yù)先設(shè)定的回?fù)懿呗赃M(jìn)一步包括:
[0012]當(dāng)判定所述異常呼叫的類型為呼叫在核心網(wǎng)側(cè)中斷或者為被叫方收到呼叫后中斷時(shí)，檢測呼叫中心側(cè)發(fā)起本次呼叫的發(fā)起觸發(fā)事件的重要級別是否滿足預(yù)先設(shè)定的級別要求，當(dāng)滿足時(shí)，設(shè)定為呼叫中心側(cè)需要進(jìn)行呼叫回?fù)堋?br> [0013]進(jìn)一步地，本發(fā)明所述方法中，根據(jù)所述失敗原因碼判定本次異常呼叫的類型時(shí)，還包括:按著所述異常呼叫的類型，對本次異常呼叫進(jìn)行本地存儲；[0014]進(jìn)一步地，本發(fā)明所述方法中，當(dāng)判斷出呼叫中心側(cè)需要進(jìn)行呼叫回?fù)軙r(shí)，通知呼叫中心立即向所述用戶發(fā)起呼叫；或者，通知呼叫中心在設(shè)定的回?fù)軙r(shí)間到達(dá)時(shí)，向所述用戶發(fā)起呼叫。
[0015]依據(jù)本發(fā)明的另一個方面，提供了一種用戶滿意度管理系統(tǒng)，包括:
[0016]網(wǎng)絡(luò)檢測模塊，用于獲取核心網(wǎng)側(cè)檢測到的呼叫中心座席與用戶間異常呼叫的檢測消息，并提取所述檢測消息中攜帶的失敗原因碼；
[0017]異常會話管理模塊，用于根據(jù)所述失敗原因碼判定本次異常呼叫的類型，并基于所述異常呼叫的類型以及預(yù)先設(shè)定的回?fù)懿呗裕袛嗪艚兄行膫?cè)是否需要呼叫回?fù)?，?dāng)需要時(shí)，觸發(fā)用戶回訪模塊；
[0018]用戶回訪模塊，用于通知呼叫中心向所述用戶發(fā)起呼叫。
[0019]進(jìn)一步地，本發(fā)明所述系統(tǒng)中，所述異常會話管理模塊中異常呼叫的類型包括呼叫在核心網(wǎng)側(cè)中斷、被叫方接收到呼叫后中斷、以及通話過程中中斷。
[0020]進(jìn)一步地，本發(fā)明所述系統(tǒng)中，所述異常會話管理模塊中預(yù)先設(shè)定的回?fù)懿呗园?所述異常呼叫的類型為呼叫在核心網(wǎng)側(cè)中斷時(shí)，和/或，所述異常呼叫的類型為被叫方收到呼叫后中斷時(shí)，設(shè)定為呼叫中心側(cè)需要進(jìn)行呼叫回?fù)堋?br> [0021]進(jìn)一步地，本發(fā)明所述系統(tǒng)中，當(dāng)呼叫中心座席為主叫方時(shí)，所述異常會話管理模塊中預(yù)先設(shè)定的回?fù)懿呗赃M(jìn)一步包括:
[0022]當(dāng)判定所述異常呼叫的類型為呼叫在核心網(wǎng)側(cè)中斷或者為被叫方收到呼叫后中斷時(shí)，檢測呼叫中心側(cè)發(fā)起本次呼叫的發(fā)起觸發(fā)事件的重要級別是否滿足預(yù)先設(shè)定的級別要求，當(dāng)滿足時(shí)，設(shè)定為呼叫中心側(cè)需要進(jìn)行呼叫回?fù)堋?br> [0023]進(jìn)一步地，本發(fā)明所述系統(tǒng)中，所述異常會話管理模塊，進(jìn)一步用于在根據(jù)所述失敗原因碼判定本次異常呼叫的類型時(shí)，按著所述異常呼叫的類型，對本次異常呼叫進(jìn)行本地存儲；
[0024]進(jìn)一步地，本發(fā)明所述系統(tǒng)中，所述用戶回訪模塊，具體用于基于所述異常會話管理模塊的觸發(fā)，通知呼叫中心立即向所述用戶發(fā)起呼叫；或者，通知呼叫中心在設(shè)定的回?fù)軙r(shí)間到達(dá)時(shí)，向所述用戶發(fā)起呼叫。
[0025]本發(fā)明有益效果如下:
[0026]本發(fā)明通過在原有呼叫中心的基礎(chǔ)上疊加一個用戶滿意度管理系統(tǒng)，通過該系統(tǒng)完成對異常呼叫的原因提取、分析等，實(shí)現(xiàn)對非用戶原因?qū)е碌暮艚兄袛噙M(jìn)行合理性的呼叫回?fù)?，提高了對于呼叫異常丟失的異常保護(hù)處理的能力，在不額外花費(fèi)金錢提升網(wǎng)絡(luò)質(zhì)量的情況下，通過業(yè)務(wù)側(cè)的合理改造，進(jìn)一步提升了用戶的滿意度，很好的解決了現(xiàn)有技術(shù)中存在的問題。
【專利附圖】

【附圖說明】
[0027]為了更清楚地說明本發(fā)明實(shí)施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實(shí)施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作一簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實(shí)施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動性的前提下，還可以根據(jù)這些附圖獲得其他的附圖。
[0028]圖1為本發(fā)明實(shí)施例中用戶滿意度管理系統(tǒng)與呼叫中心系統(tǒng)的疊加示意圖；[0029]圖2為本發(fā)明實(shí)施例提供的一種用戶滿意度管理系統(tǒng)進(jìn)行呼叫管理的方法的流程圖；
[0030]圖3為本發(fā)明實(shí)施例提供的一種用戶滿意度管理系統(tǒng)的結(jié)構(gòu)示意圖。
【具體實(shí)施方式】
[0031]下面將結(jié)合本發(fā)明實(shí)施例中的附圖，對本發(fā)明實(shí)施例中的技術(shù)方案進(jìn)行清楚、完整地描述，顯然，所描述的實(shí)施例僅僅是本發(fā)明一部分實(shí)施例，而不是全部的實(shí)施例。基于本發(fā)明中的實(shí)施例，本領(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實(shí)施例，都屬于本發(fā)明保護(hù)的范圍。
[0032]為了提高呼叫中心為用戶服務(wù)的滿意度，本發(fā)明實(shí)施例提供一種用戶滿意度管理系統(tǒng)及其進(jìn)行呼叫管理的方法，所述方法和系統(tǒng)在不影響原有呼叫系統(tǒng)呼叫功能及流程的情況下，將用戶滿意度管理系統(tǒng)USMS (User Satisfaction Manage System)疊加到呼叫中心系統(tǒng)上，并通過用戶滿意度管理系統(tǒng)完成對異常呼叫的原因提取、分析等，實(shí)現(xiàn)對非用戶原因?qū)е碌暮艚兄袛噙M(jìn)行合理性的呼叫回?fù)?，很好的解決了用戶服務(wù)滿意度下降的問題。其中，用戶滿意度管理系統(tǒng)USMS與呼叫中心系統(tǒng)的疊加示意圖如圖1所示。
[0033]方法實(shí)施例
[0034]如圖2所示，本發(fā)明實(shí)施例提供一種用戶滿意度管理系統(tǒng)進(jìn)行呼叫管理的方法，具體包括:
[0035]步驟S201，獲取核心網(wǎng)側(cè)檢測到的呼叫中心座席與用戶間異常呼叫的檢測消息；
[0036]步驟S202，提取檢測消息中攜帶的失敗原因碼，并根據(jù)失敗原因碼判定本次異常呼叫的類型；
[0037]本發(fā)明實(shí)施例中，優(yōu)選地，將異常呼叫類型總結(jié)為三種，分別為:呼叫在核心網(wǎng)側(cè)中斷、被叫方接收到呼叫后中斷、以及通話過程中中斷。
[0038]本發(fā)明實(shí)施例中，便于呼叫中心對呼叫失敗原因的查詢，優(yōu)選地，在根據(jù)所述失敗原因碼判定本次異常呼叫的類型后，按著異常呼叫的類型，對本次異常呼叫進(jìn)行本地存儲。
[0039]步驟S203，基于異常呼叫的類型以及預(yù)先設(shè)定的回?fù)懿呗?，判斷呼叫中心?cè)是否需要呼叫回?fù)埽?dāng)需要時(shí)，通知呼叫中心向所述用戶發(fā)起呼叫。
[0040]其中，預(yù)先設(shè)定的回?fù)懿呗园ǖ幌抻跒?所述異常呼叫的類型為呼叫在核心網(wǎng)側(cè)中斷時(shí)，和/或，所述異常呼叫的類型為被叫方收到呼叫后中斷時(shí)，設(shè)定為呼叫中心側(cè)需要進(jìn)行呼叫回?fù)堋?br> [0041 ] 優(yōu)選地，本發(fā)明實(shí)施例中，當(dāng)呼叫中心座席為主叫方時(shí)，所述預(yù)先設(shè)定的回?fù)懿呗赃M(jìn)一步包括:
[0042]當(dāng)判定異常呼叫的類型為呼叫在核心網(wǎng)側(cè)中斷或者為被叫方收到呼叫后中斷時(shí)，檢測呼叫中心側(cè)發(fā)起本次呼叫的發(fā)起觸發(fā)事件的重要級別是否滿足預(yù)先設(shè)定的級別要求，當(dāng)滿足時(shí)，設(shè)定為呼叫中心側(cè)需要進(jìn)行呼叫回?fù)堋?br> [0043]進(jìn)一步地，步驟S203中，當(dāng)判斷出呼叫中心側(cè)需要進(jìn)行呼叫回?fù)軙r(shí)，通知呼叫中心立即向所述用戶發(fā)起呼叫；或者，通知呼叫中心在設(shè)定的回?fù)軙r(shí)間到達(dá)時(shí)，向所述用戶發(fā)起呼叫。其中，具體采用哪種時(shí)間策略進(jìn)行回?fù)埽梢宰孕信渲?，本發(fā)明實(shí)施例不做具體限定。[0044]為了更清楚的說明本發(fā)明所述方法的具體實(shí)現(xiàn)過程，下面通過一具體示例對本發(fā)明的實(shí)現(xiàn)過程進(jìn)行進(jìn)一步闡述。
[0045]本示例以呼叫中心向用戶發(fā)起呼叫為例，具體實(shí)現(xiàn)方式如下:
[0046]步驟1，坐席通過呼叫中心向用戶發(fā)起呼叫；
[0047]步驟2，核心網(wǎng)側(cè)對所述呼叫進(jìn)行呼叫連接，當(dāng)發(fā)生呼叫異常時(shí)，向用戶滿意度管理系統(tǒng)發(fā)送18X振鈴消息或者4XX異常掛機(jī)消息；
[0048]其中，呼叫異常包括如下任意一種情況:呼叫不可達(dá)、呼叫無應(yīng)答、呼叫被拒絕、被叫方關(guān)機(jī)、通話異常中斷等等。
[0049]步驟3，用戶滿意度管理系統(tǒng)獲取核心網(wǎng)側(cè)發(fā)送的18X振鈴消息或者4XX異常掛機(jī)消息，從該消息中分析并獲取失敗原因碼；
[0050]步驟4，用戶滿意度管理系統(tǒng)根據(jù)所述失敗原因碼，對本次異常呼叫進(jìn)行歸類，并記錄到系統(tǒng)中。
[0051]步驟5，用戶滿意度管理系統(tǒng)根據(jù)預(yù)先設(shè)定的回?fù)懿呗?，判斷是否需要呼叫回?fù)埽?br> [0052]其中，預(yù)先設(shè)定的回?fù)懿呗园?所述異常呼叫的類型為呼叫在核心網(wǎng)側(cè)中斷或者被叫方收到呼叫后中斷，且呼叫中心側(cè)發(fā)起本次呼叫的發(fā)起觸發(fā)事件的重要級別滿足預(yù)先設(shè)定的級別要求時(shí)，設(shè)定為呼叫中心側(cè)需要進(jìn)行呼叫回?fù)堋?br> [0053]下面通過一例子對上述策略進(jìn)行解釋說明:假設(shè)座席向用戶發(fā)起的呼叫為不可達(dá)，此時(shí)，用戶滿意度管理系統(tǒng)需要進(jìn)一步獲取座席發(fā)起本次呼叫的原因事件(如，通知用戶目前優(yōu)惠方案、通知用戶運(yùn)營商的新套餐等等)，通過該原因事件來判斷回?fù)艿谋匾?。對此，可以根?jù)事件重要/緊急程度，依次對各事件進(jìn)行等級劃分，對于認(rèn)為是重要的事件，設(shè)定為滿足回?fù)軛l件。
[0054]當(dāng)然，上述策略僅僅是眾多策略中的一種，本領(lǐng)域技術(shù)人員可以根據(jù)具體需求進(jìn)行策略設(shè)定，但其基本思想都在本發(fā)明的保護(hù)范圍之內(nèi)。
[0055]步驟6，當(dāng)需要回?fù)軙r(shí)，通知呼叫中心立即或者在特定時(shí)間后對所述用戶進(jìn)行呼叫回?fù)堋?br> [0056]上述方法有效降低了因運(yùn)營商網(wǎng)絡(luò)原因?qū)е碌挠脩舨粷M情緒，同時(shí)從另外一個層面上看，卻提升了用戶對運(yùn)營商周到細(xì)致的服務(wù)的滿意程度。
[0057]系統(tǒng)實(shí)施例
[0058]如圖3所示，本發(fā)明實(shí)施例提供一種用戶滿意度管理系統(tǒng)，包括:
[0059]網(wǎng)絡(luò)檢測模塊310，用于獲取核心網(wǎng)側(cè)檢測到的呼叫中心座席與用戶間異常呼叫的檢測消息，并提取所述檢測消息中攜帶的失敗原因碼；
[0060]異常會話管理模塊320，用于根據(jù)所述失敗原因碼判定本次異常呼叫的類型，并基于所述異常呼叫的類型以及預(yù)先設(shè)定的回?fù)懿呗?，判斷呼叫中心?cè)是否需要呼叫回?fù)?，?dāng)需要時(shí)，觸發(fā)用戶回訪模塊330 ；
[0061]用戶回訪模塊330，用于通知呼叫中心向所述用戶發(fā)起呼叫。
[0062]本發(fā)明實(shí)施例中，異常會話管理模塊320中異常呼叫的類型包括呼叫在核心網(wǎng)側(cè)中斷、被叫方接收到呼叫后中斷、以及通話過程中中斷。
[0063]進(jìn)一步地，異常會話管理模塊320中預(yù)先設(shè)定的回?fù)懿呗园?異常呼叫的類型為呼叫在核心網(wǎng)側(cè)中斷時(shí)，和/或，異常呼叫的類型為被叫方收到呼叫后中斷時(shí)，設(shè)定為呼叫中心側(cè)需要進(jìn)行呼叫回?fù)堋?br> [0064]優(yōu)選地，當(dāng)呼叫中心座席為主叫方時(shí)，異常會話管理模塊320中預(yù)先設(shè)定的回?fù)懿呗赃M(jìn)一步包括:
[0065]當(dāng)判定所述異常呼叫的類型為呼叫在核心網(wǎng)側(cè)中斷或者為被叫方收到呼叫后中斷時(shí)，檢測呼叫中心側(cè)發(fā)起本次呼叫的發(fā)起觸發(fā)事件的重要級別是否滿足預(yù)先設(shè)定的級別要求，當(dāng)滿足時(shí)，設(shè)定為呼叫中心側(cè)需要進(jìn)行呼叫回?fù)堋?br> [0066]進(jìn)一步地，本發(fā)明實(shí)施例中，便于呼叫中心對呼叫失敗原因的查詢，優(yōu)選地，異常會話管理模塊320，還用于在根據(jù)所述失敗原因碼判定本次異常呼叫的類型時(shí)，按著所述異常呼叫的類型，對本次異常呼叫進(jìn)行本地存儲；
[0067]進(jìn)一步地，本發(fā)明實(shí)施例中，用戶回訪模塊330，具體用于基于異常會話管理模塊320的觸發(fā)，通知呼叫中心立即向所述用戶發(fā)起呼叫；或者，通知呼叫中心在設(shè)定的回?fù)軙r(shí)間到達(dá)時(shí)，向所述用戶發(fā)起呼叫。
[0068]為了更清楚的說明本發(fā)明所述系統(tǒng)的具體實(shí)現(xiàn)過程，下面通過一具體示例對本發(fā)明的實(shí)現(xiàn)過程進(jìn)行進(jìn)一步闡述。
[0069]本示例以呼叫中心向用戶發(fā)起呼叫為例，具體實(shí)現(xiàn)方式如下:
[0070]步驟1，坐席通過呼叫中心向用戶發(fā)起呼叫；
[0071]步驟2，核心網(wǎng)側(cè)對所述呼叫進(jìn)行呼叫連接，當(dāng)發(fā)生呼叫異常時(shí)，向用戶滿意度管理系統(tǒng)中網(wǎng)絡(luò)檢測模塊發(fā)送18X振鈴消息或者4XX異常掛機(jī)消息；
[0072]其中，呼叫異常包括如下任意一種情況:呼叫不可達(dá)、呼叫無應(yīng)答、呼叫被拒絕、被叫方關(guān)機(jī)、通話異常中斷等等。
[0073]步驟3，網(wǎng)絡(luò)檢測模塊獲取核心網(wǎng)側(cè)發(fā)送的18X振鈴消息或者4XX異常掛機(jī)消息，從該消息中分析并獲取失敗原因碼；
[0074]步驟4，異常會話管理模塊根據(jù)所述失敗原因碼，對本次異常呼叫進(jìn)行歸類，并記錄到系統(tǒng)中；
[0075]步驟5，異常會話管理模塊根據(jù)預(yù)先設(shè)定的回?fù)懿呗?，判斷是否需要呼叫回?fù)埽?br> [0076]其中，預(yù)先設(shè)定的回?fù)懿呗园?所述異常呼叫的類型為呼叫在核心網(wǎng)側(cè)中斷或者被叫方收到呼叫后中斷，且呼叫中心側(cè)發(fā)起本次呼叫的發(fā)起觸發(fā)事件的重要級別滿足預(yù)先設(shè)定的級別要求時(shí)，設(shè)定為呼叫中心側(cè)需要進(jìn)行呼叫回?fù)堋?br> [0077]下面通過一例子對上述策略進(jìn)行解釋說明:假設(shè)座席向用戶發(fā)起的呼叫為不可達(dá)，此時(shí)，異常會話管理模塊需要進(jìn)一步獲取座席發(fā)起本次呼叫的原因事件(如，通知用戶目前優(yōu)惠方案、通知用戶運(yùn)營商的新套餐等等)，通過該原因事件來判斷回?fù)艿谋匾浴Υ?，可以根?jù)事件重要/緊急程度，依次對各事件進(jìn)行等級劃分，對于認(rèn)為是重要的事件，設(shè)定為滿足回?fù)軛l件。
[0078]當(dāng)然，上述策略僅僅是眾多策略中的一種，本領(lǐng)域技術(shù)人員可以根據(jù)具體需求進(jìn)行策略設(shè)定，但其基本思想都在本發(fā)明的保護(hù)范圍之內(nèi)。
[0079]步驟6，當(dāng)需要回?fù)軙r(shí)，用戶回訪模塊通知呼叫中心立即或者在特定時(shí)間后對所述用戶進(jìn)行呼叫回?fù)堋?br> [0080]上述系統(tǒng)有效降低了因運(yùn)營商網(wǎng)絡(luò)原因?qū)е碌挠脩舨粷M情緒，同時(shí)從另外一個層面上看，卻提升了用戶對運(yùn)營商周到細(xì)致的服務(wù)的滿意程度。[0081]顯然，本領(lǐng)域的技術(shù)人員可以對本發(fā)明進(jìn)行各種改動和變型而不脫離本發(fā)明的精神和范圍。這樣，倘若本發(fā)明的這些修改和變型屬于本發(fā)明權(quán)利要求及其等同技術(shù)的范圍之內(nèi)，則本發(fā)明也意圖包含這些改動和變型在內(nèi)。
【權(quán)利要求】
1.一種用戶滿意度管理系統(tǒng)進(jìn)行呼叫管理的方法，其特征在于，包括: 獲取核心網(wǎng)側(cè)檢測到的呼叫中心座席與用戶間異常呼叫的檢測消息； 提取所述檢測消息中攜帶的失敗原因碼，并根據(jù)所述失敗原因碼判定本次異常呼叫的類型； 基于所述異常呼叫的類型以及預(yù)先設(shè)定的回?fù)懿呗?，判斷呼叫中心?cè)是否需要呼叫回?fù)?，?dāng)需要時(shí)，通知呼叫中心向所述用戶發(fā)起呼叫。
2.如權(quán)利要求1所述的方法，其特征在于，所述異常呼叫的類型包括:呼叫在核心網(wǎng)側(cè)中斷、被叫方接收到呼叫后中斷、以及通話過程中中斷。
3.如權(quán)利要求2所述的方法，其特征在于，所述預(yù)先設(shè)定的回?fù)懿呗园?所述異常呼叫的類型為呼叫在核心網(wǎng)側(cè)中斷時(shí)，和/或，所述異常呼叫的類型為被叫方收到呼叫后中斷時(shí)，設(shè)定為呼叫中心側(cè)需要進(jìn)行呼叫回?fù)堋?br> 4.如權(quán)利要求3所述的方法，其特征在于，當(dāng)呼叫中心座席為主叫方時(shí)，所述預(yù)先設(shè)定的回?fù)懿呗赃M(jìn)一步包括: 當(dāng)判定所述異常呼叫的類型為呼叫在核心網(wǎng)側(cè)中斷或者為被叫方收到呼叫后中斷時(shí)，檢測呼叫中心側(cè)發(fā)起本次呼叫的發(fā)起觸發(fā)事件的重要級別是否滿足預(yù)先設(shè)定的級別要求，當(dāng)滿足時(shí)，設(shè)定為呼叫中心側(cè)需要進(jìn)行呼叫回?fù)堋?br> 5.如權(quán)利要求1至4任一項(xiàng)所述的方法，其特征在于， 所述方法中，根據(jù)所述失敗原因碼判定本次異常呼叫的類型時(shí)，還包括:按照所述異常呼叫的類型，對本次異常呼叫進(jìn)行本地存儲； 所述方法中，當(dāng)判斷出呼叫中心側(cè)需要進(jìn)行呼叫回?fù)軙r(shí)，通知呼叫中心立即向所述用戶發(fā)起呼叫；或者，通知呼叫中心在`設(shè)定的回?fù)軙r(shí)間到達(dá)時(shí)，向所述用戶發(fā)起呼叫。
6.一種用戶滿意度管理系統(tǒng)，其特征在于，包括: 網(wǎng)絡(luò)檢測模塊，用于獲取核心網(wǎng)側(cè)檢測到的呼叫中心座席與用戶間異常呼叫的檢測消息，并提取所述檢測消息中攜帶的失敗原因碼； 異常會話管理模塊，用于根據(jù)所述失敗原因碼判定本次異常呼叫的類型，并基于所述異常呼叫的類型以及預(yù)先設(shè)定的回?fù)懿呗?，判斷呼叫中心?cè)是否需要呼叫回?fù)埽?dāng)需要時(shí)，觸發(fā)用戶回訪模塊； 用戶回訪模塊，用于通知呼叫中心向所述用戶發(fā)起呼叫。
7.如權(quán)利要求6所述的用戶滿意度管理系統(tǒng)，其特征在于，所述異常會話管理模塊中異常呼叫的類型包括呼叫在核心網(wǎng)側(cè)中斷、被叫方接收到呼叫后中斷、以及通話過程中中斷。
8.如權(quán)利要求7所述的用戶滿意度管理系統(tǒng)，其特征在于，所述異常會話管理模塊中預(yù)先設(shè)定的回?fù)懿呗园?所述異常呼叫的類型為呼叫在核心網(wǎng)側(cè)中斷時(shí)，和/或，所述異常呼叫的類型為被叫方收到呼叫后中斷時(shí)，設(shè)定為呼叫中心側(cè)需要進(jìn)行呼叫回?fù)堋?br> 9.如權(quán)利要求8所述的用戶滿意度管理系統(tǒng)，其特征在于，當(dāng)呼叫中心座席為主叫方時(shí)，所述異常會話管理模塊中預(yù)先設(shè)定的回?fù)懿呗赃M(jìn)一步包括: 當(dāng)判定所述異常呼叫的類型為呼叫在核心網(wǎng)側(cè)中斷或者為被叫方收到呼叫后中斷時(shí)，檢測呼叫中心側(cè)發(fā)起本次呼叫的發(fā)起觸發(fā)事件的重要級別是否滿足預(yù)先設(shè)定的級別要求，當(dāng)滿足時(shí)，設(shè)定為呼叫中心側(cè)需要進(jìn)行呼叫回?fù)堋?br> 10.如權(quán)利要求6至9任一項(xiàng)所述的用戶滿意度管理系統(tǒng)，其特征在于， 所述異常會話管理模塊，進(jìn)一步用于在根據(jù)所述失敗原因碼判定本次異常呼叫的類型時(shí)，按照所述異常呼叫的類型，對本次異常呼叫進(jìn)行本地存儲； 所述用戶回訪模 塊，具體用于基于所述異常會話管理模塊的觸發(fā)，通知呼叫中心立即向所述用戶發(fā)起呼叫；或者，通知呼叫中心在設(shè)定的回?fù)軙r(shí)間到達(dá)時(shí)，向所述用戶發(fā)起呼叫。
【文檔編號】H04L12/24GK103685779SQ201210335521
【公開日】2014年3月26日 申請日期:2012年9月12日 優(yōu)先權(quán)日:2012年9月12日
【發(fā)明者】柯文鋒 申請人:中興通訊股份有限公司