在呼叫中心外呼业务中，问卷调研或信息挖掘类的项目占很大部分。这些业务的特点是数据量大、业务相对统一。特点有这样两方面：

　　(1)业务流程相同

　　这些业务大致分为：获取客户基本数据、处理客户基本数据、回答问卷流程。

　　(2) 数据量大、数据信息准确

　　由于做问卷调研的座席每天要完成大量的问卷，这就要求外呼系统不仅能够处理大量的问卷，同时还要保证数据准确。

　　当前呼叫中心外呼业务系统主要是基于B/S、C/S两种结构，由于B/S系统容易部署、维护量小, 因此在少量座席的情况下采用B/S结构有着较大的优势。但是B/S服务器的负荷较重，当呼叫中心的座席数达到上百上千时，B/S结构的缺点就显现出来了。由于C/S结构客户端和服务器端都能够处理任务，因此C/S结构能解决座席数量大的问题。

　　当前很多公司外呼业务系统都采用两层的C/S结构，但随着公司业务的扩大，这种结构也会严重阻碍公司的发展，主要表现在：

　　(1)数据不安全

　　这种系统可以直接访问数据库，数据是否被正确存储不能被监控到，一旦数据部分或全部丢失，整套呼出数据就可能作废，因此这种结构对数据的安全没有保证。

　　(2)加重了技术人员的工作量

　　外呼业务中有一项是调研，随着调研项目的变化，要求技术部门重新修改呼出界面，加重了技术人员的工作量，而且工作的重复性很高。

　　(3)座席的工作效率低

　　座席在使用系统时一旦发生错误，就不得不停止工作，直到技术人员进行系统修复后才能继续工作，这严重影响了座席的工作效率。

　　(4)监控比较难，致使公司管理人员和技术部门不能更好的监控座席。

　　呼叫中心发展到今天，要求管理越来越精细化，不仅在人员和设备上要上一个新台阶，在系统平台的支持上也要上一个新台阶，要求呼叫中心的支持系统与业务和数据库统一起来。这不仅大大提高整个呼叫中心的效率，减少技术部门的人员数量，降低维护成本，同时可以使管理人员的监控变得更加容易。因此，改进当前系统对公司发展有很重要的作用。

　　改进后的外呼业务系统

　　针对旧外呼业务系统的弊端及业务系统特点，赛迪呼叫研发了基于三层C/S结构的外呼业务系统，该系统分客户端，接入服务器，业务服务器及数据库端。客户端发送请求给分配服务器，接受到请求后，分配服务器根据客户端的请求数据将其分配给自身的业务服务器做业务处理，这样客户端与业务服务器建立起联系，结构体系如图：

　　新系统工作原理：

　　当座席登陆后，外呼业务系统客户端会发送请求通知接入服务器要连接哪个业务处理服务器，接入服务器接受到请求后将座席客户端与业务处理服务器建立起连接。

　　整个业务数据和业务处理都由XML配置管理，系统业务被分成本地业务逻辑和服务器端业务逻辑，客户端通过提取本地业务逻辑脚本中的数据处理业务逻辑，业务处理服务器通过提取服务器端业务逻辑脚本中的数据访问数据库，并将数据库返回结果发往客户端。本地业务逻辑和服务器端业务逻辑之间的逻辑关系是通过一套配置脚本维护。如图：

　　本地业务脚本配置了本地的业务数据、业务约束的条件及业务逻辑，格式如下：

　　该节点的约束条件配置到节点中，当前的数据和业务逻辑配置到[data]节点中，逻辑的跳转[next Acton]定义着。这样业务，数据，业务关系就通过这种方式串接起来。客户端处理程序按照[condition]定义好的条件处理当前[data]节点中的数据后得到一些新数据。

　　服务器端业务脚本配置着服务器端的数据同时也配置着访问数据库的sql语句。格式如下：

　　节点中配置着对数据库操作的查询、更新、插入、删除语句，或一些定义好的存储过程。[data]节点中配置从数据库中取到的数据是以什么样的方式被发往到客户端的。当客户端程序发送请求给服务器端程序时，服务器端先确认当前动作是什么，并读取客户端发来的数据，服务器程序读取配置好的语句，并将从客户端获得的数据填充到sql语句中，执行sql语句后，将返回的结果按照节点定义好的数据格式，将数据发回客户端。

　　新系统的优点：

　　改进后，整个业务被拆分成两部分，服务器端业务逻辑、本地端业务逻辑。具体的优点是：

　　(1) 业务逻辑清晰

　　系统的业务被拆分成两部分，服务器端业务逻辑、本地端业务逻辑。服务器端业务主要完成数据库的操作，本地端业务主要完成本地的一些逻辑跳转。业务被拆分成很多动作，每个动作完成一部分的工作任务，将所有的动作串接起来，整个工作流就被确定下来，通过这种方式，整个业务被细化，相同的任务可以使用同一个动作节点，简化了代码的重用，将业务拆分开后整个业务变得简化、清晰、明了。

　　(2) 业务数据和业务逻辑被封装到脚本中，因此当业务逻辑变更时，不会影响系统程序修改，只需调整业务脚本即可。

　　改进前的业务整个被封到程序代码中，当呼叫中心系统因业务要求需要调整时，系统不得不将此要求反馈给维护人员修改，这不仅增加了维护人员的工作量，也影响了呼叫中心的业务。

　　改进后的新系统，业务脱离代码被封装在由XML(可扩展标识语言)配置的脚本中， 一旦业务改动，系统并不需要改动，只需重新修改业务脚本中的数据、业务逻辑及动作之间的跳转关系。维护人员只需修改某些节点中的数据及节点与节点之间的关联就可以完成业务修改，这大大降低了维护人员的工作量，同时提高了使用人员的工作效率。

　　(3)减少了数据库处理压力

　　旧系统中，频繁的读取数据给数据库造成了极大的压力，改进后的新系统采用数据库连接池，当连接数据过多时，服务器端系统会将多余的连接加入到等待队列中，这样就降低了数据库的访问压力。

　　(4)容错处理容易

　　旧系统中，当业务出现问题时，维护人员不得不重新察看程序，找到错误的发生位置。由于系统直接访问数据库，数据的存储不能被记录跟踪，数据一旦被检查出错误，已经来不及了。

　　改进的新系统增加了日志处理，每一次动作的操作数据都被记录下来，维护人员可以动态跟踪数据及系统运行情况，当系统遇到问题时，维护人员可以轻松的查询哪个业务动作节点出现问题，容错处理变得非常容易。

　　(5)增加了系统的扩展性

　　在新系统上，可以开发呼叫中心的人力系统、监控系统等。

　　总之，使用了三层C/S框架结构的新系统，系统业务被分离开来，业务脚本维护着整个系统的数据和业务操作。 新系统使业务逻辑变得清晰，这减少了系统维护人员的工作量，同时增加的日志工作可以帮助维护人员跟踪错误。