第五章 技術(shù)的設(shè)計(二)
李寶民 2005/03/17
5.2 企業(yè)顧客關(guān)系管理解決方案

5.3 服務(wù)請求
。。多渠道的客戶關(guān)系管理措施將要求用于傳送公司需要的功能。基本上,通過"雙重渠道"將較容易進行目標(biāo)系統(tǒng)服務(wù),也可用于電話和互聯(lián)網(wǎng)客戶。
但是,有一部分服務(wù)是向來不適合電話渠道的。如今大多數(shù)服務(wù)可以通過郵件或人工進行,因為客戶要求獲得比電話中更多的信息。除傳統(tǒng)的公司渠道外,這些服務(wù)將利用互聯(lián)網(wǎng)渠道進行,。
部門 |
服務(wù)內(nèi)容 |
渠道
|
需要的支持辦公 |
所有 |
公司范圍直接 |
呼叫中心 |
互聯(lián)網(wǎng) |
服務(wù) |
服務(wù)查詢 |
√ |
√ |
√ |
清單 |
查核清單水平 |
√ |
√ |
√ |
投訴 |
對服務(wù)和/或產(chǎn)品的投訴 |
√ |
√ |
√ |
市場 |
市場運作事務(wù)要求 |
√ |
√ |
√ |
銷售 |
推銷產(chǎn)品和/或服務(wù) |
√ |
√ |
√ |
維護 |
報告事故和故障 |
√ |
√ |
√ |
。。下面的圖表說明了目標(biāo)系統(tǒng)如何使委托客戶服務(wù)請求和申請的。另外,目標(biāo)系統(tǒng)從各部門調(diào)配公司員工履行/解答服務(wù)請求,傳達請求的解決辦法。
Figure: System Request System Concept

。。為了提供請求的服務(wù),目標(biāo)系統(tǒng)要以企業(yè)CRM方案為基礎(chǔ),該方案是為委托客戶和客戶服務(wù)專業(yè)人員制定的,可以幫助他們輕松地提交、獲取、處理和跟蹤服務(wù)情況,并且快速準(zhǔn)確地解決問題。
具體說明,運行呼叫中心系統(tǒng)的CRM方案必須:
- 對公司現(xiàn)有產(chǎn)品和服務(wù)水平表示不滿
- 標(biāo)準(zhǔn)基礎(chǔ)上--允許應(yīng)用程序改進(不需要改變"編碼"),適應(yīng)公司不斷變化的需求和運行策略
- 可延伸--支持公司提供的發(fā)展中的服務(wù)"清單"
- 可提高--使公司能夠支持隨時間不斷增加的使用目標(biāo)系統(tǒng)的委托客戶數(shù)量。
更詳細地說,運行目標(biāo)系統(tǒng)的企業(yè)CRM方案應(yīng)含有下列內(nèi)容:
- 應(yīng)用和登記辦法:能夠收集并處理(綜合后備辦公辦法支持)登記和應(yīng)用信息,以便公司服務(wù)、許可、執(zhí)照和事件的處理。
- 服務(wù)請求辦法:能夠收集客戶服務(wù)請求,以便通過電話和互聯(lián)網(wǎng)渠道提供服務(wù)。
- 百科全書:提供信息知識庫,其中包含公司服務(wù)、聯(lián)絡(luò)信息、按時間排列的事件和活動表、方針和步驟,以及其他可以使用的客戶服務(wù)信息。
- 聯(lián)絡(luò)中心統(tǒng)計:能夠收集和分析關(guān)于實際時間服務(wù)代表生產(chǎn)力的廣泛的統(tǒng)計數(shù)據(jù),包括回應(yīng)和處理時間、呼叫完成比率、放棄呼叫比率、平均呼叫長度,以及忙音百分比。服務(wù)代表生產(chǎn)力數(shù)字可使經(jīng)理跟蹤服務(wù)代表的目標(biāo)完成及生產(chǎn)情況。
? 呼叫電子郵件:能夠?qū)⒖蛻舻碾娮余]件發(fā)送給適合的服務(wù)代表,使客戶和終端用戶通過互聯(lián)網(wǎng)取得服務(wù)請求許可,訪問信息庫。
- 聯(lián)絡(luò)分配:按規(guī)則進行工作量分配,保證將知識最豐富、最有用、最適合的客戶服務(wù)自動分配給進行服務(wù)請求或客戶聯(lián)絡(luò)的人。
- 聯(lián)絡(luò)史:記錄客戶相互作用,包括呼叫發(fā)送、服務(wù)請求狀況、服務(wù)代表聯(lián)絡(luò)信息,以及互聯(lián)網(wǎng)活動。呼叫和互聯(lián)網(wǎng)的遞交歷史有助于分析呼叫種類和服務(wù)質(zhì)量。
- 操作任務(wù):能夠形成、分配、發(fā)送、分類和操作處理從客戶聯(lián)絡(luò)渠道取得的服務(wù)請求。
- 外部知識庫鏈接:提供鏈接,使組織或產(chǎn)品信息能夠形成、儲存和管理,從而有助于處理客戶服務(wù)請求和詢問。 ? 工作流:自動發(fā)送文件和工作條目給在個別服務(wù)發(fā)送過程中負(fù)責(zé)執(zhí)行具體步驟的人員。工作流能力能夠分析和智能化執(zhí)行公司業(yè)務(wù)步驟。
- Quick Star-up Out of Box:提供一個健全的整體的解決辦法,能夠滿足關(guān)于客戶呼叫/互聯(lián)網(wǎng)聯(lián)絡(luò)中心的基本功能要求。Out-of-box
辦法減少了運行成本和時間,并且比客戶辦法有更少的內(nèi)在風(fēng)險。
- 屏幕定制:可使用戶將屏幕用戶化,反映其偏好或具體的業(yè)務(wù)要求。用戶選擇想要的個人屏幕種類--如服務(wù)請求、協(xié)議和服務(wù)信息--此外使用過濾器--如"顯示所有服務(wù)請求","只打開服務(wù)請求",和"只打開過去7天提交的服務(wù)請求"。
- 環(huán)球網(wǎng)連接:允許公司服務(wù)代表通過公共網(wǎng)絡(luò)設(shè)施如互聯(lián)網(wǎng)支持公司內(nèi)外的聯(lián)系和事務(wù)。能夠通過互聯(lián)網(wǎng)聯(lián)系、知識庫和客戶資助服務(wù)建立和維持委托客戶關(guān)系。
- 報告:允許服務(wù)代表和經(jīng)理利用多種有用的預(yù)備或特別報告匯報、分析和散發(fā)客戶服務(wù)相關(guān)信息。利用第三方報告工具和辦公自動操作技術(shù)制定報告。
- 跟蹤重復(fù)發(fā)生的問題:使服務(wù)代表能夠持續(xù)、快速、準(zhǔn)確地回復(fù)各種委托客戶的詢問和服務(wù)請求。運用解決方案,逐步加強記錄并跟蹤客戶呼叫聯(lián)系和互聯(lián)網(wǎng)聯(lián)系。
- 架構(gòu):能夠按照行業(yè)標(biāo)準(zhǔn)、開放式服務(wù)平臺、網(wǎng)絡(luò)協(xié)議和數(shù)據(jù)庫平臺,以及客戶平臺運行。
5.5 后臺辦公集成中間件
。。呼叫中心系統(tǒng)將與許多公司遺留數(shù)據(jù)和新型后臺辦公方案相結(jié)合。該系統(tǒng)的客戶接待和處理部分也將結(jié)合企業(yè)支付系統(tǒng),支持提供可支付服務(wù)。結(jié)合后臺辦公系統(tǒng)的工作將利用中間件技術(shù)進行。
。。中間件在運行系統(tǒng)和網(wǎng)絡(luò)服務(wù)間形成了分布式應(yīng)用程序組件的連通性。這些服務(wù)一般利用應(yīng)用程序接口(API)使用,并通過某組服務(wù)執(zhí)行,這組服務(wù)能夠使應(yīng)用程序組件:
- 內(nèi)部運行而不需考慮潛在的計算機架構(gòu)。可以通過把應(yīng)用程序組件從運行環(huán)境和相關(guān)架構(gòu)中分離出來進行這一工作。分離利用一個抽象接口和可從原運行環(huán)境分離出應(yīng)用程序組件的中間件API進行。
- 內(nèi)部運行而不需考慮網(wǎng)絡(luò)架構(gòu)。這一功能通常稱為"聯(lián)系橋梁"或"傳送橋梁",它促進了運行環(huán)境間運用各種網(wǎng)絡(luò)協(xié)議進行聯(lián)系。當(dāng)應(yīng)用程序組件要在各網(wǎng)絡(luò)諸如TCP/IP.SNA,IPX/SPX和X.25之間分配時,這種功能是很有必要的。
- 共享數(shù)據(jù)和使用參數(shù)而不需考慮運行程序和網(wǎng)絡(luò)。此功能通過"數(shù)據(jù)翻譯"和"參數(shù)調(diào)度"服務(wù)進行。數(shù)據(jù)翻譯服務(wù)保證了以本機格式為分配的應(yīng)用程序組件提供數(shù)據(jù)。例如,可能需要將數(shù)據(jù)從EBCDIC翻譯成ASCII,在不同字節(jié)次序間轉(zhuǎn)換,或者在不同數(shù)據(jù)表示類型間轉(zhuǎn)換。參數(shù)調(diào)度為網(wǎng)絡(luò)傳輸預(yù)備了數(shù)據(jù)架構(gòu)并由分配的應(yīng)用程序組件使用。例如,當(dāng)使用指示器時,參數(shù)調(diào)度服務(wù)負(fù)責(zé)識別參考數(shù)據(jù),復(fù)制數(shù)據(jù)及準(zhǔn)備網(wǎng)絡(luò)傳輸,傳輸后不壓縮數(shù)據(jù),根據(jù)對分配的應(yīng)用程序組件的價值進行發(fā)送。
。。大多數(shù)商用中間件系統(tǒng)建立在遠程呼叫或信息發(fā)送和信息排隊技術(shù)的基礎(chǔ)上。服務(wù)方面,兩者本質(zhì)上提供同種功能:它們都促進了分布式應(yīng)用程序組件的進程間通信。

。。不過在技術(shù)上二者有很大區(qū)別。例如,遠程過程調(diào)用(RPC)中間件以過程調(diào)用類似概念為基礎(chǔ),本質(zhì)上會發(fā)生同步化和堵塞。
因此,RPC基礎(chǔ)的中間件要求:
- 客戶程序和服務(wù)器在服務(wù)請求期間同時可用
- 客戶等候服務(wù)器應(yīng)答后再進行其他工作
。。顯然,這種程序模式已不適用了。舉例來說,即使不是服務(wù)請求時間,公司也可能要收集、儲存、給后臺辦公系統(tǒng)傳達服務(wù)請求信息。如果技術(shù)同步化,使用RPC是不能進行這些工作的。同樣地,服務(wù)請求系統(tǒng)也可能需要同時查詢各個后臺辦公系統(tǒng)。使用RPC系統(tǒng)也不可能進行工作,因為技術(shù)堵塞,需要客戶等候遞交請求的回復(fù),然后再遞交別的請求。下面的圖表說明了這一過程。

。。RPC技術(shù)的一個替換方案是信息發(fā)送中間件。信息發(fā)送和信息排隊技術(shù)利用信息傳送和排隊技術(shù)支持應(yīng)用程序進程間通信。信息傳送模式可使客戶通過發(fā)送信息給服務(wù)器呼叫API并發(fā)送服務(wù)請求。許多運行過程中,信息發(fā)送模式通過排隊和保證發(fā)送措施得到提高,可以非常靈活并不同步地儲存,進行聯(lián)絡(luò)。這種不同步模式加上綜合傳送橋梁服務(wù)系統(tǒng),可以完美地運用廣域網(wǎng)絡(luò)技術(shù)發(fā)送信息--在此范圍內(nèi)不能同步使用分配的資源。下面的圖表描述了信息排隊模型。

。。舉例來說,一些公司的呼叫中心系統(tǒng)運用兩種信息發(fā)送產(chǎn)品結(jié)合了所需的后臺辦公方案。它們是IBM公司的MQ系列以及Mitem
有限公司的MitemView 。更具體地說,MitemView 用于緊密地將呼叫中心系統(tǒng)"結(jié)合"后臺辦公方案包括IBM3270,或類似的終端設(shè)備。該方案不要求以任何方式修改現(xiàn)有后臺辦公方案,也不要求在系統(tǒng)上安裝其他軟件。也就是說,MitemView運用提供終端圖像服務(wù)的數(shù)據(jù)流建立要求的應(yīng)用程序界面,這在下圖中有所說明。
。。當(dāng)后臺辦公方案不能提供3270或類似界面時,就要使用IBM公司的MQ系列。作為呼叫中心系統(tǒng)的一部分,通過持續(xù)排隊和保證發(fā)送服務(wù),MQ系列可以不同時不堵塞地發(fā)送信息。這些服務(wù)可以保證正常閱讀排隊中的客戶請求,并在業(yè)務(wù)委托和確認(rèn)之前都能進行--即使排隊運行環(huán)境不穩(wěn)定或在程序中發(fā)生錯誤的情況下也能工作。
。。在決定中間件研究怎樣結(jié)合特別的后臺辦公方案之前,需要進一步分析公司的歷史數(shù)據(jù)和后臺辦公方案。
本文由作者向CTI論壇提供
回到 李博士專欄——呼叫中心構(gòu)建規(guī)劃指南
相關(guān)鏈接:
和政县|
阿克陶县|
房产|
宁德市|
广饶县|
会昌县|
崇礼县|
宣汉县|
珲春市|
资阳市|
武威市|
涪陵区|
卫辉市|
开远市|
修水县|
花莲县|
建阳市|
莱芜市|
黎川县|
武川县|
巴林右旗|
镇原县|
广昌县|
汉寿县|
灯塔市|
尉氏县|
泰和县|
扎兰屯市|
绥中县|
苗栗市|
邯郸县|
金秀|
武强县|
佛冈县|
安新县|
澄江县|
二连浩特市|
叙永县|
锦屏县|
威信县|
中方县|