第五章 技術(shù)的設(shè)計(jì)(二)
李寶民 2005/03/17
5.2 企業(yè)顧客關(guān)系管理解決方案
5.3 服務(wù)請(qǐng)求
。。多渠道的客戶(hù)關(guān)系管理措施將要求用于傳送公司需要的功能。基本上,通過(guò)"雙重渠道"將較容易進(jìn)行目標(biāo)系統(tǒng)服務(wù),也可用于電話(huà)和互聯(lián)網(wǎng)客戶(hù)。
但是,有一部分服務(wù)是向來(lái)不適合電話(huà)渠道的。如今大多數(shù)服務(wù)可以通過(guò)郵件或人工進(jìn)行,因?yàn)榭蛻?hù)要求獲得比電話(huà)中更多的信息。除傳統(tǒng)的公司渠道外,這些服務(wù)將利用互聯(lián)網(wǎng)渠道進(jìn)行,。
部門(mén) | 服務(wù)內(nèi)容 |
渠道
|
需要的支持辦公 | |
所有 | 公司范圍直接 | 呼叫中心 | 互聯(lián)網(wǎng) | |
服務(wù) | 服務(wù)查詢(xún) | √ | √ | √ |
清單 | 查核清單水平 | √ | √ | √ |
投訴 | 對(duì)服務(wù)和/或產(chǎn)品的投訴 | √ | √ | √ |
市場(chǎng) | 市場(chǎng)運(yùn)作事務(wù)要求 | √ | √ | √ |
銷(xiāo)售 | 推銷(xiāo)產(chǎn)品和/或服務(wù) | √ | √ | √ |
維護(hù) | 報(bào)告事故和故障 | √ | √ | √ |
。。下面的圖表說(shuō)明了目標(biāo)系統(tǒng)如何使委托客戶(hù)服務(wù)請(qǐng)求和申請(qǐng)的。另外,目標(biāo)系統(tǒng)從各部門(mén)調(diào)配公司員工履行/解答服務(wù)請(qǐng)求,傳達(dá)請(qǐng)求的解決辦法。
Figure: System Request System Concept
。。為了提供請(qǐng)求的服務(wù),目標(biāo)系統(tǒng)要以企業(yè)CRM方案為基礎(chǔ),該方案是為委托客戶(hù)和客戶(hù)服務(wù)專(zhuān)業(yè)人員制定的,可以幫助他們輕松地提交、獲取、處理和跟蹤服務(wù)情況,并且快速準(zhǔn)確地解決問(wèn)題。
具體說(shuō)明,運(yùn)行呼叫中心系統(tǒng)的CRM方案必須:
更詳細(xì)地說(shuō),運(yùn)行目標(biāo)系統(tǒng)的企業(yè)CRM方案應(yīng)含有下列內(nèi)容:
5.5 后臺(tái)辦公集成中間件
。。呼叫中心系統(tǒng)將與許多公司遺留數(shù)據(jù)和新型后臺(tái)辦公方案相結(jié)合。該系統(tǒng)的客戶(hù)接待和處理部分也將結(jié)合企業(yè)支付系統(tǒng),支持提供可支付服務(wù)。結(jié)合后臺(tái)辦公系統(tǒng)的工作將利用中間件技術(shù)進(jìn)行。
。。中間件在運(yùn)行系統(tǒng)和網(wǎng)絡(luò)服務(wù)間形成了分布式應(yīng)用程序組件的連通性。這些服務(wù)一般利用應(yīng)用程序接口(API)使用,并通過(guò)某組服務(wù)執(zhí)行,這組服務(wù)能夠使應(yīng)用程序組件:
。。大多數(shù)商用中間件系統(tǒng)建立在遠(yuǎn)程呼叫或信息發(fā)送和信息排隊(duì)技術(shù)的基礎(chǔ)上。服務(wù)方面,兩者本質(zhì)上提供同種功能:它們都促進(jìn)了分布式應(yīng)用程序組件的進(jìn)程間通信。
。。不過(guò)在技術(shù)上二者有很大區(qū)別。例如,遠(yuǎn)程過(guò)程調(diào)用(RPC)中間件以過(guò)程調(diào)用類(lèi)似概念為基礎(chǔ),本質(zhì)上會(huì)發(fā)生同步化和堵塞。
因此,RPC基礎(chǔ)的中間件要求:
。。顯然,這種程序模式已不適用了。舉例來(lái)說(shuō),即使不是服務(wù)請(qǐng)求時(shí)間,公司也可能要收集、儲(chǔ)存、給后臺(tái)辦公系統(tǒng)傳達(dá)服務(wù)請(qǐng)求信息。如果技術(shù)同步化,使用RPC是不能進(jìn)行這些工作的。同樣地,服務(wù)請(qǐng)求系統(tǒng)也可能需要同時(shí)查詢(xún)各個(gè)后臺(tái)辦公系統(tǒng)。使用RPC系統(tǒng)也不可能進(jìn)行工作,因?yàn)榧夹g(shù)堵塞,需要客戶(hù)等候遞交請(qǐng)求的回復(fù),然后再遞交別的請(qǐng)求。下面的圖表說(shuō)明了這一過(guò)程。
。。RPC技術(shù)的一個(gè)替換方案是信息發(fā)送中間件。信息發(fā)送和信息排隊(duì)技術(shù)利用信息傳送和排隊(duì)技術(shù)支持應(yīng)用程序進(jìn)程間通信。信息傳送模式可使客戶(hù)通過(guò)發(fā)送信息給服務(wù)器呼叫API并發(fā)送服務(wù)請(qǐng)求。許多運(yùn)行過(guò)程中,信息發(fā)送模式通過(guò)排隊(duì)和保證發(fā)送措施得到提高,可以非常靈活并不同步地儲(chǔ)存,進(jìn)行聯(lián)絡(luò)。這種不同步模式加上綜合傳送橋梁服務(wù)系統(tǒng),可以完美地運(yùn)用廣域網(wǎng)絡(luò)技術(shù)發(fā)送信息--在此范圍內(nèi)不能同步使用分配的資源。下面的圖表描述了信息排隊(duì)模型。
。。舉例來(lái)說(shuō),一些公司的呼叫中心系統(tǒng)運(yùn)用兩種信息發(fā)送產(chǎn)品結(jié)合了所需的后臺(tái)辦公方案。它們是IBM公司的MQ系列以及Mitem 有限公司的MitemView 。更具體地說(shuō),MitemView 用于緊密地將呼叫中心系統(tǒng)"結(jié)合"后臺(tái)辦公方案包括IBM3270,或類(lèi)似的終端設(shè)備。該方案不要求以任何方式修改現(xiàn)有后臺(tái)辦公方案,也不要求在系統(tǒng)上安裝其他軟件。也就是說(shuō),MitemView運(yùn)用提供終端圖像服務(wù)的數(shù)據(jù)流建立要求的應(yīng)用程序界面,這在下圖中有所說(shuō)明。
。。當(dāng)后臺(tái)辦公方案不能提供3270或類(lèi)似界面時(shí),就要使用IBM公司的MQ系列。作為呼叫中心系統(tǒng)的一部分,通過(guò)持續(xù)排隊(duì)和保證發(fā)送服務(wù),MQ系列可以不同時(shí)不堵塞地發(fā)送信息。這些服務(wù)可以保證正常閱讀排隊(duì)中的客戶(hù)請(qǐng)求,并在業(yè)務(wù)委托和確認(rèn)之前都能進(jìn)行--即使排隊(duì)運(yùn)行環(huán)境不穩(wěn)定或在程序中發(fā)生錯(cuò)誤的情況下也能工作。
。。在決定中間件研究怎樣結(jié)合特別的后臺(tái)辦公方案之前,需要進(jìn)一步分析公司的歷史數(shù)據(jù)和后臺(tái)辦公方案。
本文由作者向CTI論壇提供
回到 李博士專(zhuān)欄——呼叫中心構(gòu)建規(guī)劃指南
呼叫(接觸)中心在CRM領(lǐng)域中所扮演的角色 2005-03-15 |
聰明軟件能判斷電話(huà)語(yǔ)氣 2005-03-09 |
呼叫中心外呼服務(wù)管理之腳本設(shè)計(jì)規(guī)則 2005-03-09 |
以用戶(hù)為圓心以服務(wù)為半徑 2005-03-04 |
客服中心的策略、方向和目標(biāo) 2005-03-02 |