IVR為Interactive Voice Response的縮寫(xiě)，意為交互式語(yǔ)音應答（系統）。它可以應答客戶(hù)的呼叫，然后為呼叫者提供語(yǔ)音導航或自助服務(wù)，呼叫者可通過(guò)按鍵輸入或使用語(yǔ)音命令進(jìn)行選擇。隨后，IVR可通過(guò)呼叫路由將呼叫轉移到座席或自助服務(wù)應用程序。在金融領(lǐng)域，IVR應用系統也被銀行稱(chēng)之為電話(huà)銀行系統。

　　千行百業(yè)都離不開(kāi)客服系統，IVR作為客服系統中話(huà)務(wù)接入的門(mén)戶(hù)，是構成客戶(hù)體驗感的服務(wù)排頭兵。在金融領(lǐng)域，電話(huà)銀行系統是銀行與客戶(hù)建立和保持溝通的重要渠道，自下而上支撐著(zhù)遠程銀行的構建和正常運轉。

　　一個(gè)完整的IVR應用系統由IVR平臺（下文簡(jiǎn)稱(chēng)平臺）和IVR業(yè)務(wù)系統（下文簡(jiǎn)稱(chēng)業(yè)務(wù)系統或業(yè)務(wù)）組成。

　　市面上現有的、主流與非主流廠(chǎng)商基于軟交換技術(shù)推出的IVR平臺可謂琳瑯滿(mǎn)目。這些平臺有共同的特點(diǎn)--和自身的開(kāi)發(fā)工具強綁定，因此開(kāi)發(fā)過(guò)程及成果都只能應用在自身的閉環(huán)系統上。雖然VXML號稱(chēng)是IVR的通用國際建議（此處注意：國際建議和標準不同），但是各家廠(chǎng)商大都也是遵循"有利則用，不利則棄"這一不成文的規則，形成了多如牛毛的VXML開(kāi)發(fā)過(guò)程，沒(méi)有辦法做到業(yè)務(wù)和平臺特性的完全解耦。

　　這就造成一個(gè)讓人頭疼的問(wèn)題：開(kāi)發(fā)人員必須要掌握每種IVR的開(kāi)發(fā)細節才行。由于開(kāi)發(fā)人員對各家平臺的理解程度有高有低，這些平臺所使用的開(kāi)發(fā)工具又多多少少地埋著(zhù)各種不盡如人意的"坑"，最終導致開(kāi)發(fā)出來(lái)的成品穩定性、魯棒性各不相同，造成上線(xiàn)質(zhì)量參差不齊且客戶(hù)的業(yè)務(wù)受制于IVR平臺。

　　綜上所述，開(kāi)發(fā)一個(gè)可適用于所有平臺、并且基于目前最常用開(kāi)發(fā)語(yǔ)言的、具備"兼濟天下"能力的IVR框架，具有非常重要的實(shí)際意義。

　　框架設計圍繞這樣的思想展開(kāi)：平臺只干平臺的事，業(yè)務(wù)邏輯交給WebAPP來(lái)做，平臺和WebAPP的交互通過(guò)目前流行的REST接口或HTTP接口。IVR平臺實(shí)現基本功能：

　　■　1. 來(lái)電時(shí)接起電話(huà)，作為被叫和主叫建立通話(huà)鏈路，也可以作為主叫呼出電話(huà)和被叫鏈接通話(huà)鏈路；

　　■　2. 播放語(yǔ)音，可以是TTS和預錄好的語(yǔ)音文件；

　　■　3. 搜集客戶(hù)的按鍵或客戶(hù)的語(yǔ)音（如果有集成ASR）；

　　■　4. 偵測通話(huà)鏈路的狀態(tài)（比如客戶(hù)掛機等等）；

　　■　5. 掛斷電話(huà)（可以主動(dòng)掛斷電話(huà)）；

　　■　6. 鏈接CTI（非基本功能，可以在服務(wù)端實(shí)現）；

　　■　7. 轉接會(huì )議電話(huà)；

　　■　8. 鏈接外部系統接口。

　　把這些基本的功能串接在一起成為一個(gè)完整的IVR應用系統（電話(huà)銀行系統），由應用服務(wù)來(lái)實(shí)現。

　　前文已經(jīng)提到，一個(gè)完整的IVR應用系統分為IVR平臺和IVR業(yè)務(wù)系統兩部分。

　　IVR平臺根據具體產(chǎn)商不同而不同，其主要功能是接收客戶(hù)來(lái)電，并在接收客戶(hù)來(lái)電后搜集客戶(hù)信息。執行具體的放音、按鍵搜集、語(yǔ)音識別、傳真（現在很少使用）、菜單選擇、轉接、掛斷話(huà)務(wù)層面的事情。如果平臺支持IVVR則執行IVVR相關(guān)的功能，如播放視頻。如果有類(lèi)似UUI類(lèi)的隨路數據，則也由平臺執行。其開(kāi)發(fā)過(guò)程使用產(chǎn)商的開(kāi)發(fā)工具，只做基本功能的開(kāi)發(fā)及與平臺的通訊開(kāi)發(fā)。

　　IVR業(yè)務(wù)系統完成所有菜單匹配、流程處理、超時(shí)處理、錯誤判斷、隨路數據等等具體的業(yè)務(wù)過(guò)程，使用純Java的開(kāi)發(fā)。

　　其中業(yè)務(wù)系統作為服務(wù)端，IVR平臺作為客戶(hù)端，平臺和業(yè)務(wù)系統之間采用Restful的通訊協(xié)議。

　　具體過(guò)程如下：

　　■　1. 客戶(hù)來(lái)電時(shí)，IVR平臺搜集來(lái)電的基本信息，并向業(yè)務(wù)系統發(fā)起來(lái)電請求；

　　■　2. 業(yè)務(wù)系統根據配置菜單來(lái)獲取下一步操作，并把下一步要執行的動(dòng)作返回給IVR平臺，同時(shí)保留當前的業(yè)務(wù)流程上下文；

　　■　3. IVR平臺收到返回后執行響應的動(dòng)作，并把操作的結果通過(guò)請求接口方式返回給業(yè)務(wù)系統；

　　■　4. 業(yè)務(wù)系統收到請求后，根據請求結果結合當前的上下文判定后續動(dòng)作，再次返回給平臺；

　　■　5. 重復步驟3和4。

詳細交互過(guò)程

IVR平臺總體邏輯架構

　　基礎通訊組件完成和業(yè)務(wù)系統的通訊，如果平臺有現成的支持API則可以不用開(kāi)發(fā)，如果沒(méi)有就要根據產(chǎn)品平臺提供的集成API來(lái)開(kāi)發(fā)。

　　其過(guò)程如下圖所示：

　　此處多了兩個(gè)服務(wù)：一是利用平臺本身開(kāi)發(fā)工具提供組件調用DLL（或JAVA 通訊API）的便利性來(lái)調用C語(yǔ)言的DLL；二是利用JAVA解釋JSON報文的有利工具來(lái)封裝和解釋報文。

　　框架由兩個(gè)部分組成：菜單和業(yè)務(wù)流程。

　　菜單采用XML結構來(lái)描述，一者XML文檔的結構很適合用于描述菜單，二者XML的遍歷開(kāi)發(fā)比較成熟，對開(kāi)發(fā)人員要求不算太高。

　　菜單的結構如下：

　　所有的業(yè)務(wù)流程采用純J2EE的服務(wù)方式開(kāi)發(fā)，框架實(shí)現基本的功能，定制開(kāi)發(fā)只實(shí)現具體的業(yè)務(wù)流程。主要包含：實(shí)現各類(lèi)輸入的屬性、業(yè)務(wù)過(guò)程串接、后臺交易的實(shí)現等。

　　■　1. 流程開(kāi)發(fā)的任務(wù)配置菜單文件；

　　■　2. 開(kāi)發(fā)所有輸入項（比如輸入開(kāi)始日期、結束日期、幣種等等）；

　　■　3. 開(kāi)發(fā)業(yè)務(wù)流程，比如余額查詢(xún)，首先輸入卡號、然后輸入密碼、調交易、報讀結果，最后回到上級菜單；

　　■　4. 開(kāi)發(fā)交易過(guò)程，配置交易提交接口、調交易、返回值封裝等等，是開(kāi)發(fā)的主要工作；

　　■　5. 記錄日志、埋點(diǎn)等運維及運營(yíng)相關(guān)的功能。

　　所有業(yè)務(wù)流程都要從BusiBase類(lèi)中派生出來(lái)。流程開(kāi)發(fā)具體過(guò)程如下：

　　通過(guò)上圖可以看出，一個(gè)業(yè)務(wù)流程的完成，需要和平臺有多次交互才可以實(shí)現，每次交互流程類(lèi)的對象都結束了，都需要保存和恢復上下文，這是一個(gè)需要特別注意的地方。

　　平臺和業(yè)務(wù)系統之間通過(guò)接口實(shí)現，這個(gè)接口適合于所有的平臺。接口的具體內容如下：

　　文章來(lái)源：中電金信軟件有限公司遠程銀行事業(yè)部