如何從現(xiàn)有的NGCC縱向分層構(gòu)架,演進(jìn)到基于統(tǒng)一通信的橫向分層的扁平化構(gòu)架?NGCC的演進(jìn)應(yīng)該是平滑的,使呼叫中心既盡量保護(hù)現(xiàn)有投資,又要實(shí)現(xiàn)統(tǒng)一通信的扁平化構(gòu)架模型。結(jié)合公司近期多個(gè)呼叫中心項(xiàng)目實(shí)踐,給出了基于統(tǒng)一通信的扁平化呼叫中心結(jié)構(gòu)的具體實(shí)現(xiàn)方式,如圖1所示:

橫向分層的具體實(shí)現(xiàn)構(gòu)架
消息類業(yè)務(wù)的呼叫中心構(gòu)架如下圖所示。上述構(gòu)架是在對(duì)呼叫中心的功能要求進(jìn)行抽象的基礎(chǔ)上給出的。

消息類業(yè)務(wù)的呼叫中心構(gòu)架
在該構(gòu)架圖中,只需要在原有NGCC呼叫中心的基礎(chǔ)上,增加消息處理模塊(即圖1中的MM Sever和MMC Sever),即可完成對(duì)消息類會(huì)話的接入和轉(zhuǎn)發(fā),同時(shí)還要對(duì)原有的排隊(duì)路由系統(tǒng)、監(jiān)控系統(tǒng)、數(shù)據(jù)配置系統(tǒng)、報(bào)表系統(tǒng)等進(jìn)行升級(jí),以完成對(duì)呼叫和多媒體的統(tǒng)一交互管理,并對(duì)原有傳統(tǒng)的IVR進(jìn)行擴(kuò)展,使其可支持更多的業(yè)務(wù)類型,如郵件、短信、微信、微博等,對(duì)外給出可兼容全業(yè)務(wù)的VXML接口。盡管消息處理和呼叫處理是在不同的模塊進(jìn)行,但消息處理模塊和呼叫處理模塊具有相同的分層結(jié)構(gòu),這種分層結(jié)構(gòu)與圖1中的橫向分層結(jié)構(gòu)一致,從全業(yè)務(wù)智能處理層開(kāi)始對(duì)消息類業(yè)務(wù)和呼叫類業(yè)務(wù)進(jìn)行統(tǒng)一的管理,可包括智能路由排隊(duì)、交互式應(yīng)答、智能機(jī)器人等模塊,最終由全業(yè)務(wù)流程處理平臺(tái)給出統(tǒng)一的對(duì)外接口。上述系統(tǒng)的優(yōu)勢(shì)如下。
①與過(guò)去縱向分層的煙囪式的構(gòu)架相比,基于統(tǒng)一通信技術(shù)的分層架構(gòu)具有良好的擴(kuò)展能力。例如,對(duì)于互聯(lián)網(wǎng)中層出不窮的新型社交媒體和IM即時(shí)消息媒體,如微博類(新浪、騰訊、搜狐、網(wǎng)易)、微信類(微信、易信、來(lái)往)等平臺(tái),統(tǒng)一通信技術(shù)的分層架構(gòu)只需新增網(wǎng)關(guān)模塊即可靈活擴(kuò)展,后臺(tái)無(wú)需修改,而傳統(tǒng)縱向分層的煙囪式構(gòu)架則需要為每一種業(yè)務(wù)搭建從接入網(wǎng)關(guān)、交互管理、消息處理、流程處理及監(jiān)控管理的自下而上的平臺(tái),統(tǒng)一通信技術(shù)的分層架構(gòu)在媒體擴(kuò)展、應(yīng)用擴(kuò)展、人員擴(kuò)展等多個(gè)層面都存在明顯優(yōu)勢(shì)。
②基于統(tǒng)一通信技術(shù)的分層架構(gòu)可將多種媒體進(jìn)行統(tǒng)一的交互和管理,這與過(guò)去縱向分層的煙囪式構(gòu)架中對(duì)每一類業(yè)務(wù)分別接入、路由和管理的方式相比,其管理能力明顯提高。如在語(yǔ)音呼叫排隊(duì)繁忙的情況下,可以優(yōu)先給實(shí)時(shí)語(yǔ)音進(jìn)行排隊(duì),非實(shí)時(shí)的E-mail、短信等則可以安排較低的優(yōu)先級(jí)進(jìn)行處理,可對(duì)語(yǔ)音、視頻、即時(shí)消息進(jìn)行監(jiān)控,同一客服可同時(shí)處理消息類業(yè)務(wù)和語(yǔ)音類業(yè)務(wù),可對(duì)語(yǔ)音、視頻、即時(shí)消息進(jìn)行統(tǒng)一的排隊(duì),建立統(tǒng)一的流程模型、語(yǔ)義模型、消息模型,提供統(tǒng)一的KPI、質(zhì)檢和監(jiān)控、報(bào)表等,這些都是過(guò)去縱向分層的煙囪式構(gòu)架無(wú)法實(shí)現(xiàn)的。
③基于統(tǒng)一通信技術(shù)的分層架構(gòu)可通過(guò)對(duì)傳統(tǒng)呼叫中心的平滑升級(jí),只需要在原有NGCC基礎(chǔ)上增加消息接入平臺(tái)和消息交互管理中間件,即可實(shí)現(xiàn)與語(yǔ)音、視頻呼叫類業(yè)務(wù)一起進(jìn)行統(tǒng)一的路由分配、排隊(duì),支持人工服務(wù)和自動(dòng)服務(wù),保護(hù)了現(xiàn)有投資,節(jié)約了投資成本,降低了系統(tǒng)搭建難度。
在交換層面,由SIP呼叫平臺(tái)負(fù)責(zé)語(yǔ)音呼叫和視頻呼叫的接入,由于消息類業(yè)務(wù)具有統(tǒng)一的特征,所以采用數(shù)據(jù)接入引擎處理郵件、短信、微信、微博等消息類業(yè)務(wù)。在交互管理層面,呼叫類業(yè)務(wù)與消息類業(yè)務(wù)的交互,仍然在不同的模塊進(jìn)行,這是由于呼叫和消息具體不同的交互特征,呼叫需要實(shí)時(shí)交互,而消息類是非實(shí)時(shí)的交互。在智能處理層面,各抽象模型就不再區(qū)別消息類業(yè)務(wù)和語(yǔ)音類業(yè)務(wù),可將語(yǔ)音業(yè)務(wù)與消息業(yè)務(wù)建立統(tǒng)一的流程模型、知識(shí)模型、語(yǔ)義模型。在流程處理平臺(tái)層面,各類業(yè)務(wù)的交互接口可抽象為兩類:一類是傳統(tǒng)的流程式交互,另一類則是機(jī)器人交互接口。