商業的本質是讓客戶滿意，那么企業的呼叫中心則是售后服務的直接體現。今天我們繼續接著上一篇來講講呼叫中心數據金礦挖掘機系列之IVR。
1、管中窺馬
眾所周知，IVR在呼叫中心不是一個組件在戰斗，G廠喜歡的是群毆”，能量不夠數量來湊。當IVR提供語音自助式服務式，G廠當家的IVR平臺媒體服務器MCP/MediaServer需要溝通的服務包括：
- TTS文本語音引擎
- ASR語音識別引擎
- REST/SOAP HTTP服務
- Tomcat/IIS WebService
- Load Balancer負載均衡服務
- Httpproxy緩存代理
- JDBC數據庫服務
- CRM業務數據連接
如何有效監控這些外圍？這是個問題。
想您所想！為您先做！G廠的GVP平臺配合SNMP協議(V3)可以提供一系列的分析數據，可傳遞到專業的NMS系統(OpenView，etc)或者G廠的GVPReporting Server就可以提供。
有人就問了，我拿這些數據有什么用？
當然有用啦～一個很簡單又很難回答的問題：當您的呼叫中心有300路IVR時，你要準備多少路TTS呢？300路TTS嗎？呵呵～拍腦袋嗎？呵呵呵～IVR中的TTS-Usage數據就可以提供非常直觀的答案，給你秀出Peak/Average峰值/平均調用率，讓您有的放矢。
再舉一個？好，再來一個
一個不太簡單又不難回答的問題：呼叫中心的IT-Team如何去和公司IT-Business-CRM去較真他們的服務響應及不及時？
G廠的IVR數據中可以真實地體現外圍系統對IVR客戶服務中的響應情況，多少Http Request發出，收到多少Response返回？返回時間時多少？
所以我們應該重視這些數據，包括不限于：Latency時延數據、外部服務響應數據、端口調用率、峰值和均值使用率。
2、望山跑馬
呼叫中心本質上是有限的確定資源來服務無限的不確定的客戶來電/信/聊天。
這些資源既包括坐席，也包括自助式IVR服務。那么問題來了，什么時候知道IVR端口資源不夠用了？什么時候該擴容了？如何削峰填谷？我們同時需要IVR的統計數據來輔助決策，比如具體的媒體服務器數量、可用的IVR端口數量、具體某項語音流程的使用量(e.g.滿意度調查)。
3、回馬槍
沒有多少行業是比呼叫中心更重視客戶滿意度的吧，咱們有一大堆的KPI來衡量，主動放棄率Abandon Rate，一次接通率，首次問題解決率，客戶凈推薦值以及回訪客戶滿意度。有意思的問題來了：其他幾個KPI是算出來的，而滿意度是調查出來的。怎么調查？一般是客戶掛電話前座席主動引導調查，當然了，禮儀之邦的Nice客戶一般都很好說話。也有是客戶掛機后發短信回訪的，雖然回復免費但是人都有惰性，也有電子郵件自動觸發問詢的，也有網頁主動提示Webform問詢的，也有客戶掛機稍后或者一段時間后IVR來電回訪的，各種方案都可以做到。
最有效地，莫過于掛機前IVR引導在線調查，其次是事后IVR自動回訪。一般來說開發工程師需要IVR的Callflow里去記錄一些數據，收集后寫入數據庫，再做可視化分析，說實話，可以做，大部分也是這么做的，就是有些煩。
