專利名稱：實(shí)時(shí)通信呼叫中心服務(wù)器的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及在呼叫中心和一個(gè)或多個(gè)用戶之間通過實(shí)時(shí)通信呼叫中心服務(wù)器進(jìn)行資源配置的方法和系統(tǒng)，前述實(shí)時(shí)通信呼叫中心服務(wù)器適于通過處理用戶通信內(nèi)容，為用戶通信選擇路由。
背景技術(shù)：
呼叫中心為消費(fèi)者和商家提供了至關(guān)重要的通信鏈路。在當(dāng)前的呼叫中心系統(tǒng)中，消費(fèi)者通過標(biāo)準(zhǔn)公共電話網(wǎng)電話呼叫該呼叫中心的主要免費(fèi)號(hào)碼，然后與交互式語音應(yīng)答(IVR)系統(tǒng)交互，該交互式語音應(yīng)答系統(tǒng)會(huì)推導(dǎo)出主叫意圖。一般地，在等待一段時(shí)間之后，主叫被轉(zhuǎn)接到適當(dāng)?shù)暮艚兄行拇?，由后者隨后與消費(fèi)者通話，解決他或她的請(qǐng)求。在基于雙音多頻(DTMF)的那些實(shí)現(xiàn)中，主叫可能不得不處理一系列不同的DTMF菜單，以最終確定他的意圖。在這種緩慢而又麻煩的處理之后發(fā)現(xiàn)實(shí)際上并沒有DTMF菜單項(xiàng)能夠很好地體現(xiàn)他們的意圖時(shí)，主叫很容易感到沮喪，而這種情況并不少見。在某些情況下，主叫可能會(huì)選擇退出，他按下“0”鍵，與呼叫中心操作人員交談，以便更為快捷和準(zhǔn)確地表明他或她的意圖，這使得呼叫中心操作員不得不花時(shí)間在這些呼叫上，從而導(dǎo)致額外的呼叫中心開支。在其它情況下，主叫可能會(huì)因客戶服務(wù)和支持很差而感到沮喪，掛掉呼叫，不在該公司購買其它產(chǎn)品。
一般地，在等待人工呼叫中心代理接入時(shí)，主叫會(huì)聽到呼叫保持音樂(MOH)。在某些情況下，用音頻資料替代了MOH，或者在MOH之外還會(huì)有音頻資料。例如，到機(jī)票預(yù)訂中心的呼叫可能為主叫提供了事先錄制的音頻通告，給出了到不同目的地的特價(jià)航班，或者周末旅行特價(jià)。此外，如果用戶在IVR提示之后，通過DTMF輸入了他的飛行?？?frequent flyer)代碼，呼叫中心給出的呼叫保持音頻(AOH)信息可能是主叫的飛行?？涂偫锍?。此外，主叫可以接收描述呼叫中心代理是否可用，以及預(yù)期在呼叫隊(duì)列中等待的時(shí)間的音頻信息，典型的音頻通知的一個(gè)例子是“請(qǐng)等待，你的呼叫將在大約5分鐘內(nèi)應(yīng)答?！彪S著電話網(wǎng)絡(luò)從傳統(tǒng)電路交換公共電話網(wǎng)演進(jìn)到分組交換話音和數(shù)據(jù)IP網(wǎng)絡(luò)，基于話音/數(shù)據(jù)綜合的新的通信形式將會(huì)出現(xiàn)。因此，需要下一代呼叫中心支持這些新的通信形式，新的呼叫中心應(yīng)當(dāng)利用這種話音/數(shù)據(jù)的綜合，提供增強(qiáng)的客戶服務(wù)。
最有前景的話音/數(shù)據(jù)綜合協(xié)議之一是會(huì)話初始協(xié)議(SIP)。SIP被優(yōu)化為用于在IP網(wǎng)絡(luò)和用戶之間有效地建立綜合媒體交換會(huì)話的建立、變動(dòng)和拆除的有效處理。SIP協(xié)議的詳細(xì)細(xì)節(jié)在因特網(wǎng)工程任務(wù)組(IETF)請(qǐng)求注釋(RFC)3261中給出。
市場(chǎng)上已經(jīng)出現(xiàn)了不同類型的SIP客戶端。目前，最為廣泛應(yīng)用的SIP客戶端是微軟視窗(TM)實(shí)時(shí)通信(RTC)信使(Messenger)，它嵌入在微軟視窗XP(TM)操作系統(tǒng)中，可以從華盛頓州Redding的微軟公司購買。微軟視窗(TM)RTC信使目前可以下載并安裝到已有的微軟公司老視窗(TM)系統(tǒng)，包括視窗95(TM)，視窗98(TM)，視窗NT(TM)，以及視窗2000(TM)。微軟視窗(TM)RTC信使集成的功能包括發(fā)送即時(shí)消息(IM)、文本交談、查看和改變?cè)趫?chǎng)狀態(tài)、創(chuàng)建好友清單、建立并終止基于IP的話音(VoIP)呼叫、收發(fā)基于IP的視頻、交換文檔以及屏幕共享。這里稱集成有實(shí)時(shí)通信服務(wù)器的SIP通信客戶端為RTC信使。此外，稱在不同人之間的端到端應(yīng)用中使用的SIP通信客戶端為“好友”。

發(fā)明內(nèi)容
本發(fā)明的若干實(shí)施方式包括呼叫中心和用戶，或者后面實(shí)施例中的主叫之間資源配置的方法和系統(tǒng)，每個(gè)用戶的用戶接口能夠處理比如在因特網(wǎng)上包括即時(shí)文本消息和話音傳輸?shù)耐ㄐ??？傮w上，該方法中用戶通過用戶接口發(fā)送第一通信到呼叫中心，其中該呼叫中心包括實(shí)時(shí)通信呼叫中心服務(wù)器，用于處理多個(gè)用戶的即時(shí)文本消息，以及處理多個(gè)用戶的話音傳輸。本發(fā)明的實(shí)時(shí)通信呼叫中心服務(wù)器確定每個(gè)接收的初始用戶通信的用戶目的地地址；向確定的每個(gè)用戶地址發(fā)送詢問通信，如果接收到對(duì)該詢問通信的應(yīng)答用戶通信，該RTC服務(wù)器利用該用戶通信確定需要發(fā)送給該用戶的通信內(nèi)容的數(shù)量和類型，發(fā)送給該用戶確定數(shù)量和類型的通信內(nèi)容。此外，該呼叫中心可以有一個(gè)或多個(gè)呼叫中心代理，也就是通過本發(fā)明的RTC呼叫中心服務(wù)器應(yīng)答用戶的呼叫人員。該RTC呼叫中心服務(wù)器可以分析用戶的通信內(nèi)容，基于諸如用戶與資源中心的初始通信的目的之類的信息，RTC呼叫中心服務(wù)器可以建立路由狀態(tài)。該路由狀態(tài)可以包括話音通信可以轉(zhuǎn)接到的最佳呼叫中心代理。
基于SIP的通信客戶端目前廣為被采用，尤其是基于視窗(TM)的操作系統(tǒng)。這些基于PC的客戶端支持集成的通信能力，如在場(chǎng)信息、即時(shí)消息、文本交談、基于IP的話音、基于IP的視頻、文件傳送以及屏幕共享。盡管這些客戶端一般用于通過因特網(wǎng)的人們之間的端到端形式的通信，或者在公司LAN上公司員工之間的通信，本發(fā)明的若干實(shí)施方式中允許使用這些客戶端與呼叫中心通信。
在本發(fā)明的若干實(shí)施方式中，通過實(shí)時(shí)通信呼叫中心服務(wù)器(RTC-CCS)來提供新呼叫中心服務(wù)的輸送。RTC-CCS所提供的一種這樣的服務(wù)是交互式會(huì)話應(yīng)答(ISR)。ISR利用了主叫具有集成話音和即時(shí)消息(IM)能力的事實(shí)，基于在即時(shí)消息中用文本指示的主叫的意圖，精確地為話音呼叫尋找路由。另一個(gè)示例性的服務(wù)是IM幫助(IMH)，其中主叫開始時(shí)話音呼叫呼叫中心，在可能升級(jí)到與人工呼叫中心代理交談之前，從RTC-CCS接收一個(gè)或多個(gè)即時(shí)消息，這些消息包括文本、網(wǎng)頁鏈接或文檔。RTC-CCS所提供的其它服務(wù)包括多信道交互(MCI)、會(huì)話保持(SOH)以及呼叫中心好友(CCB)。CCB允許消費(fèi)者在他的好友清單中加入呼叫中心，以及隨后利用RTC信使的內(nèi)置在場(chǎng)能力傳輸呼叫中心狀態(tài)，和/或推斷出的該消費(fèi)者會(huì)感興趣的其它信息。
RTC-CCS為主叫提供了重要服務(wù)，而不需要對(duì)呼叫中心作額外改動(dòng)。但是，如果呼叫中心代理也用RTC信使來代替?zhèn)鹘y(tǒng)的PBX電話，或者在傳統(tǒng)的PBX電話之外還有RTC信使，那么RTC-CCS提供額外服務(wù)，包括文檔交換、基于IP的視頻、屏幕共享、主叫和呼叫中心代理之間的即時(shí)消息。另一實(shí)施方式具有輔助開發(fā)集成的呼叫中心代理應(yīng)用的RTC-CCS桌面工具箱。
ISR具有若干優(yōu)點(diǎn)，一個(gè)是它通過簡單的無格式文本輸入，允許主叫直接明確他呼叫的意圖，而不是通過復(fù)雜的一系列DTMF菜單。利用ISR，主叫可以容易地、快速并準(zhǔn)確地表明他的意圖，從而消除了成本高昂的操作人員介入。此外，增加了總體客戶滿意度-客戶能夠更好地明確他的意圖，從而在為呼叫選擇路由時(shí)，精確度得以提高。利用ISR，客戶能夠與最能夠滿足他需要的呼叫中心代理通話。


通過舉例說明本發(fā)明，但本發(fā)明并不受限于這些附圖，在附圖中圖1給出了本發(fā)明的示例性總體網(wǎng)絡(luò)拓?fù)?；圖2給出了本發(fā)明的一個(gè)實(shí)施方式的示例性信號(hào)事件；圖3A給出了本發(fā)明的交互式會(huì)話應(yīng)答實(shí)施方式的示例性信號(hào)事件；圖3B給出了本發(fā)明的另一交互式會(huì)話應(yīng)答實(shí)施方式的示例性信號(hào)事件；圖3C給出了本發(fā)明的另一交互式會(huì)話應(yīng)答實(shí)施方式的示例性信號(hào)事件；
圖4A給出了本發(fā)明的IM幫助實(shí)施方式的示例性信號(hào)事件；圖4B給出了本發(fā)明的另一IM幫助實(shí)施方式的示例性信號(hào)事件；圖5給出了本發(fā)明的多信道交互實(shí)施方式的示例性信號(hào)事件；圖6給出了本發(fā)明的另一多信道交互實(shí)施方式的示例性信號(hào)事件；圖7A給出了本發(fā)明的會(huì)話保持實(shí)施方式的示例性信號(hào)事件；圖7B給出了本發(fā)明的另一會(huì)話保持實(shí)施方式的示例性信號(hào)事件；圖8A給出了進(jìn)行與本發(fā)明呼叫中心之間的VoIP通話的示例性圖形用戶接口窗口；圖8B給出了用于開始與本發(fā)明的呼叫中心的VoIP通話的示例性圖形用戶接口窗口；圖8C給出了用于本發(fā)明的呼叫中心好友和在場(chǎng)信息的示例性圖形用戶接口窗口；圖8D給出了用于本發(fā)明的呼叫中心好友和在場(chǎng)信息的示例性圖形用戶接口窗口；圖9給出了本發(fā)明的一種實(shí)施方式的示例性信號(hào)事件，前述實(shí)施方式中主叫和代理具有集成的客戶端；圖10進(jìn)一步給出了本發(fā)明的一種實(shí)施方式的示例性信號(hào)事件，前述實(shí)施方式中主叫和代理具有集成的客戶端；以及圖11給出了本發(fā)明的一種實(shí)施方式的示例性信號(hào)事件，前述實(shí)施方式中主叫和代理具有集成的客戶端，代理具有的CRM處理。
具體實(shí)施例方式
現(xiàn)代呼叫中心一般支持與消費(fèi)者進(jìn)行電郵交換，還可以允許呼叫中心代理和消費(fèi)者同時(shí)瀏覽萬維網(wǎng)。增強(qiáng)的呼叫中心還可以采用計(jì)算機(jī)電話集成(CTI)技術(shù)連接到它的專用交換分機(jī)(PBX)系統(tǒng)，從而智能地，或者至少更為精確地為每個(gè)來話尋找路由，將其接續(xù)到當(dāng)時(shí)認(rèn)為最佳的呼叫中心代理，并且自動(dòng)向該代理提供主叫信息。該主叫信息從呼叫中心的數(shù)據(jù)庫中檢索得到，可以在應(yīng)答代理的圖形用戶接口中以彈出窗口的形式顯示。呼叫中心代理利用與話音呼叫相結(jié)合的客戶關(guān)系管理(CRM)軟件，有效接入并關(guān)聯(lián)客戶特定的數(shù)據(jù)庫信息的能力，是提供好的客戶服務(wù)的一個(gè)完整方面。
當(dāng)消費(fèi)者使用基于SIP的通信客戶端，例如RTC信使，以及集成多個(gè)通信信道的其它類似的軟件客戶端，與呼叫中心交互，在與呼叫中心的交互過程中，除了它們的傳統(tǒng)電話之外，主叫還能夠利用集成的通信信道，例如文本、網(wǎng)頁、話音和視頻。在本發(fā)明的若干實(shí)施方式中，稱為實(shí)時(shí)通信呼叫中心服務(wù)器(RTS-CCS)的實(shí)體允許資源中心，例如呼叫中心，將重要的新業(yè)務(wù)提供給使用基于SIP的通信客戶端，例如RTC信使和其它類似軟件客戶端的消費(fèi)者。RTC-CCS利用基于SIP的通信客戶端的流行性、普遍性和內(nèi)置特征來提供這些新服務(wù)。本發(fā)明描述了基于使用RTC-CCS的呼叫中心體系結(jié)構(gòu)，以及它所支持的新呼叫中心服務(wù)。這些服務(wù)包括交互式會(huì)話應(yīng)答(ISR)、IM幫助(IMH)、多信道交互(MCI)、會(huì)話保持(SOH)以及呼叫中心好友(CCB)。此外，因?yàn)楹艚兄行拇磉€可以使用包含基于SIP的通信客戶端，例如RTC信使的PC，下面公開支持RTC的呼叫中心代理的附加拓?fù)浜吞卣鳌?shí)時(shí)通信呼叫中心服務(wù)器可以是按照客戶機(jī)/服務(wù)器模型的一個(gè)或多個(gè)具有一個(gè)或多個(gè)服務(wù)器應(yīng)用的服務(wù)器或計(jì)算機(jī)。RTC-CCS的通信指令可以包含在一個(gè)或多個(gè)包括基于腳本或可執(zhí)行的應(yīng)用的通信模塊中。同樣，RTC-CCS的路由指令可以包含在一個(gè)或多個(gè)包括基于腳本或可執(zhí)行的應(yīng)用程序的路由模塊中。
如圖1所示，RTC-CCS包括一個(gè)基于CPU的服務(wù)器120，它位于呼叫中心局域網(wǎng)(LAN)150的邊界上，其中邊界最好具有至少一個(gè)路由器，以及最好一個(gè)防火墻151，防火墻151最好包括連接到因特網(wǎng)140的分組過濾路由器，連接到呼叫中心LAN 150的分組過濾路由器，以及插入在兩個(gè)路由器之間的應(yīng)用網(wǎng)關(guān)。該呼叫中心LAN路由器/防火墻151對(duì)公開本發(fā)明的若干實(shí)施方式而言是透明的，本領(lǐng)域的一般技術(shù)人員會(huì)認(rèn)識(shí)到不需要對(duì)它進(jìn)一步闡述。具有基于SIP的通信客戶端，例如RTC信使和運(yùn)行于他們個(gè)人計(jì)算機(jī)(PC)110上的其它類似軟件客戶端的用戶，例如那些使用最新視窗(TM)操作系統(tǒng)的用戶，適于通過他們的主叫RTC IM接口110聯(lián)系使用RTC-CCS的呼叫中心。在與用戶交互時(shí)，呼叫中心代理接口130可以采用各種不同類型的裝置。這些裝置包括PBX電話、執(zhí)行CRM軟件的PC、CTI應(yīng)用程序、瀏覽器以及基于SIP的通信客戶端，例如RTC信使和其它類似軟件客戶端。
在一種實(shí)施方式中，RTC-CCS充當(dāng)中間設(shè)備服務(wù)器，在傳統(tǒng)呼叫中心和使用RTC信使，或類似軟件客戶端的主叫之間提供一層，使得呼叫中心能夠重用已有的PBX基礎(chǔ)設(shè)施處理來自RTC信使或類似軟件客戶端的呼叫。在這種實(shí)施方式中，RTC-CCS提供了必要的翻譯和轉(zhuǎn)換功能，為主叫的基于VoIP(也就是基于SIP)的通信客戶端與已有的，以前只處理來自公共電話交換網(wǎng)(PSTN)的話音呼叫的呼叫中心提供接口。
圖2描述了RTC-CCS作為中間設(shè)備如何運(yùn)作，其中以例子形式說明了具有傳統(tǒng)基礎(chǔ)設(shè)施(例如PBX222、PBX電話132、CTI客戶端以及呼叫中心LAN 150)的呼叫中心和具有基于SIP的通信客戶端，例如RTC信使的因特網(wǎng)用戶之間的中間設(shè)備功能。主叫利用基于SIP的通信客戶端作為接口110，用SIP INVITE消息(步驟201)經(jīng)因特網(wǎng)140，經(jīng)由RTC-CCS 120，向呼叫中心發(fā)出VoIP呼叫請(qǐng)求，RTC-CCS通過SIP OK信號(hào)(步驟202)通知它接受了該請(qǐng)求。RTC-CCS撥打一個(gè)電話呼叫到呼叫中心人工代理接口，本例中利用PBX CTI(步驟204)，從而導(dǎo)致PBX 222振鈴呼叫中心代理130的PBX話機(jī)132(步驟205)。在該例中，采用CTI的RTC-CCS在呼叫中心代理的個(gè)人計(jì)算機(jī)134顯示器上激活一個(gè)彈出窗口(步驟206)。RTC-CCS通過因特網(wǎng)或其它網(wǎng)絡(luò)部分發(fā)送VoIP媒體到主叫，并從主叫接收VoIP媒體(步驟207)。RTC-CCS將話音媒體從IP轉(zhuǎn)換到PBX數(shù)字格式，通過電話干線231向PBX發(fā)送，或從PBX接收話音媒體(步驟208)。該P(yáng)BX通過數(shù)字線路240向呼叫中心代理的PBX電話132發(fā)送數(shù)字話音媒體和從呼叫中心接收數(shù)字話音媒體(步驟209)。該示例實(shí)施方式中中間設(shè)備的使用使得主叫能夠使用新的客戶端類型，例如RTC信使來訪問呼叫中心的已有基礎(chǔ)設(shè)施。在該示例實(shí)施方式中，RTC-CCS適于能夠提供可視指示，例如彈出窗口。對(duì)客戶數(shù)據(jù)庫(未示出)的訪問和索引可以利用SIPINVITE消息頭中“From”來完成，而不是傳統(tǒng)方法中PSTN所提供的主叫標(biāo)識(shí)號(hào)碼。
在優(yōu)選實(shí)施方式中，RTC-CCS包括可選的CTI接口，從而能夠與一種或多種類型的支持CTI的PBX互連。在一種異構(gòu)的具有多個(gè)不同廠商的PBX的呼叫中心中，單個(gè)RTC-CCS服務(wù)器可以相應(yīng)處理來自PSTN電話的呼叫和來自基于SIP的通信客戶端的消息，將它們適當(dāng)?shù)貙ぢ返饺我籔BX上的代理。
利用RTC-CCS充當(dāng)中間設(shè)備層，呼叫中心繼續(xù)向主叫提供與呼叫中心目前向在PSTN所支持連接中使用傳統(tǒng)的話機(jī)或者RTC信使的主叫提供的服務(wù)集相同的服務(wù)集。但是，RTC-CCS的一個(gè)優(yōu)勢(shì)在于，它在處理簡單話音呼叫之外，還提供了有用并且新的服務(wù)。RTC-CCS所提供的新服務(wù)綜合利用了主叫RTC信使客戶端或類似客戶端的內(nèi)置集成通信特征。
交互式會(huì)話應(yīng)答圖3A給出了這里稱為交互式會(huì)話應(yīng)答(ISR)的服務(wù)，在若干實(shí)施方式中，它源自RTC-CCS，并且是RTC-CCS的一部分。通過ISR，RTC-CCS利用了主叫的集成話音和即時(shí)消息(IM)能力。ISR根據(jù)主叫在聯(lián)系呼叫中心時(shí)對(duì)其意圖的文本描述，也就是即時(shí)消息(IM)體的文本內(nèi)容，準(zhǔn)確地為呼叫尋路。ISR擴(kuò)展了間接尋求確定主叫意圖的交互式語音應(yīng)答(IVR)及其相關(guān)聯(lián)的DTMF交互的傳統(tǒng)方法。利用ISR，主叫直接地在與話音呼叫相關(guān)聯(lián)的IM的內(nèi)容中確定他的意圖。
在圖3A所描述的ISR的優(yōu)選實(shí)施方式中，主叫在(步驟301)中向具有RTC-CCS的呼叫中心發(fā)起話音呼叫。RTC-CCS檢查該初始話音呼叫，尤其是SIP INVITE(步驟302)頭中的“From”和“Contact”字段，以確定發(fā)送IM的地址。RTC-CCS隨后立即在(步驟303)中向主叫發(fā)送回請(qǐng)求主叫描述他的呼叫的意圖和目的的詢問通信IM，應(yīng)答該呼叫。在優(yōu)選實(shí)施方式中，主叫用自由格式IM應(yīng)答響應(yīng)RTC-CCS IM詢問(步驟304)。RTC-CCS隨后通過基于計(jì)算機(jī)的文本分析，理解和分析該IM響應(yīng)，以最準(zhǔn)確地推斷出主叫請(qǐng)求，進(jìn)而確定通信路由狀態(tài)?；趯?duì)主叫文本響應(yīng)的分析，RTC-CCS隨后將呼叫尋路到最理想的代理(步驟305)。例如，ISR可以隨后采用基于技能的路由和策略匹配方法，或者其它最合適技術(shù)來適當(dāng)?shù)貫楹艚袑ふ衣酚伞Ｒ坏┍粚ぢ?，該呼叫以話音通話形式繼續(xù)(步驟305)。在某些實(shí)施方式中，去和/或從呼叫中心代理的話音媒體經(jīng)由已有的PBX話機(jī)，這種情況下，RTC-CCS最好進(jìn)行VoIP轉(zhuǎn)換，采用CTI與PBX交互。在另一種實(shí)施方式中，媒體保持VoIP格式，可以由RTC-CCS發(fā)送給呼叫中心代理的RTC信使或者類似客戶端。
在可選的實(shí)施方式中，除了對(duì)主叫IM響應(yīng)的計(jì)算機(jī)文本分析之外，RTC-CCS也采用其它基于策略的路由來適當(dāng)?shù)剡M(jìn)行呼叫路由選擇。例如，如果主叫發(fā)送回IM，例如“我的洗衣機(jī)，型號(hào)為350有問題。它漏水，我想與設(shè)備公司總裁說說這個(gè)事”，RTC-CCS會(huì)利用內(nèi)容分析，以及已有的策略匹配，將呼叫轉(zhuǎn)接到負(fù)責(zé)該設(shè)備公司型號(hào)350洗衣機(jī)的客戶支持分部。盡管RTC-CCS推斷出主叫的意圖是與設(shè)備公司總裁講講設(shè)備指定類型和型號(hào)的產(chǎn)品支持和維修，但更高級(jí)的策略禁止將該請(qǐng)求直接轉(zhuǎn)接給總裁，而是適當(dāng)?shù)貙⒑艚修D(zhuǎn)接到客戶支持部門。
作為選擇，RTC-CCS可以將ISR和其它高級(jí)的呼叫路由處理結(jié)合，例如基于技能的路由，來適當(dāng)為呼叫尋找路由。參照前一例子，可能目前沒有可用的洗衣機(jī)型號(hào)350的代理，但具有洗衣機(jī)型號(hào)220和型號(hào)460技能的代理卻可以提供服務(wù)。路由處理例如組合從ISR抽取的信息，然后確定具有型號(hào)220技能或型號(hào)460技能的代理是否最適合處理該次特定呼叫。
在優(yōu)選實(shí)施例中，使用VoIP在主叫RTC信使或類似軟件客戶端，以及RTC-CCS之間交換話音媒體。RTC-CCS隨后撥打呼叫中心代理的話機(jī)，將媒體從VoIP轉(zhuǎn)換到PBX所使用的數(shù)字或模擬話音協(xié)議。在另一實(shí)施方式中，呼叫中心代理也可以具有VoIP客戶端，例如RTC信使，所以在該實(shí)施方式中，不再需要媒體轉(zhuǎn)換。下面描述呼叫中心操作的其它方面，其中該呼叫中心代理還使用VoIP SIP客戶端，例如RTC信使。
在一些實(shí)施方式中，ISR采用本領(lǐng)域眾所周知的計(jì)算機(jī)文本分析技術(shù)來確定話音主叫的內(nèi)容。盡管在包含電郵分析以實(shí)現(xiàn)自動(dòng)響應(yīng)并將電郵轉(zhuǎn)發(fā)給代理的應(yīng)用中，這種文本分析技術(shù)在本領(lǐng)域中眾所周知，但本發(fā)明的若干實(shí)施方式提供了計(jì)算機(jī)文本分析和話音呼叫的智能路由之間的關(guān)聯(lián)。
在ISR的優(yōu)選實(shí)施方式中，作為對(duì)RTC-CCS詢問的響應(yīng)，主叫在即時(shí)消息中明確其意圖。此外，還有主叫通過非IM方法傳送文本意圖的其它實(shí)施方式。例如，在圖3B中給出，RTC-CCS請(qǐng)求用戶完成文本文檔，其中明確呼叫的意圖。ISR分析完成的文檔的內(nèi)容，將每個(gè)呼叫轉(zhuǎn)接到最合適的代理。
作為選擇，該文檔可以最初由RTC-CCS轉(zhuǎn)發(fā)給主叫，或者作為選擇，該文檔可以駐留在用戶的接口設(shè)備中。該文檔可選地可以包括其它信息，例如賬號(hào)代碼、客戶信息、注冊(cè)號(hào)、保修期以及類似信息。待完成的文檔最好能夠利用RTC信使或類似軟件代理的內(nèi)置文件交換能力推送給主叫，或者利用其它方式提供給主叫，例如頁面下載或者事先存儲(chǔ)在主叫的接口設(shè)備，例如個(gè)人電腦中。典型的例子是文檔交換，前述文檔不僅有主叫意圖的文本信息，而且包含附加客戶注冊(cè)信息，例如客戶地址，何時(shí)何地購買該項(xiàng)產(chǎn)品，以及客戶可能購買其它產(chǎn)品的興趣。文檔中的信息隨后可以用于為呼叫尋找路由，或者更新呼叫中心數(shù)據(jù)庫，以便客戶追蹤、銷售渠道分析以及類似處理。在圖3B給出的ISR實(shí)施方式中，RTC-CCS IM包含文本提示和需要由主叫完成的文檔(步驟303B)，隨后主叫通過IM完成并返回由RTC-CCS轉(zhuǎn)發(fā)給它的文本文檔(步驟304B)。之后，在確定了通信路由狀態(tài)之后，RTC-CCS分析提交的文檔，使用事先描述的路由邏輯，將呼叫轉(zhuǎn)接到最合適的代理(步驟305B)。
在圖3C給出的另一示例性實(shí)施方式中，作為詢問通信，從RTC-CCS的響應(yīng)包括即時(shí)消息中的網(wǎng)頁鏈接(步驟303C)。主叫點(diǎn)擊鏈接，打開基于網(wǎng)頁的表。主叫隨后填充并提交該基于網(wǎng)頁的表(步驟304C)，RTC-CCS隨后利用該表確定通信路由狀態(tài)，以準(zhǔn)確地為呼叫選擇路由(步驟305C)。這樣，通過分析完成后的網(wǎng)頁表的內(nèi)容，呼叫被轉(zhuǎn)接到最適當(dāng)?shù)拇怼Ｗ鳛檫x擇，網(wǎng)頁表也可以在主叫接口設(shè)備上存儲(chǔ)cookies，后者可以恢復(fù)為呼叫路由處理的一部分。
經(jīng)由IM幫助的主叫輔助在圖3A-3C給出的實(shí)施方式中，RTC-CCS通過向主叫發(fā)送單個(gè)詢問來響應(yīng)主叫，允許在將呼叫轉(zhuǎn)接到人工呼叫中心代理之前，使得主叫能夠通過IM、文檔或網(wǎng)頁表來明確他的意圖。但是，當(dāng)RTC-CCS確定了主叫的意圖時(shí)，在某些情況下，可能不需要將呼叫轉(zhuǎn)接到實(shí)際的人工代理。在這些實(shí)施方式中，RTC-CCS能夠發(fā)送一個(gè)或多個(gè)即時(shí)消息，轉(zhuǎn)發(fā)一個(gè)或多個(gè)文檔，或者提出一個(gè)或多個(gè)網(wǎng)頁鏈接，來提供所需的幫助。該RTC-CCS發(fā)明的這個(gè)可選方面這里稱之為IM幫助(IMH)。
為了盡量減小人工呼叫中心資源的消耗，同時(shí)維持客戶滿意度，RTC-CCS首先尋求通過自動(dòng)方式來解決主叫的需要，而不需要涉及人工呼叫中心代理。RTC-CCS提供IMH服務(wù)的處理的一個(gè)例子在圖4A中給出。主叫通過例如從他的RTC信使發(fā)出INVITE，聯(lián)系呼叫中心(步驟301)。RTC-CCS最好利用主叫SIP INVITE中的“Contact”來確定IM的目的地(步驟302)。RTC-CCS以詢問通信回應(yīng)主叫，通過IM提示或者請(qǐng)求主叫明確呼叫目的(步驟303)。在該例中，這通過IM完成，也可以通過下面描述的話音來完成。主叫以明確他的呼叫目的的IM回應(yīng)(步驟304)。但是，在該實(shí)施例中，RTC-CCS120在推導(dǎo)通信路由狀態(tài)后，確定不需要將話音呼叫轉(zhuǎn)接到人工呼叫中心代理(步驟405)。在不滿足轉(zhuǎn)接到人工呼叫中心的條件時(shí)，RTC-CCS 120發(fā)送一個(gè)或多個(gè)附加IM，附上并轉(zhuǎn)發(fā)文檔，頁面或HTML鏈接，或者RTC-CCS認(rèn)為相關(guān)的其它基于文本的響應(yīng)，自動(dòng)為主叫提供幫助(步驟406)。在該步驟406中，為了滿足主叫，可以提供任一或者所有這些IM。在某些情況下，RTC-CCS在沒有直接涉及人工呼叫中心代理的單個(gè)自動(dòng)事務(wù)處理中提供了所需的信息，滿意的主叫終止了呼叫，如BYE傳輸所示(步驟407)。在圖4B所示的其它情況下，可能需要在主叫和RTC-CCS之間進(jìn)行附加交換；從用戶發(fā)來消息(步驟407B)和發(fā)給用戶消息的交換(步驟408)。在該例中，RTC-CCS 120自動(dòng)介入與主叫之間的文本交談(步驟408)，按照這種格式，RTC-CCS 120提出并交換一個(gè)或多個(gè)文檔和網(wǎng)頁鏈接，以滿足主叫的意圖，而不需要直接涉及人工呼叫中心代理。例如初始IM可能不會(huì)完全滿足主叫的意圖，在話音呼叫或者被升級(jí)轉(zhuǎn)接給最適當(dāng)?shù)暮艚兄行拇?，或者被終止之前進(jìn)行后續(xù)包含了附加的文本消息、HTML鏈接，和/或所附文檔的IM交換。在某些情況下，這種多次交換是足夠的，使?jié)M意的主叫終止了話音呼叫。另一些情況下，作為確定通信路由狀態(tài)步驟的一部分，最好利用記分系統(tǒng)和預(yù)定條件，RTC-CCS 120推斷出實(shí)際需要人工呼叫中心代理(步驟409)，根據(jù)該推斷，RTC-CCS將呼叫適當(dāng)?shù)剞D(zhuǎn)接到最適合的人工代理(步驟410)。
在可能將話音呼叫升級(jí)之前，在同一會(huì)話中利用即時(shí)消息、文檔交換和/或網(wǎng)頁瀏覽的基于IM的自助服務(wù)，提供了一種框架，在該框架內(nèi)由RTC-CCS 120提供IM幫助或IMH服務(wù)。這種服務(wù)利用了主叫RTC信使的集成的即時(shí)消息、文檔交換和頁面訪問能力。IMH保存了呼叫中心人工代理資源，同時(shí)仍能滿足主叫的需要。如果RTC-CCS 120推斷出在IMH會(huì)話中一個(gè)或多個(gè)自動(dòng)交換之后，主叫的需要仍然未滿足，RTC-CCS會(huì)將話音呼叫轉(zhuǎn)發(fā)給最適合的人工呼叫中心代理。呼叫路由處理最好基于消息304中的主叫意圖的初始指定，或者基于交換的整個(gè)歷史。相應(yīng)地，RTC-CCS 120最好在可能將話音呼叫升級(jí)之前，在同一會(huì)話中利用即時(shí)消息、文檔交換和/或網(wǎng)頁瀏覽，進(jìn)行基于IM的自助服務(wù)，以更好地分配示例性呼叫中心的資源，同時(shí)按照識(shí)別的意圖為主叫提供有用的內(nèi)容。
多信道交互在前面公開的實(shí)施方式中，RTC-CCS 120通過將呼叫轉(zhuǎn)接到人工代理，以及RTC-CCS 120和主叫之間包含即時(shí)消息、文檔和網(wǎng)頁鏈接的非話音交換的交互，提供了呼叫中心的話音服務(wù)。在另外的實(shí)施方式中，RTC-CCS 120本身在會(huì)話中在音頻傳輸中發(fā)言或者介入，并聽主叫說話。在另外的實(shí)施方式中，RTC-CCS在前面描述的所有ISR和IHM服務(wù)中集成了語音，使得主叫利用話音和/或文本信道，與RTC-CCS 120交互，前述話音和/或文本信道最好已經(jīng)內(nèi)置在他的RTC信使客戶端中。
在一個(gè)基本的例子中，接收到話音呼叫之后，RTC-CCS 120口頭感謝用戶撥打，隨后發(fā)送給主叫一個(gè)即時(shí)消息，請(qǐng)求有關(guān)呼叫目的的更多的信息，然后口頭要求主叫明確呼叫的目的，在主叫的IM響應(yīng)之后，口頭感謝該主叫。RTC-CCS 120對(duì)多個(gè)文本、文檔交換和話音信道的使用這里稱之為多信道交互(MCI)。
圖5給出了RTC-CCS 120的MCI服務(wù)如何工作的一個(gè)例子。最初，主叫通過從他的RTC信使發(fā)出INVITE，聯(lián)系呼叫中心(步驟301)。RTC-CCS 120利用主叫SIP INVITE中的“Contact”來確定IM的目的地(步驟302)。RTC-CCS隨后以即時(shí)消息的形式發(fā)送詢問通信給主叫，請(qǐng)求有關(guān)呼叫目的的更多信息(步驟503)。同時(shí)，作為選擇，RTC-CCS也可以跟主叫交談，禮貌地要求主叫(步驟503)提供必要的信息，使得能夠?qū)艚羞M(jìn)行評(píng)定，從而可以轉(zhuǎn)發(fā)給最可能提供服務(wù)的代理。用戶最好發(fā)送即時(shí)消息，和/或與RTC-CCS交談，或者同時(shí)利用這兩種方式(步驟504)來回應(yīng)。該用戶隨后在RTC-CCS確定通信路由狀態(tài)步驟期間(步驟506)，可能在(步驟505)接收呼叫保持音樂，前述RTC-CCS確定通信路由狀態(tài)步驟最好包括分析主叫IM和/或話音，確定文本、HTML鏈接或所附文檔的最佳內(nèi)容，同時(shí)由RTC-CCS 120在(步驟507)中交換一個(gè)或多個(gè)后續(xù)即時(shí)消息、文檔或網(wǎng)頁鏈接。RTC-CCS 120可以口頭詢問主叫(步驟508)，確定該材料是否令人滿意，也可以傾聽主叫的口頭響應(yīng)(步驟509)。通過這種方式，利用多個(gè)媒體信道的組合，改善用戶的感受，使得主叫和呼叫中心之間的交互更令人滿意，而不需要涉及人工呼叫中心代理。
前面提過，主叫和RTC-CCS 120之間的初始聯(lián)系可以是話音呼叫，最好使用VoIP。但是，在本發(fā)明的另一方面，初始聯(lián)系可以經(jīng)由IM。在這種實(shí)施方式中，RTC-CCS提供了例如ISR、IMH和MCI服務(wù)的組合。
例如，圖6給出的場(chǎng)景中，消費(fèi)者最初通過IM聯(lián)系呼叫中心(步驟601)。RTC-CCS 120利用即時(shí)消息頭中的“From”和“Contact”字段(步驟602)，進(jìn)行詢問通信，并且RTC-CCS 120由此確定如何發(fā)送后續(xù)的SIP INVITE消息(步驟603)。如果消費(fèi)者接受了SIPINVITE，并且在RTC-CCS 120推導(dǎo)通信路由狀態(tài)的步驟中，確定不需要人工呼叫中心代理立即介入(步驟604)，RTC-CCS 120可以提供附加信息(步驟605)，隨后作為RTC-CCS 120話音和IM交互處理的一部分(步驟606)，與主叫交談，通過話音或文本，或者這兩種方式請(qǐng)求有關(guān)主叫意圖的附加信息(步驟607)，并例如傾聽主叫(步驟608)。這樣，對(duì)本發(fā)明的這種實(shí)施方式而言，RTC-CCS 120可以通過對(duì)主叫的或者SIP INVITE或者即時(shí)消息予以響應(yīng)，從而發(fā)起呼叫中心的會(huì)話。
會(huì)話保持
RTC-CCS 120綜合了向主叫發(fā)送呼叫保持音樂(MOH)或呼叫保持音頻(AOH)信息。RTC-CCS不再只輸送音樂或音頻，而是能夠利用客戶具有集成的客戶端，例如RTC信使，其能夠支持多種信息信道的輸送，輸送即時(shí)消息、文檔、即時(shí)消息中的網(wǎng)頁鏈接、視頻和音頻。這種特定的RTC-CCS服務(wù)這里稱為會(huì)話保持(SOH)。
圖7A給出了RTC-CCS 120輸送SOH功能的方式。SOH綜合了傳統(tǒng)的MOH和呼叫排隊(duì)。在主叫等待某個(gè)代理提供服務(wù)時(shí)，RTC-CCS 120可以發(fā)送包括諸如文本、HTML鏈接、文檔、音頻片斷、視頻片斷和音頻視頻片斷等內(nèi)容的附加IM。該信息可以包括廣告、特價(jià)商品、個(gè)人賬號(hào)狀態(tài)、相關(guān)產(chǎn)品信息、預(yù)期等待時(shí)間信息以及類似信息。在該實(shí)施例中，當(dāng)主叫聯(lián)系呼叫中心(步驟301)時(shí)，RTC-CCS 120確定主叫接收IM的目的地(步驟302)，然后作為詢問通信發(fā)送具有文本提示和需要由用戶完成的文檔的IM(步驟703)。主叫隨后輸入描述呼叫目的的信息(步驟704)，在完成并提交這些輸入之后，作為確定通信路由狀態(tài)的步驟的一部分，RTC-CCS 120開始執(zhí)行路由決定，并最好基于主叫IM的內(nèi)容和主叫完成的文檔進(jìn)行尋路(步驟707)，路由決定還可以包括已有的呼叫代理路由邏輯。但是，在該例中，不是立即將主叫連接到人工代理，而是由RTC-CCS 120分析主叫IM，利用呼叫中心策略來輸送適當(dāng)?shù)臅?huì)話內(nèi)容，也就是，需要通信的內(nèi)容信息的數(shù)量和類型，在主叫等待代理提供服務(wù)(步驟705)時(shí)，向主叫輸送多媒體信息(步驟706)，這種多媒體信息可以包括包含文本、HTML、所附文檔的IM，以及作為可選的多媒體內(nèi)容的視頻和音頻片斷。例如，在機(jī)票預(yù)定場(chǎng)景中，RTC-CCS 120輸送一個(gè)短視頻片斷，該視頻片斷描述周末旅行特價(jià)，在IM中提供一個(gè)購買該特價(jià)機(jī)票的網(wǎng)頁鏈接，和/或在即時(shí)消息中發(fā)送主叫的當(dāng)前飛行?？偷挠囝~。RTC-CCS利用主叫RTC信使或類似客戶端中所有的可用通信信道，向用戶提供信息。最后，呼叫被轉(zhuǎn)接到最合適的代理(步驟707)，之后，基于話音的通話開始(步驟708)。
在場(chǎng)消息本發(fā)明的若干實(shí)施方式中，提供了圖形顯示的組合，與打到呼叫中心的話音呼叫一起協(xié)力運(yùn)作，向主叫提供呼叫中心狀態(tài)、隊(duì)列中預(yù)期等待時(shí)間的更新信息。RTC信使，以及類似的軟件代理，支持利用非音頻方式顯示可用數(shù)據(jù)，這里稱之為在場(chǎng)狀態(tài)。在場(chǎng)信息利用SIP NOTIFY消息發(fā)送給RTC信使，SIP NOTIFY消息體中包含有在場(chǎng)數(shù)據(jù)。利用RTC信使的內(nèi)置在場(chǎng)能力，顯示一個(gè)或多個(gè)好友的可用性。每個(gè)好友的在線、出去午飯、或者其它狀態(tài)都可以通過RTC信使GUI顯示。
在本發(fā)明的一個(gè)實(shí)施方式中，RTC-CCS 120利用在場(chǎng)消息發(fā)送呼叫中心可用信息給RTC信使。圖7B顯示了事件的優(yōu)選順序。主叫聯(lián)系RTC-CCS 120(步驟301)，RTC-CCS確定IM的目的地(步驟302)，以詢問呼叫的形式發(fā)送IM，后者最好提示需要完成所附文檔以明確呼叫的目的(步驟703)，或者在IM文本中請(qǐng)求給出主叫意圖或該次呼叫的目的。主叫發(fā)送IM，描述了呼叫的目的(步驟704)，該IM可能包括完成的前面由RTC-CCS 120發(fā)送的文檔。根據(jù)對(duì)主叫意圖的分析(步驟705)，RTC-CCS 120發(fā)送(步驟706)IMH文檔、文本交談和與主叫交談，參與SOH交換。最后，主叫一般開始等待可以提供服務(wù)的呼叫中心代理。作為確定通信路由狀態(tài)步驟的一部分，RTC-CCS 120使用主叫SIP INVITE消息頭中的“Contact”字段來確定在場(chǎng)NOTIFY消息的目的地(步驟707B)。RTC-CCS 120隨后發(fā)送在場(chǎng)信息給主叫的客戶端，描述預(yù)期等待時(shí)間(步驟708B)。之后，確定通信路由狀態(tài)(步驟709)，其中作為確定通信路由狀態(tài)步驟的一部分，路由可以基于IM的內(nèi)容，文檔內(nèi)容和路由邏輯。因?yàn)闋顟B(tài)信息，例如等待下一代理的時(shí)間也可以通過SIP/SIMPLE基于在場(chǎng)的通知消息發(fā)送，主叫的RTC信使不再指示簡單的存在狀態(tài)，例如在線、不可用以及類似信息，而是顯示預(yù)期等待時(shí)間，例如如圖8C所示，下面予以描述。
在圖7B所示的本發(fā)明的示例性實(shí)施方式中，RTC-CCS 120利用在場(chǎng)消息，通知主叫呼叫中心的可用性信息以及RTC-CCS 120認(rèn)為主叫在呼叫中心隊(duì)列中的預(yù)期等待時(shí)間，其中通過圖形RTC信使顯示通知主叫。主叫RTC信使的內(nèi)置顯示能力使得它能夠通過圖形裝置，而不是音頻裝置，或者在音頻裝置之外還有圖形裝置，來使用戶及時(shí)得到通知和更新。例如在只有圖形更新模式下，主叫能夠著手做他的工作，而不需要聽音頻中斷，偶爾察看圖形顯示就可以知道他在呼叫中心隊(duì)列中的當(dāng)前等待狀態(tài)。RTC-CCS 120定期發(fā)送有關(guān)主叫情況的狀態(tài)更新，隱含地告知他在隊(duì)列中的前移。在一種示例性實(shí)施方式中，RTC-CCS 120每分鐘發(fā)送附加的SIP NOTIFY在場(chǎng)消息，更新主叫的顯示，其中每個(gè)SIP NOTIFY在場(chǎng)消息包括更新后的等待時(shí)間。
主叫可以以多種方法使用RTC信使來與具有RTC-CCS 120的呼叫中心進(jìn)行初始聯(lián)系。圖8A-C中給出了與具有RTC-CCS 120的呼叫中心進(jìn)行初始聯(lián)系的兩種示例性方法。圖8A和8B給出了主叫用以聯(lián)系具有RTC-CCS 120的呼叫中心的手工過程。在該示例性方法中，主叫使用他的RTC信使手工輸入呼叫中心的完全有效域名。例如，如果主叫希望用RTC信使對(duì)“A Generic Computer Store”發(fā)出話音呼叫，他如下開始話音通話，即開始時(shí)從即時(shí)消息窗口中選擇行動(dòng)下拉菜單，在開始話音信箱窗口打開的情況下，主叫輸入“agenericcomputerstore.com”，如圖8B所示。在該第一方法中，用戶也可以如上所述，向呼叫中心的RTC-CCS 120發(fā)送初始即時(shí)消息，聯(lián)系呼叫中心。在該例中，主叫使用開始話音通話，或者例如發(fā)送即時(shí)消息菜單選項(xiàng)，隨后輸入呼叫中心的完全有效域名。在該示例性方法中，呼叫中心沒有進(jìn)入主叫的好友清單。
聯(lián)系呼叫中心的第二方法這里稱為呼叫中心好友(CCB)，并在圖8C中給出。利用該方法，主叫最初將呼叫中心加入他的好友列表。該實(shí)施例中CCB項(xiàng)對(duì)應(yīng)于完全呼叫中心。在該例中，RTC-CCS 120接受主叫的好友請(qǐng)求，并呈現(xiàn)在場(chǎng)狀態(tài)。用戶隨后發(fā)起話音呼叫，或者發(fā)送即時(shí)消息給他的CCB，其方式與他針對(duì)人類好友的操作基本相同。加入到主叫好友列表中的呼叫中心有助于更為直接的訪問。一個(gè)或多個(gè)呼叫中心，例如該例中那些商業(yè)計(jì)算機(jī)零售商或者夜間運(yùn)送服務(wù)的呼叫中心，現(xiàn)在占用了主叫桌面的一部分，可以經(jīng)由IM，例如單擊鼠標(biāo)進(jìn)行呼叫或聯(lián)系。此外，某些實(shí)施方式中的在場(chǎng)信道用于指示呼叫中心的可用性。
如上所述，作為選擇，RTC-CCS可以發(fā)送其它在場(chǎng)狀態(tài)信息給登記的客戶端。例如，有關(guān)呼叫中心狀態(tài)的信息被推送到用戶，不管是否有初始、或者激發(fā)的用戶呼叫到達(dá)該呼叫中心。圖8C給出了RTC信使好友清單例子，更新的在場(chǎng)信息從具有RTC-CCS的兩個(gè)呼叫中心發(fā)出。My-OvernightShipper-Buddy點(diǎn)的在場(chǎng)信息表明了盡管呼叫中心仍然運(yùn)營，人工代理目前需要兩分鐘等待時(shí)間。類似地，agenericcomputerstore.com計(jì)算機(jī)支持的在場(chǎng)信息，Geri-Comp-Sup-Buddy，表明呼叫中心運(yùn)營并且目前有可提供服務(wù)的呼叫中心代理。盡管目前沒有涉及任何呼叫，消費(fèi)者從OvernightShipper和A Generic Computer Store接收更新的在場(chǎng)信息。這個(gè)例子說明了主叫發(fā)起話音呼叫，或者發(fā)送即時(shí)消息給他的示例性呼叫中心好友“Overnight Shipper”和“A Generic Computer Store”，以及如上所述的接收IHM或SOH信息的圖形接口。
經(jīng)由在場(chǎng)消息的呼叫中心信息在任一特定時(shí)刻RTC-CCS選擇發(fā)送給任一特定消費(fèi)者哪種類型的在場(chǎng)信息需要在RTC-CCS中配置。例如，如果主叫向RTC-CCS發(fā)起了話音呼叫，作為選擇，從RTC-CCS來的在場(chǎng)消息可以用于顯示預(yù)期的等待時(shí)間，即使消費(fèi)者沒有發(fā)起呼叫，作為選擇，RTC-CCS也可以通過在場(chǎng)通信信道發(fā)送銷售信息、訂單狀態(tài)以及其他重要的呼叫中心數(shù)據(jù)。
圖8D給出了在Overnight Shipping(通宵運(yùn)送)的RTC-CCS和在A Generic Computer Store(通用計(jì)算機(jī)商店)的另一RTC-CCS如何利用在場(chǎng)消息，使得消費(fèi)者即時(shí)了解包裹運(yùn)送狀態(tài)，以及客戶化PC訂單的狀態(tài)。RTC-CCS利用在場(chǎng)通知消息發(fā)送其它重要狀態(tài)信息。在這些例子中，消費(fèi)者沒有向Overnight Shipping或A GenericComputer Store發(fā)起話音呼叫，而是簡單地將Overnight Shipping和A Generic Computer Store加入他的好友清單。RTC-CCS將相關(guān)信息推送給用戶，而不需要向呼叫中心發(fā)起話音或即時(shí)消息呼叫。通過這種機(jī)制，呼叫中心在客戶發(fā)起呼叫之前，提供重要的有用客戶服務(wù)信息。
將CCB加入好友清單的一個(gè)好處是，即使沒有發(fā)起呼叫，消費(fèi)者也能夠從呼叫中心的RTC-CCS接收個(gè)性化信息。該信息可以充當(dāng)對(duì)消費(fèi)者的提示，提示消費(fèi)者之后要與呼叫中心進(jìn)行即時(shí)消息或話音通信。
例如，消費(fèi)者訂購了筆記本，已經(jīng)將“A Generic Computer Store”作為CCB加入。該消費(fèi)者查看該信息，如圖8D所示，想知道他筆記本PC的運(yùn)送細(xì)節(jié)，以及是否仍可能購買更多的內(nèi)存。該用戶利用RTC信使，通過他的CCB與A Generic Computer Store建立聯(lián)系。在該特定例子中，用戶傾向于用即時(shí)消息與A Generic Computer Store開始初始聯(lián)系。該用戶與A Generic Computer Store的RTC-CCS之間相應(yīng)的對(duì)話可以記錄在對(duì)話框里。該用戶首先通過即時(shí)消息與AGeneric Computer Store的RTC-CCS交互。客戶，現(xiàn)在是主叫，可能會(huì)就他的未決筆記本訂單問若干IM問題，然后才會(huì)升級(jí)到人工呼叫中心代理，由后者收集主叫追加購買所需的相關(guān)信息。但是，RTC-CCS并不是立即直接將該呼叫轉(zhuǎn)接到人工代理，而是開始時(shí)尋求通過IMH來提供有關(guān)運(yùn)送方法、筆記本內(nèi)存需求的必要信息。當(dāng)RTC-CCS確定現(xiàn)在需要用戶與呼叫中心代理通話時(shí)，向用戶的RTC信使發(fā)送話音INVITE，呼叫隨后準(zhǔn)確地被轉(zhuǎn)接到精通筆記本處理內(nèi)存銷售的代理。利用主叫的IMH會(huì)話，經(jīng)由轉(zhuǎn)接到最佳呼叫中心代理的話音呼叫，RTC-CCS有助于在筆記本訂單狀態(tài)之間的平滑升級(jí)，在用戶桌面上以在場(chǎng)狀態(tài)形式示出。
具備SIP客戶端的代理接口前面章節(jié)描述了RTC-CCS 120提供給具有集成客戶端的主叫的重要服務(wù)。但是，當(dāng)呼叫中心代理也具有集成客戶端930時(shí)，在這些實(shí)施方式中，RTC-CCS提供了額外的特征和好處。圖9給出了RTC-CCS呼叫中心體系結(jié)構(gòu)，其中主叫和代理都有集成客戶端，其步驟類似于前面描述的步驟，其中主叫進(jìn)入與代理的通話。但是，在該實(shí)施方式中，話音現(xiàn)在作為VoIP，被發(fā)送給呼叫中心代理的集成客戶端(步驟906)，而不是代理的PBX電話機(jī)。圖9還說明了一個(gè)或多個(gè)呼叫中心代理也可以使用集成客戶端來增加客戶服務(wù)等級(jí)和滿意度。例如，呼叫中心代理通過IM來提供客戶相關(guān)的HTML鏈接、交換文檔(步驟907)，并通過屏幕共享來提供遠(yuǎn)程支持(步驟908)。作為選擇，呼叫中心代理也可以發(fā)送視頻(步驟909)來提高個(gè)性化程度。在優(yōu)選實(shí)施方式中，RTC-CCS 120用作這些交換的代理服務(wù)器。
圖10進(jìn)一步描述了RTC-CCS 120為VoIP SIP呼叫尋路的方式的細(xì)節(jié)。主叫向RTC-CCS 120發(fā)送INVITE(步驟1001A)，從RTC-CCS 120接收一個(gè)SIP OK(步驟1001B)，主叫隨后以SIP ACK形式返回確認(rèn)(步驟1001C)。作為詢問通信的一部分，RTC-CCS 120發(fā)送一個(gè)IM(步驟303)，請(qǐng)求給出主叫的意圖，最好接收的IM(步驟304)包含有足夠的信息，從中可以識(shí)別出主叫的意圖。在確定通信路由狀態(tài)時(shí)(步驟1005)，RTC-CCS 120確定適當(dāng)?shù)暮艚兄行拇恚缓蟀l(fā)出SIPINVITE(步驟1006A)，最好會(huì)話描述協(xié)議(SDP)明確主叫IP地址作為媒體源。呼叫中心代理利用“OK”應(yīng)答該呼叫(步驟1006B)，以其IP地址C作為媒體源，接收確認(rèn)(步驟1006C)。RTC-CCS 120向主叫重發(fā)SIPINVITE(步驟1007A)，通知主叫其媒體應(yīng)當(dāng)發(fā)送給呼叫中心代理IP地址C，隨著OK(步驟1007B)和確認(rèn)(步驟1007C)，通話開始，話音媒體從主叫首先到RTC-CCS120(步驟1008a)，然后到呼叫中心代理(步驟1008B)，以及從呼叫中心代理到主叫(步驟1009)。作為選擇，RTC-CCS 120也可以進(jìn)行進(jìn)入媒體映射，從而阻塞進(jìn)入呼叫中心的未授權(quán)的用戶數(shù)據(jù)報(bào)(UDP)流。出于安全考慮，RTC-CCS還提供基于防火墻的進(jìn)入媒體映射。會(huì)話也維持在RTC-CCS服務(wù)器上，從而可以得到呼叫中心的統(tǒng)計(jì)數(shù)據(jù)。RTC-CCS計(jì)算典型的呼叫中心統(tǒng)計(jì)數(shù)據(jù)，例如呼叫數(shù)量、平均呼叫時(shí)長、平均等待時(shí)間以及類似數(shù)據(jù)。RTC-CCS還計(jì)算衡量它所提供的新服務(wù)性能的統(tǒng)計(jì)數(shù)據(jù)。例如，計(jì)算的統(tǒng)計(jì)數(shù)據(jù)包括平均IMH交換數(shù)量、從IMH轉(zhuǎn)變?yōu)樵捯舻暮艚袛?shù)量、即時(shí)消息的平均長度、請(qǐng)求CCB的主叫數(shù)量。RTC-CCS在某些實(shí)施例中還提供記錄服務(wù)，記錄整個(gè)聯(lián)系過程，包括ISR和SOH交換，以及話音和視頻。一些實(shí)施方式的RTC-CCS還提供下一代呼叫中心監(jiān)視，由此其人工呼叫中心監(jiān)視人員能夠監(jiān)控主叫和代理的交互，例如文本交談或文檔交換。
RTC-CCS有助于主叫和呼叫中心代理之間利用標(biāo)準(zhǔn)的RTC信使能力進(jìn)行并行通信會(huì)話。例如，呼叫中心代理可以直接傳送給主叫一個(gè)文檔，例如幫助手冊(cè)、產(chǎn)品手冊(cè)或其它文件。主叫和代理也可以在話音通話的同時(shí)并行進(jìn)行文本交談。例如，作為選擇，代理可以請(qǐng)求“請(qǐng)點(diǎn)擊這個(gè)超文本鏈接以得到更多信息”，當(dāng)發(fā)送包含該鏈接的IM給主叫時(shí)。呼叫中心代理可以可選地支持視頻，以及RTC信使所支持的其它通信信道。這些信道包括屏幕共享、遠(yuǎn)程幫助、頁面共同瀏覽、白板以及類似信道。雖然這些服務(wù)目前使用在因特網(wǎng)或企業(yè)LAN上的好友之間的端到端會(huì)話，但按照本發(fā)明的技術(shù)或步驟，這些業(yè)務(wù)可以應(yīng)用于主叫和呼叫中心代理之間。
圖11說明了本發(fā)明的優(yōu)選實(shí)施方式，RTC-CCS 120向用戶或主叫RTC IM接口110發(fā)送詢問通信(步驟303)，根據(jù)接收到的信息，確定通信路由狀態(tài)(步驟305)，最好使用CRM處理輔助呼叫中心代理1130與主叫的交互。CRM包也可以采用CTI，從而呼叫中心代理在應(yīng)答呼叫時(shí)，可以從數(shù)據(jù)庫中檢索出客戶信息，前述數(shù)據(jù)庫以PSTN提供的主叫標(biāo)識(shí)為索引，客戶信息本可以從以主叫的SIPINVITE頭中的“From”字段為索引的數(shù)據(jù)庫中檢索得到。也就是說，在優(yōu)選實(shí)施方式中，呼叫中心代理使用集成RTC信使和CRM的單個(gè)軟件應(yīng)用，而不是兩個(gè)單獨(dú)的非集成應(yīng)用。為了簡化這種集成應(yīng)用，稱為RTC呼叫中心代理(RTC-CCA)的軟件開發(fā)，圖11中給出了RTC-CCS桌面工具的使用，該工具揭示了消息代理和RTC-CCS的功能。
本說明書中使用的描述本發(fā)明及其各種實(shí)施方式的文字不僅需要在普通意義上理解，而且應(yīng)當(dāng)理解為在普通意義之外，包含本說明書中結(jié)構(gòu)、材料或行為的特定定義。因此，如果某個(gè)元素在本說明書上下文中理解為包含多于一種含義，那么在權(quán)利要求中它的出現(xiàn)必須理解為是一般性的，適于本說明書和文字本身所支持的各種可能的含義。
在不偏離這里公開的本發(fā)明及其若干實(shí)施例的精神和范圍的前提下，本領(lǐng)域一般技術(shù)人員可以做出許多變化和改進(jìn)。因此，必須理解，這里給出的實(shí)施方式只是為了舉例說明，不應(yīng)當(dāng)理解為限制本發(fā)明，本發(fā)明由后續(xù)權(quán)利要求書定義。
權(quán)利要求
1.一種在呼叫中心和用戶之間資源配置的方法，該用戶的用戶接口適于處理在網(wǎng)絡(luò)部分上包括文本消息和話音傳輸?shù)耐ㄐ?，該方法包括由該呼叫中心接收由該用戶接口發(fā)出的第一通信，其中該呼叫中心包括實(shí)時(shí)通信呼叫中心服務(wù)器，適于處理多個(gè)用戶的即時(shí)文本消息，以及處理多個(gè)用戶的話音傳輸；以及由該實(shí)時(shí)通信呼叫中心服務(wù)器從該第一通信確定用戶目的地地址；由該實(shí)時(shí)通信呼叫中心服務(wù)器向確定的用戶地址發(fā)送詢問通信；由該實(shí)時(shí)通信呼叫中心服務(wù)器接收對(duì)該詢問通信的用戶應(yīng)答；以及基于對(duì)該詢問通信的應(yīng)答，確定該用戶的通信路由狀態(tài)。
2.根據(jù)權(quán)利要求1的方法，其中該呼叫中心還包括一個(gè)或多個(gè)呼叫中心代理。
3.根據(jù)權(quán)利要求2的方法，其中該確定通信路由狀態(tài)的步驟還包括查詢第一通信的內(nèi)容以及對(duì)該詢問通信的應(yīng)答；以及根據(jù)該應(yīng)答，確定最適合的該第一通信的內(nèi)容，以及對(duì)一個(gè)或多個(gè)呼叫中心代理的詢問通信的應(yīng)答。
4.根據(jù)權(quán)利要求2的方法，還包括步驟按照該路由狀態(tài)，將該用戶轉(zhuǎn)接到具有呼叫中心代理接口的一個(gè)或多個(gè)呼叫中心代理中的呼叫中心代理。
5.根據(jù)權(quán)利要求1的方法，還包括以下步驟由該實(shí)時(shí)通信呼叫中心服務(wù)器確定需要發(fā)送給該用戶的至少一個(gè)通信中包含的內(nèi)容的數(shù)量和類型；以及發(fā)送給該用戶至少一個(gè)包含確定數(shù)量和類型的內(nèi)容的通信。
6.一種在呼叫中心和至少一個(gè)用戶之間的資源配置系統(tǒng)，每個(gè)用戶的用戶接口適于處理在網(wǎng)絡(luò)部分上包括即時(shí)文本消息和話音傳輸?shù)耐ㄐ?，該呼叫中心還包括適于處理包括多個(gè)用戶的即時(shí)文本消息，以及多個(gè)用戶的話音傳輸?shù)挠脩敉ㄐ诺膶?shí)時(shí)通信呼叫中心服務(wù)器；其中該實(shí)時(shí)通信呼叫中心服務(wù)器適于自動(dòng)地確定每個(gè)接收的初始用戶通信的用戶目的地地址；向每個(gè)確定的用戶地址發(fā)送詢問通信；以及如果從至少一個(gè)用戶接收到對(duì)該詢問通信的應(yīng)答通信，基于該應(yīng)答確定需要發(fā)送給該用戶的通信的內(nèi)容的數(shù)量和類型，以及發(fā)送給該用戶具有確定的數(shù)量和類型的通信內(nèi)容。
7.根據(jù)權(quán)利要求6的系統(tǒng)，其中該通信中心還包括一個(gè)或多個(gè)呼叫中心代理。
8.根據(jù)權(quán)利要求7的系統(tǒng)，其中該通信中心確定資源代理路由狀態(tài)。
9.根據(jù)權(quán)利要求8的系統(tǒng)，其中該通信中心按照該路由狀態(tài)，將該用戶轉(zhuǎn)接到呼叫中心代理。
10.一種適于將呼叫中心的資源配置給至少一個(gè)具有地址的用戶的服務(wù)器，該服務(wù)器包括通信模塊，適于自動(dòng)地向用戶地址發(fā)送至少一個(gè)詢問通信；以及向該用戶發(fā)送至少一個(gè)根據(jù)對(duì)該詢問通信的一個(gè)或多個(gè)用戶應(yīng)答確定的通信；以及路由模塊，適于根據(jù)對(duì)至少一個(gè)詢問通信的一個(gè)或多個(gè)用戶應(yīng)答，自動(dòng)地將該用戶轉(zhuǎn)接到資源中心的資源。
全文摘要
具有處理用戶即時(shí)文本消息和話音傳輸?shù)膶?shí)時(shí)通信(RTC)服務(wù)器的呼叫中心之間進(jìn)行資源配置的方法和系統(tǒng)。該RTC服務(wù)器根據(jù)一個(gè)或多個(gè)即時(shí)文本消息交換的分析，確定該話音呼叫的適當(dāng)路由目的地。在某些情況下，RTC服務(wù)器可以提供文檔、包含HTML鏈接的即時(shí)消息和多媒體音頻和視頻，以期滿足主叫而不需要將該話音呼叫轉(zhuǎn)接到人工代理。RTC服務(wù)器還提供了會(huì)話保持、IM幫助、多信道交互和呼叫中心好友能力。
文檔編號(hào)H04L12/54GK1697419SQ20041006158
公開日2005年11月16日 申請(qǐng)日期2004年12月27日 優(yōu)先權(quán)日2003年12月26日
發(fā)明者邁克爾·S·溫羅維茨 申請(qǐng)人:阿爾卡特公司