項目編號 | 銷售價格(萬元) | 新需求 | 開發成本(萬元) | 開發成本中代碼編寫部分(萬元) | 開發成本中測試部分(萬元) | 利潤(萬元) | 穩定性(一年宕機的小時數) | BHCC |
1 | 10 | 0% | 0 | 0 | 10 | 10 | 10 | 30萬 |
2 | 10 | 10% | 10 | 4 | 6 | 0 | 10 | 30萬 |
3 | 10 | 10% | 10 | 4 | 6 | 0 | 10 | 30萬 |
4 | 10 | 10% | 10 | 4 | 6 | 0 | 10 | 30萬 |
5 | 10 | 10% | 10 | 4 | 6 | 0 | 10 | 30萬 |
6 | 10 | 10% | 10 | 4 | 6 | 0 | 10 | 30萬 |
7 | 10 | 10% | 10 | 4 | 6 | 0 | 10 | 30萬 |
8 | 10 | 10% | 10 | 4 | 6 | 0 | 10 | 30萬 |
9 | 10 | 10% | 10 | 4 | 6 | 0 | 10 | 30萬 |
10 | 10 | 10% | 10 | 4 | 6 | 0 | 10 | 30萬 |
我們可以看到,一年運營下來,軟件的穩定性沒有下降,每個項目宕機總時長都是10小時,每個項目的BHCC值都是30萬,但是企業只有10萬元的利潤,離預期100萬元的收益很遠。
還有一個隱藏很深,但是致命的問題,就是人員不夠了,需要擴招研發人員。為什么呢?因為軟件開發了一年,10%的修改需要的時間是1.2個月,只要發生兩個項目并行,就會出現人員不夠的情況,只能擴招1個研發人員,那么,一年運營下來,血本無歸。
國內大部分公司選擇的方案是如下的:
項目編號 | 銷售價格(萬元) | 新需求 | 開發成本(萬元) | 開發成本中代碼編寫部分 (萬元) | 開發成本中測試部分 (萬元) | 利潤(萬元) | 穩定性(一年宕機的小時數) | BHCC |
1 | 10 | 0% | 0 | 0 | 10 | 10 | 10 | 30萬 |
2 | 10 | 10% | 10 | 4 | 0 | 6 | 30 | 25萬 |
3 | 10 | 10% | 10 | 4 | 0 | 6 | 60 | 20萬 |
4 | 10 | 10% | 10 | 4 | 0 | 6 | 120 | 15萬 |
5 | 10 | 10% | 10 | 4 | 0 | 6 | 180 | 10萬 |
6 | 10 | 10% | 10 | 4 | 0 | 6 | 210 | 9萬 |
7 | 10 | 10% | 10 | 4 | 0 | 6 | 240 | 8萬 |
8 | 10 | 10% | 10 | 4 | 0 | 6 | 270 | 7萬 |
9 | 10 | 10% | 10 | 4 | 0 | 6 | 300 | 6萬 |
10 | 10 | 10% | 10 | 4 | 0 | 6 | 330 | 5萬 |
一年運營下來,企業只有64萬元的利潤,收益大幅提高,而且不需要擴招人員,可怕,穩定性降低很多很多,一年宕機到330小時,可能是每天宕機一次。BHCC值逐步下降到5萬。
還有一個隱藏很深,但是致命的問題,就是穩定性的問題是經常是乘法關系,即多個不穩定因素會關聯在一起,導致系統更加不穩定,因此一年宕機330小時的估算是非常保守的。
而對于客戶來說,導致眾多運營上技術問題的核心都在于軟件公司將測試成本省去,因為軟件公司可能活不下去。
二 靈活性
技術上問題的核心在于穩定性和靈活性的矛盾,即需求的滿足和變化的適應需要靈活性。現在再看看呼叫中心的靈活性產生的原因,靈活性有多么大,多么可怕。
呼叫中心系統靈活性產生的原因我認為有以下幾個方面:
- 新的通信方式的不斷產生;
- 新的行業不斷擴展;
- 新的計算機軟件技術的不斷發展;
- 新的業務模式的不斷創新;
- 新的管理方式的不斷深化;
從技術上來說,靈活性產生的原因是兩個方面,第一,整合的要求,第二,策略變化的要求。
(一)整合的要求
呼叫中心系統是一個全方位整合的系統,這一點我們很容易理解。
有一個上海的合作伙伴,我在和他的CTO聊天的時候,雙方都是感慨萬千。CTO說,他們是在語音板卡上開發的呼叫中心,做電視購物呼叫中心系統,有這樣一個問題:客戶提出了業務軟件的一個修改,他認為工作量不大,但具體做業務軟件的時候,發現需要修改坐席業務軟件,具體做坐席業務軟件的時候,發現需要修改軟電話…….最后,需要修改對語音卡的控制,總計需要修改7-8個模塊,而銷售只談了2萬元,而且這種事在他們公司經常發生。
對于很多的客戶,在系統整合的要求方面,他們確實要求很高,例如,在錄音調聽軟件中,需要整合各種監控信息、報表信息、客戶信息等等。甚至有的客戶認為呼叫中心的所有管理軟件應該按照Portal的概念組織。
呼叫中心的各個組成部分。PBX、CTI、ACD、IVR(包含傳真)、ADS(自動外撥系統)、ACC(短信、郵件等異步通信方式的呼叫中心)、ICC(Internet呼叫中心)、錄音服務器、錄音調聽軟件、坐席軟電話、坐席業務軟件、業務軟件,報表和實時統計,這些部分雖然數量不多,但是每一部分和其他交互很多,下面,我們分析一下交互,這種分析不是根據一個項目的需求分析的,而是大量項目的總結,也就是說如果你要想做一個可以在大量項目中復用的軟件,那么這些交互你必須都要想到,否則,你的軟件只能在少量的項目中使用。
整合產生的靈活性要求舉例:
1、PBX:這是整合要求最少、靈活性要求最低的。
它只和CTI整合,很慶幸,ITU、ECMA和微軟等等公司做了很多標準,我們按照標準做就行了,但是,還是有個別PBX廠商對標準支持的不好,需要CTI軟件去適應;
2、CTI:整合要求最多、靈活性要求最高,這部分是大家比較熟悉的:
a)ACD需要從CTI獲取交換機各種來電信息并通過CTI需要進行呼叫路由;
b)IVR需要從CTI獲取交換機各種來電信息并通過CTI需要進行呼叫控制;
c)ADS需要通過CTI需要進行外撥并從CTI獲取呼叫外撥結果;
d)錄音服務器需要從CTI獲取交換機各種呼叫信息形成相關的錄音記錄;
e)坐席軟電話需要通過CTI進行全方位的坐席電話操作和信息顯示;
f)報表需要從CTI獲取中繼、分機等呼叫信息并形成歷史報表數據;
g)實時統計需要實時從CTI獲取中繼、分機等呼叫信息并形成實時統計數據;
3、ACD:應該說整合要求很多、靈活性要求很高,這部分大家應該非常陌生:
a)IVR,分成三個方面,第一,ACD系統需要根據客戶來電在IVR輸入的信息,如業務分類,賬號等等信息來進行呼叫路由;第二,ACD系統在很多情況下是將呼叫物理駐留在IVR上,控制IVR進行排隊音樂和提示的播報和轉接操作;第三,ACD系統可能將呼叫路由到IVR,如在電話剛剛進入呼叫中心的時候,或者在做呼叫溢出的時候,這是ACD需要IVR占用情況的實時統計和命令IVR進入哪一個語音流程;
b)ADS,ADS對ACD的需要也全面,大體分成三個方面:第一,ADS外撥電話接通后,需要將呼叫通知ACD,讓ACD分配到一個最適合的坐席;第二,ADS在執行外撥算法的時候,需要根據ACD提供的歷史統計數據和實時統計數據,如每一個坐席或坐席組的歷史平均通話時長和當前每一個坐席的占用狀態;第三,ADS需要ACD配合呼入電話的需求,進行混合(Call Blending);
c)ACC,ACC的短信、郵件、傳真的請求需要ACD進行統一排隊和分配;
d)ICC,ICC的文本交談、電子白板、文件傳輸、護航瀏覽的請求需要ACD進行統一排隊和分配;
e)錄音服務器,錄音服務器需要對ACD的信息進行記錄,如坐席相關的信息,坐席姓名、工號、排隊情況、技能組等等;
f)坐席軟電話,軟電話需要和ACD系統進行交互,主要是坐席狀態管理、技能管理、分組管理等等,并且ACD要根據軟電話的狀態進行呼叫路由和分配;
g)報表,ACD需要產生大量的報表數據以供運營分析和輔助決策,如呼叫排隊情況、呼叫分配情況、坐席狀態的統計、坐席工作量統計等等;
h)實時統計,ACD需要以實時統計的形式提供現場管理的手段;
4、ADS(自動外撥系統):
a)ACC(短信、郵件等異步通信方式的呼叫中心),ACC同樣需要主動發起,需要ADS統一管理;
b)錄音服務器,需要記錄外撥特有的錄音信息,如外撥時長,還需要錄制客戶應答之前的聲音;
c)坐席軟電話,屏幕彈出等操作需要和ADS進行配合;
d)業務軟件,需要對外撥的任務管理、外撥客戶資料管理方面與ADS交互;
e)報表,需要形成ADS相關的各種報表,以便調整外撥策略;
f)實時統計,兩個方面,一方面ADS需要形成實時統計的數據,以供管理人員進行實時調整干預,另外一方面,外撥算法需要根據實時統計數據執行外撥算法,尤其是在預測外撥的情況下;
5、ACC(短信、郵件等異步通信方式的呼叫中心):
a)錄音服務器,短信、郵件等媒體,同樣需要進行坐席質量管理;
b)錄音調聽軟件,對于短信、郵件等媒體,需要特定的瀏覽器去顯示;
c)坐席軟電話,在坐席操作界面需要對短信和郵件進行顯示和坐席操作,需要配合坐席業務軟件進行客戶資料管理和知識庫調用;
d)坐席業務軟件,配合實現與電話相同的處理流程;
e)業務軟件,配合實現與電話相同的處理流程;
f)報表,實現與電話相同的歷史統計;
g)實時統計,實現與電話相同的實時統計來實現現場管理;
6、ICC(Internet呼叫中心):
a)錄音服務器,同ACC;
b)錄音調聽軟件,同ACC;
c)坐席軟電話,同ACC;
d)坐席業務軟件,同ACC;
e)業務軟件,同ACC;
f)報表,同ACC;
g)實時統計,同ACC;
7、錄音服務器:
a)錄音調聽軟件,很自然,錄音調聽軟件和錄音服務器進行交互,展示給運營管理者,以便進行質量考核;
b) 坐席軟電話,錄音的啟動和停止、錄音記錄的信息需要軟電話提供;
c) 坐席業務軟件;兩個方向,方向一,坐席業務軟件可以隨時根據權限調聽錄音服務器中的錄音,以便業務關聯和信息補充錄入,方向二,坐席業務軟件需要為錄音記錄補充需要的信息,如質檢人員可以在錄音調聽軟件中看到產品信息和訂購信息;
d) 業務軟件,業務軟件的訂單、工單信息,經常要直接關聯錄音文件;
e) 實時統計,錄音的狀態需要實時統計,展現給運營管理者;
8、錄音調聽軟件:
a) 坐席業務軟件,很多坐席業務軟件要求內置錄音調聽軟件;
b) 業務軟件,很多業務軟件要求內置錄音調聽軟件,同時,錄音調聽軟件經常需要同時獲取業務軟件的數據,以便進行質檢;
c) 報表和實時統計,很多錄音記錄的信息需要來源于報表,同時,很多錄音調聽軟件需要內置報表和實時統計,進行統一的顯示;
9、坐席軟電話
a)坐席業務軟件,大家很容易理解,這是呼叫中心必須的;
b)業務軟件,大家很容易理解,坐席業務軟件和業務本來就是一體的;
10、坐席業務軟件
a)報表,坐席自我管理經常需要進行報表的顯示,如顯示本坐席或本組坐席歷史的平均通話時長、平均應答次數、平均轉接次數等等;
b) 實時統計,坐席自我管理經常需要進行實時統計的顯示,如顯示本坐席或本組坐席實時的平均通話時長、平均應答次數、平均轉接次數等等;
11、業務軟件、報表、實時統計
很多客戶會要求為了運營分析方便,將業務的實時統計信息、業務的歷史統計信息、呼叫的實時統計信息、呼叫的歷史統計信息在一個軟件中顯示,有的要求在中間件中顯示,有的要求在業務軟件中顯示。
(二)流程策略的要求
和其他的軟件一樣,呼叫中心軟件存在大量的需要隨時調整地流程和策略,如IVR流程、呼叫路由流程、呼叫分配策略、外撥策略、報警策略、坐席狀態管理策略等。
(三)穩定性和靈活性的矛盾
如果沒有整合的要求、沒有流程策略的不斷變化,呼叫中心就可以很穩定,就像我們經常見到的電話交換機、網絡交換機、打印機一樣;
如果沒有不間斷運行的要求、性能的要求,呼叫中心就可以很靈活,就像我們經常見到的OA軟件、CRM和ERP軟件一樣。
呼叫中心就是呼叫中心,需要解決這個矛盾,我們不得不演進到第五代呼叫中心”,下一篇,我們看看一種基于SOA思想的解決方案。