整体设计思想

在基于MXT多媒体系统平台建设、设计中，将力争达到使用最佳的软、硬件的技术相结合，为用户提供最为完整的方案，其实现的基础就是敏讯通公司对业界众多的软件、硬件平台功能与技术性能有着深刻了解，但又不依赖和成为任何一家软硬件生产商的经营者。因为任何一种单一软硬件供应都不可能满足日益增长的用户需要。一切从用户利益出发，结合敏讯通公司为包括中国电信在内的众多的用户提供各种用途的系统平台的多年的经验，提供一整套最佳的系统解决方案，是我们所遵循的原则。

MXT多媒体系统平台中，不仅提供了完整建设方案，而且从软、硬件构造上准备了系统的扩充以及与其它系统、第三方数据源的连接，并采用多重措施来保障由此带来的安全问题；不仅考虑满足用户业务需求，而且以我们特有的经验选择合理配置的软硬件，即实用又节省用户的投资。总之我们本次提供的方案不仅仅是技术上的可行性分析，而是一套完整的系统解决方案。

应用系统设计思想

系统软件平台选用了开放式的符合国际标准的产品。这些系统平台包括服务器的操作系统、数据库管理系统、微机操作系统、Web服务器和浏览器等。

各个应用子系统和各工作节点之间的网络通讯协议采用工业标准的TCP/IP协议。

在各个应用软件的设计、开发过程中，采用了模块化的设计，便于对系统进行维护和管理。

充分利用敏讯通公司多年积累起来的经验，为各个系统提供最方便使用和管理的系统。

系统设计原则

在对本次一卡通呼叫中心客服信息管理系统平台进行设计时，我们遵循以下原则：

(1)       业务连续性：对目前运行在老平台上的重要业务，可以经过不间断平滑移植到新平台上，以保持对用户服务的连续性；

(2)       模块化设计：系统中的功能模块、接口模块等，可以有选择地运用、组合，完成各项业务功能，模块之间应相互独立，单一模块的损坏和更换不影响其他模块的应用，同时，对于部分重要模块，可以在系统中通过双重设计，以保证系统在运行过程中不会因为某模块的故障而导致业务的故障；

(3)       先进性与成熟性：系统平台采用成熟、先进的技术，保证整个系统在技术上处于领先地位，系统在建成后一段时间内不会因技术落后而大规模调整，并能够通过升级保持系统的先进性，延长其生命周期，同时又要保证先进的技术是稳定的、成熟的；

(4)      可扩展性：本系统的设计和建设充分考虑网络、硬件的扩展需要，以及支持未来可能出现的新业务的需要，保证以后可以方便地升级和不断增加新业务、增加容量、以及在同一平台上扩充其他业务功能；在业务量增长以及由其他业务需求的情况下，平台应设计成具有平滑扩容的能力；

 可维护性：系统提供方便、灵活的维护手段，方便维护人员的维护和管理；

总体设计

       整个客户服务中心示意如下：

       图形说明：其中黑色的线表示ISDN专线，蓝色的线为网络线。其中CCS/DBProxy/QOS服务器为目前系统的CTI服务器立旧，在CTI服务器上安装3个服务程序（CCS、DBProxy、QOS），考虑到系统的安全与备份，我们在数据加载服务器上同时也安装这3个程序备用（CCS、DBProxy、QOS）在遇到机器故障时可以启用备份系统，详细的系统启用参见系统的使用手册。

主要体现三个部分：敏讯通公司呼叫中心平台部分，用户业务部分，与一卡通后台接口部分。

整个客服系统建立在敏讯通公司呼叫中心平台基础之上，在此平台之上建立所要完成的具体业务。整个客户系统提供客户三种手段来解答一些用户关心的问题，完成一些可以通过这些手段可以实现的业务操作。这三种手段为：

1.自动语音：通过打入呼叫中心电话根据语音提示自动完成，具体能完成的功能请参见自动语音实现部分。

2.座席系统：通过打入呼叫中心电话然后把电话转到话务员，由话务员协助用户解答问题或者完成其所要完成的业务。

3.客服网站：通过用户访问客服网站根据网站的形式完成其业务。

这三种实现业务的方式所实现的具体业务基本相同，只是由于某种具体方式在实现某些业务时可能会存在一定的差别。具体每种方式所实现的具体业务功能请参见需求规定及业务实现部分。

前面所提到整个客服系统建立在敏讯通公司呼叫中心平台基础之上，那么业务系统与平台之间的接口方式如下：

1、平台的座席系统是一个内嵌IE浏览器的模块，因此用户要求实现的业务功能就只要通过WEB方式开发即可与平台实现联接。而其中的座席业务与座席系统的接口就只有一小部分的信息交互，包括座席系统自动进入相关业务功能网页以及座席系统把相关的呼叫信息（如主叫号码等）传给WEB网页形式的业务系统。

2、自动语音部分通过平台脚本语言通过数据库代理访问数据库实现其业务功能。

3、客服网站与平台之间没有接口。不过客服网站和座席业务系统及自动语音部分使用同一套数据表，实现三者的统一。

三种手段的具体实现方式如下：

       自动语音：

这一种业务的实现方式通过敏讯通公司的平台提供的脚本语言进行实现，此脚本语言可以通过播放语音文件提示用户按电话机上相应的键，然后系统根据用户的按键进行相应的数据库操作。

       座席业务：

这一种业务的实现方式由用户呼入到敏讯通公司平台，然后把电话转接到话务员，然后由话务员利用座席系统访问座席业务系统协助用户完成。

       客服网站：

客服网站在整个客服系统中比较独立，与平台之间不存在接口，只是与座席业务和自动语音部分通过共用一套数据表来达到数据的统一。

需求规定

       这里仅提供一个需求列表，是基本保留或改进目前系统的现有功能，满足坐席和公司对外的网站需求。

       公司网站功能性需求：

       公司介绍、使用方法和规则、相关资费、一卡通充值点分布图、使用领域介绍、咨询服务、卡挂失解挂失、用卡查询、意见及反馈、个人购卡登记、集体购卡登记、大额充值登记、新闻栏、产品介绍、广告栏、个人信息修改、邮件系统、网络链接到相关的链接页面。

       座席业务系统功能性需求：

       业务咨询、余额查询、交易查询、转接用户电话到指定的号码（如：Bus热线、地铁客服、或有关的专家电话）用户投诉、用户建议、个人购卡登记、集体购卡登记、大额充值登记、业务知识管理。

       自动语音功能性需求：

       听取产品介绍、听取代理代办业务介绍、听取公司介绍、听取使用方法和规则、听取使用领域介绍、听取相关资费、自动卡查询、月票余次查询、充值续费查询、自动用户建议、自动用户投诉。

运行环境

       本系统是利用敏讯通公司客户服务平台进行集成，此平台Web服务器系统是运行在Windows2003平台上，其余系统都运行在Windows2000环境下。在此平台基础之上的业务功能用Web方式完成。

平台功能概述

  目前一卡通客服系统平台的突出问题主要体现在两个方面：1、系统的设备老化，带来故障率高，增加维护成本。2、应用系统随着业务的拓展和用户的增长，带来平台应用的局限性和功能的不足。

  本次改造需要依据两个方面进行，首先要求解决目前系统出现的故障，减少人工对目前系统的维护量，淘汰更新落后的产品和技术，使系统稳定性和功能加强和加大，更大可能的减少日后对系统的维护投资。改善系统平台的设计适应目前的需求从技术上进行更新，满足客服系统的功能提高平台的效率。

电话平台更新设计

   采用当前的先进技术，用NGN软交换代替目前的硬排队系统，从传统的以电路交换为主的PSTN网络中逐渐迈向以分组交换为主，它承载了原有PSTN网络的所有业务，把大量的数据传输卸载到IP网络中以减轻PSTN网络的重荷，又以IP技术的新特性增加和增强了许多新老业务。撤除排队机，减掉对目前排队机的维护，基于IP的坐席模式有极大的方便分布式的坐席接入，也去除掉基于排队机的远程模块，同时由于采用IP坐席接入，也省掉目前的坐席的语音专线。节约系统的维护成本，增大了系统的稳定性。同时在语音上增加转接功能，用户电话可以通过坐席或语音流程转接到指定的号码上去，如：李素丽热线，公交热线，地铁投诉电话等，只要需被转接方提供普通电话能呼入的号码就可以进行转接。

业务系统的更新设计

  1）、Web系统改造。

    应用上用Windows2003企业版＋Tomcat 开发环境为JSP，采用网络均载平衡技术，两台Web服务器并行工作，分担网络访问流量，每台服务器的并发访问量初步设计为300左右，在网络带宽的不限条件下能达到600个并发访问，利用集群技术最高能达到8个节点，目前的网路出口带宽为2M，考虑公司网站的页面流量数据为10k左右，正常情况下能支持200个并发量，在架用两个节点WEB服务器，可以满足6M的带宽的网路接入，由于目前公司的网站存在缺陷，无法准确估算出平均的访问量，参照目前门户网站如：sina每天访问量1亿左右，共15个站点，每个站点每秒并发量近200左右，考虑到访问时间的集中，其最大并发数为1000左右的数据，200个并发量能够满足目前一卡通公司的持卡用户为500万的WEB访问需求，同时采用集群架构，可以根据访问量动态调整，随着业务的拓展，网络流量的增加，基于集群的架构能够更好的适应需求，增加带宽或增加服务器，能满足公司的业务需求，同时也起到Web系统的安全性，某台服务器出故障时，不至于这个网站都无法访问，提高了系统的安全和处理性能。本次web改造在功能上，要有网络链接，或在网站的页面中嵌套一些和一卡通公司相关的行业的主页。

2）、数据入库加载模块的改造

目前的卡用户近500万，每天的消费记录（分月票消费，普通卡消费）为近700万，其中月票消费和普通卡消费各将近300万左右，现在的入库平均速度约为180000条每小时，也就是本日的数据不能及时入库，这是有几个原因造成，1、目前的数据结构设计不合理，普通卡的消费记录和月票卡的消费记录分别为各一个表，对于数据库oracle8i上亿条的数据，很难及时处理过来，2、数据入库时是分拣入库，对每条数据都是解析后再入库，造成数据库的运算量加大。3、数据库硬盘设备老化，造成I/O速度下降。4、对于海量数据服务器的性能是个重要指标。

在本次改造中，首先更改数据库的表结构，为保证平台的平滑过渡，在目前的数据库服务器上新建出个库，供本次平台改造用，在割接完全后，再删除目前的老库。在数据结构上，为普通卡和月票卡的消费记录，每天建一个表，对于普通卡的消费记录保留近3个月的历史数据，月票卡的消费记录保留近1个月的数据。数据的加载程序采用入库时不解析原始数据，根据测试每小时入库量估算为150万，这样能保证每天的消费数据能当天入完库，根据卡的发行量和消费数据比可以满足1000万卡的消费数据当天入完库，能够解决用户的及时查询。

系统规模

中继规模 　　目前提供的中继为10*E1，即同时支持300线的用户接入；

座席规模 　　根据目前的公话客服要求，在本次系统的合作中，先期开设1个班长席和9个普通座席； 　

外部数据连接 　　

客服中心与外部如区站、公话公司、GTS等在完成网络连接后，需要在客服中心与每一个外部站点之间进行数据
传输，数据传输主要包括四个方面的连接；

区站与客服中心数据连接 　　

    在区站与客服中心建立数据连接主要用于各区站的查询，在区站的客户端系统（通过浏览器）可查询指定的
数据和话机信息； 　　

查询的内容包括以下方面： 　　

  公话用户申请单到达通知：当公话用户申请安装公话时，由客服座席进行登记，并存放到数据库中，区站管理
人员每天进行系统登录后，可查询指定时间上的公话申请数据；同时，完成接收后，通过系统签收公话申请单，
同时当区站审核用户后，将审核结果通过客户端系统上报客服中心，以供客服中心向用户提供查询服务；

中国联通短讯连接 　　

联通公司目前采用的协议为ETIP和SGIP两种协议，在一般情况下，只提供SGIP协议，SGIP协议为短消息网关
接口协议，在本协议中用于SP接入165平台的接口协议，完成165平台短消息的发送、接收和转发功能。 当SP
需要与联通短讯中心进行连接时，首先需要基于SGIP协议完成接口的处理。

根据联通的165短讯平台的体系结构，在声讯系统只需要基于SGIP协议建立与165短信下载业务处理平台建立
连接即可完成对联通的短信连接。 　　

对于中国移动北京公司，其短信网关采用亚信公司的产品，其系统放置在Internet网络上，任何能登录到
Internet的设备都能授权访问，同时对于中国联通北京分公司而言，其系统同样可以通过Internet网络进行
授权访问，当需要与它们建立物理连接时，一般情况下需要声讯平台系统中的短信接口网关能同时访问
Internet网络和内部网络即可。在软件系统上，MXT-2002平台系统中的短消息接口系统软件能通过CMPP和SGIP
协议分别与中国移动和中国联通的短信网关进行连接，以满足系统的业务需要。

与寻呼系统连接 　　

由于检查员一般情况下配置了BP机，当客服系统需要实时与检查员进行联系时，需要通过BP进行，因此，在
系统中设置客服中心系统与寻呼系统的连接是必不可少的工作。
　　在一般情况下，可采取两种方式实现客服中心与寻呼系统进行连接，分别如下：
　　与寻呼系统建立网络连接，即从客服中心与寻呼系统建立专线连接，由客服中心进行将发送的数据连接到
寻呼系统的编码器或发送队列上，通过该方式时可减少人工操作，提高寻呼效率；
　　在客服中心配置一台寻呼座席，当有寻呼数据到达时（由其它座席或GTS自动采集），该座席即呼叫寻呼
系统，通过人工干予完成寻呼工作。
　　在与寻呼系统建立连接时，如检查员配置了汉字机，则在BP机上显示全部信息，无需检查员通过电话进行
要求查询，如检查员配置的BP机为数字机时，则在数字机上显示工作代码，由检查员通过电话回拨客服系统，
由系统自动将工作内容告之检查员。

客服中心与GTS的数据连接中，主要包括四个方面的数据交换： 　

1、公话终端障碍数据：
　　公话终端障碍数据由GTS侧实时写入到接口数据表，客服中心对障碍接口表进行
定时（间隔时间可通过管理员进行设定）读取，当读到有公话障碍数据后，系统自动将该障碍记录到数据库中，
同时，自动通知到相应的巡查员。当修理完成后，巡查员将结果告之至客服中心，由座席填写处理表，并通过
障碍接口表将接口发送到GTS系统。 　

2、 IC公话线路障碍：
　　当巡查员在修复话机障碍过程中，发现属于话机外线障碍，即通过电话上报至公话
客服中心，由座席将该障碍通过接口数据表转发至GTS系统，待区局修复后，由GTS通过接口数据表转发至公话
客服中心。 　

3、 线路报竣工单：
　　GTS系统在接收到的报竣工单后，通过数据接口表转至公话客服中心，客服中心将收到的报竣工单汇总
整理后，下发到各区站进行装机。 　

4、 话机基本资料变更：
　　当IC话机资料变更后，由公话座席对资料进行修改，修改完毕，通过接口数据表将变更后的数据发送到
GTS系统中，以保证双方系统话机资料的一致性；