第五代呼叫中心之SOA(四)

   上一章说的是基于SOA思想建设一个呼叫中心很难,主要难点是灵活性和稳定性的矛盾。是啊,一方面客户要求7*24小时不停机,另一方面,客户需求在不断变化,处于这个矛盾中间,我们如何基于SOA的思想建设呼叫中心呢?

  我认为核心在于根据稳定性和灵活性的要求提供呼叫中心需要的服务接口以及接口的组织。


一 服务接口的提供

  呼叫中心服务的接口包括以下内容:

  1. 交换机服务接口;
  2. IVR物理环境服务接口,如语音板卡、H.323语音终端、SIP语音终端接口;
  3. 录音物理环境服务接口,如录音板卡、IP语音镜像录制软件接口;
  4. CTI服务器服务接口;
  5. IVR服务器服务接口;
  6. 录音服务器服务接口;
  7. ACD服务器服务接口;
  8. ADS服务器服务接口;
  9. ACC服务器服务接口;
  10. ICC服务器服务接口;
  11. 坐席软电话服务接口;
  12. 业务软件服务接口;
  13. 报表服务器服务接口;
  14. 实时统计服务器服务接口。

  我现在对以上的接口进行分析,并提出我的建议。

  1.1 通信服务接口的标准化

  对于通信相关的服务接口,标准化程度相对高一些,恰恰是基于SOA思想建设一个呼叫中心中相对简单的问题。

  交换机接口、IVR物理环境接口、录音物理环境接口,有很多标准,有些是ITU、ECMA、W3C的标准,有些则是事实的标准,由国际大厂商主导的。

  按照标准提供接口,好处有两个:

  一方面,接口非常稳定,以CSTA II为例,现在还是主流的交换机和计算机通信的协议,这个协议是ECMA组织在1994年发布的,经过了15年时间,依然是主流协议;TAPI则是微软在1994年就开始发布了,最晚的版本TAPI3.0 也是和Windows 2000同时发布的,可见这部分标准是稳定性很高,标准稳定,意味着软件可以大规模复制,开发成本低,而且软件稳定性高;

  另一方面,既然有标准,而且还是大厂商主导的,那么大厂商在建立标准的时候,已经将大量的复杂或者说多变的需求已经考虑进去了,因此,按照标准提供的服务接口,灵活性是有保证的。

  对于这部分接口,是通信和计算整合的关键,是世界级的难题,既然是世界级的难题,就让世界级的大厂商解决,由他们来解决的稳定性和灵活性的矛盾解决。我们只需要利用大厂商的劳动成果即可。

  1.2 CTI服务器服务接口

  CTI服务器稳定性要求很高,因为CTI服务器的故障会导致整个呼叫中心的呼叫相关的软件无法工作。

  CTI服务器灵活性要求很低,它只需要将交换机来的数据进行分发,收集来自其他系统的命令,发送给交换机即可。

  因此,CTI服务器的服务接口相对简单。

  1.3 ACD服务器和IVR服务器的服务接口

  ACD和IVR接口是呼叫中心中的难点,相对于用户来说,ACD和IVR提供了服务接口,而对其他软件系统,同样需要服务接口以便ACD和IVR调用。

  ACD和IVR流程控制的复杂性,后面我们会详细说明,现在重点说一下ACD和IVR对其他软件系统的服务接口。

  一方面,ACD和IVR需要调用其他软件的服务接口,接口形式如下:COM、DCOM、DLL、TCP、UDP、ASP、JSP、PHP、Web Service。

  另一方面,ACD和IVR需要提供调用接口以供其他软件系统调用,其中包括WebService服务接口、TCP服务器接口。可以设想,ADS需要控制IVR外拨,坐席软电话需要控制IVR播报需要的语音、ACD服务器需要IVR在客户排队的时候播报等待的提示语,ACD服务器需要提供排队信息给实时统计,ACD服务与ADS进行交互等。

  ACD和IVR服务接口没有标准,需要我们根据国内的客户需求分析整理,我的建议如下:

  服务接口要求全面:必不可少的包括数据库访问、Web Service和TCP,为了进一步降低用户开发成本,建议提供COM、DCOM、DLL、UDP、ASP、JSP、PHP;

  实时性:提供的服务接口满足实时性要求,即要求可以流程并行执行,例如,IVR在流程中,需要查询一个客户需要的数据,大概需要10秒钟,那么,流程在查询的过程中,需要同时执行放音流程,以便用户能够耐心等待;

  数据复杂计算:在外部交互的时候,需要对数据需要复杂处理,需要支持VBScript、Jscript等等,而且,为了保证实时性,建议使用不要使用流行的浏览器中脚本引擎。

  另外,我建议将交换机定义的坐席状态做封装和扩展,对外提供服务接口。

  1.4 录音服务器服务接口

  录音服务接口实时性要求比较高,建议的接口形式为Web Service和TCP。

  需要提供的服务包括以下几个方面:

  1. 录音的启动停止控制:例如,坐席控制录音的启动停止;
  2. 录音记录呼叫标识及数据的输入:第三方系统接收CTI系统的事件,根据CTI事件控制录音启动停止,将CallId、主叫和被叫号码输入到录音系统中;
  3. 录音关联的业务数据的输入:例如,录音记录中,需要包含业务的订单ID、工单ID、产品名称等等数据;
  4. 录音实时统计的输出:有的呼叫中心经常需要显示每一条线的录音状态和数据;
  5. 录音记录数据的输出:很多业务系统中需要在录音开始或者录音刚刚结束时,即提取录音相关数据,进行业务处理,例如提取录音文件名、录音时长等记录到工单数据库中;
  6. 录音查询接口:这是基本的接口。

  1.5 ADS服务器服务接口

  ADS服务器服务一部分对性能要求有较高的部分,也有较低的部分。

  ADS对于性能要求较低部分的接口包括:

  • 号码导入:ADS需要外部号码导入的服务接口;
  • 外拨结果输出:ADS需要将外拨运行的结果输出到报表服务器,以便形成报表;
  • 录音数据整合:为录音服务器提供录音需要的特定的ADS的外拨数据。

  ADS对于性能要求较高部分的接口包括:

  • 实时统计数据获取:ADS为了执行外拨算法,需要实时获得中继、IVR、队列、坐席的实时统计数据;
  • ACD交互:ADS和ACD交互以达到合理的呼叫分配,在呼入呼出混合的呼叫中心中尤其重要;
  • 实时统计数据输出:ADS需要将内部数据实时输出到管理者控制台;
  • 实时策略调整输入:ADS需要接受管理者的实时控制,如加强或减弱外拨强度等。

  1.6 ICC服务器和ACC服务器服务接口

  ICC服务器和ACC服务器的服务接口我认为在控制和事件的内容上按照交换机的服务接口设计,以达到最高的复用程度,建议参考CSTA-II、CSTA-III或者是TSAPI接口。

  1.7 坐席软电话服务接口

  坐席软电话的服务接口是针对坐席业务软件提供的。

  我的建议提供如下接口:

  • 透传交换机的服务接口(当然是经过CTI服务器转换过的);
  • 透传ACD和IVR服务接口;
  • 透传ADS服务器服务接口;
  • 透传ICC服务器和ACD服务器服务接口;
  • 透传报表服务器中呼叫相关的服务接口;
  • 透传实时统计服务器中呼叫相关的服务接口。

  1.8 业务软件服务接口

  业务软件服务接口是和具体的服务行业相关的,需要按照行业内的需求进行划分,在这里,我只有一个建议,最好要用WebService接口。

  1.9 报表服务器服务接口

  报表服务器对外接口方面实时性要求不高。

  报表服务器包括两个部分,一个是呼叫(包含坐席管理)相关的报表服务器,一个是只包含业务软件数据的报表服务器。

  只包含业务软件数据的报表服务器服务接口是和具体的服务行业相关的,需要按照行业内的需求进行划分,在这里,我还是只有一个建议,最好要用WebService接口。

  呼叫相关的报表服务器,我建议有两个方面:

  • 以WebService的形式提供;
  • 以结果临时表的形式提供;
  • 报表指标项本身全面。

  1.10 实时统计服务器服务接口

  实时统计服务器服务接口的形式建议不用WebService这样效率较低的接口形式,建议如下:

  • 采用格式紧凑的TCP基础上的传输形式;
  • 对外调用接口尽量丰富,包括Dll、Ocx;
  • 为了B/S调用方便,最好直接提供封装AJAX的Java Script对象;
  • 提供订阅方式的接口;
  • 提供类似于SQL的查询方式和结果集返回方式。

二 ESB与实时服务总线

  从上面我们可以看出,各个系统都需要提供服务接口,这样,各个部分之间的交互会非常非常多。

  建议对于实时性要求不高的业务软件部分采用ESB降低交互的复杂度;对于实时性要求较高的呼叫相关的软件部分建立实时服务总线。

  ESB的接口自然以WebService形式提供,而实时服务总线比较复杂,经常需要以三种形式提供接口:

  1. 软电话OCX:用于坐席业务和总线通信;
  2. dll:用于服务器软件与总线通信;
  3. Java Script对象:封装AJAX,用于Web客户端与总线通信。


三 服务的接口与流程策略的关系

  按照SOA的思想,软件的功能是按照服务的方式提供的,其他软件将服务聚合,按照“搭积木”的方式即可快速生成业务。

  第五代呼叫中心中,各个部分只要提供合理的服务,快速生成业务也就成为可能。

  但是,只考虑服务的聚合是不够的,还要考虑服务的流程策略,不断变化的流程让耗费了大量的开发成本,也大大影响了软件的稳定性。

  呼叫中心的流程策略我认为应该分成两个部分,一部分是实时性要求较低的业务相关的流程,另一个部分是实时性要求很高的呼叫相关的流程。

  目前,业务软件方面,普元的BPS迅速崛起,就是SOA流程平台,解决基于SOA思想软件如何处理复杂多变的流程的。因此,建议业务软件为了实现业务敏捷需要使用或者自行开发流程平台。

  可是,实时性要求很高的呼叫相关的流程策略需要特殊的流程平台,这部分流程包括IVR流程、呼叫路由流程、坐席状态管理策略、外拨策略、告警策略等等。因此,建议实时的工作流平台由呼叫中心厂商自行提供。

  下一章,开始讲实战的部分。


阅读更多
个人分类: CTI
上一篇第五代呼叫中心之SOA(三)
下一篇第五代呼叫中心之SOA(五)
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭