好事如我者，搜索了一下http://www.highestbridges.com/它才排到第十四位！十四位！十四位！大贊一下我天朝基建狂魔！世界前十獨占八成，前二十獨占九成。第一時間想到毛主席的一首詞：“一橋飛架南北，天塹變通途。更立西江石壁，截斷巫山云雨，高峽出平湖。神女應無恙，當驚世界殊。”
這就叫Connecting People！
抒情完畢，今天來說說如何搭建WEB和語音呼叫中心之間的橋梁，我G廠也是真正地干著Connecting People的事嘛不是。
G廠做法有多少種，按照排名不分先后完全憑感覺地給你介紹三種。
1.Outbound Contact Server
G廠OCS外呼服務方案主要是為了大規(guī)模大容量自動外呼而設計，當然也支持小容量高價值的Preview預覽式方式外呼。它的核心機制在于話單數(shù)據(jù)庫CallingList的人工或者自動化導入和OCS的根據(jù)Campaign Group的自動提取。再依托于WebService的情況下，前端由客戶指定要求Callback，輸入Desired Time和相關的業(yè)務信息，后端經(jīng)過號碼部分邏輯過濾后，以JDBC的方式寫入外呼的話單數(shù)據(jù)庫中。具體示意如下圖：
2.Genesys Mobile Server
G廠的移動解決方案GMS通過開放的RESTAPI搭建了一個開放的體系，不僅僅是語音的Callback，Call Matching，Virtual Hold等炫技功能以外，還可以支持email和chat，呃，我又扯遠了，拉回來。它的核心機制在于REST的無狀態(tài)HTTPPost觸發(fā)一個Inbound Voice的Orschestration的Callback.scxml，后端在業(yè)務具體處理方面可以充分展現(xiàn)出復雜路由的優(yōu)越性，在客戶的Web界面上也能提供POS（排隊數(shù)）和EWT（預計等待時長）等數(shù)據(jù)，還可以很方便地結合office hour功能提供schedule和reschdule，從技術上來說，要比OCS復雜，但是可以兼容PC Web，Mobile Web，APP Native，APP Web等多種制式，顯示了REST的優(yōu)越性。具體示意如下圖：
3.SSG:Supplementary Service Gateway
如果說OCS是弓，GMS就有點像是弩，而SSG則是我喜歡的那種漢陽造--毛瑟槍。少說了，直接上圖：
是不是很簡單？是不是很粗暴？我喜歡。
簡單在于SSG只負責翻譯工作，也就是來自第三方系統(tǒng)的Http Request發(fā)過來，按照SSG的格式進行解析，轉換成一個Tilb的TRequestMakeCall直接打電話給最終用戶。粗暴在于SSG不僅僅是無狀態(tài)，甚至是不關心電話結果如何的，它只負責收請求發(fā)請求，不談人情，沒有HA，如果要回復，回復也是粗暴:200ok，successful，failed。
這里跟GVP有啥關系？老實說，可以沒關系。但是天真可愛的研發(fā)們說了，SSG屬于GVP產(chǎn)品線下的產(chǎn)品，怎么說也要內部走點關系照顧自己人，所以SSG的Request實際上是TRequestMakePredictiveCall，也就是說帶CPD功能的，而且必須指定一個IVR Profile。有人說只想接坐席不想用IVR，也可以啊，IVR配一個VXML，VXML里面的內容就是Entry-TRouteRequest到路由唄～總之，要過一下GVP。
但是，我們還是低估了SSG的存在意義：
某種意義上這是G廠很早就做的成品解決方案，它的特點在于不關心業(yè)務，對的！一點也不關心！業(yè)務邏輯你們梳理清楚之后直接給號碼，給隨路數(shù)據(jù)，SSG就直接干活了。
亮點在于第三方的Trigger Application，這即可以是最終用戶訪問Web發(fā)起的Request，也可以呼叫中心內部執(zhí)行一些自動化腳本或者商業(yè)邏輯觸發(fā)的。
比如：下午6點的機票，2點氣象局突然提示有暴雨預警，CRM系統(tǒng)自動執(zhí)行觸發(fā)給SSG打電話做IVR通知。
或者：呼叫中心的業(yè)務系統(tǒng)隨時生成的collection數(shù)據(jù)，都不用等一天，等一周做好Calllist才load進系統(tǒng)打電話，生成一條SSG就立刻打一條，動一次，打一次！動次，打次，動次，打次，蒼茫的天涯是我的愛...。。
