好事如我者，搜索了一下http://www.highestbridges.com/它才排到第十四位！十四位！十四位！大赞一下我天朝基建狂魔！世界前十独占八成，前二十独占九成。第一时间想到毛主席的一首词：“一桥飞架南北，天堑变通途。更立西江石壁，截断巫山云雨，高峡出平湖。神女应无恙，当惊世界殊。”

　　这就叫Connecting People！

　　抒情完毕，今天来说说如何搭建WEB和语音呼叫中心之间的桥梁，我G厂也是真正地干着Connecting People的事嘛不是。

　　G厂做法有多少种，按照排名不分先后完全凭感觉地给你介绍三种。

　　G厂OCS外呼服务方案主要是为了大规模大容量自动外呼而设计，当然也支持小容量高价值的Preview预览式方式外呼。它的核心机制在于话单数据库CallingList的人工或者自动化导入和OCS的根据Campaign Group的自动提取。再依托于WebService的情况下，前端由客户指定要求Callback，输入Desired Time和相关的业务信息，后端经过号码部分逻辑过滤后，以JDBC的方式写入外呼的话单数据库中。具体示意如下图：

　　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的优越性。具体示意如下图：

　　如果说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就立刻打一条，动一次，打一次！动次，打次，动次，打次，苍茫的天涯是我的爱...。。