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