背景
该系统以敏讯通公司客户服务中心平台为基础，客户服务中心的电话功能由平台实现，此次要求开发的部分仅限于实现用户要求的业务功能，由于平台的座席端提供的业务接口为Web方式，因此座席业务系统由网站方式实现。同时用户要求建立一个公司网站，在其上也实现部分业务功能。WEB网站采用Windows2003＋Tomcat5所作为采用两台网络负载平衡服务器，具体业务开发采用Java利用Servlet方式进行开发。
本次改造是基于已经运行的一卡通客户服务中心系统，因此要求与一卡通整个后台系统交换卡信息数据与前期的要求相同，其中的技术参数等细节在本次文档中不再详细描述。
整体设计思想
在基于MXT多媒体系统平台建设、设计中，将力争达到使用最佳的软、硬件的技术相结合，为用户提供最为完整的方案，其实现的基础就是敏讯通公司对业界众多的软件、硬件平台功能与技术性能有着深刻了解，但又不依赖和成为任何一家软硬件生产商的经营者。因为任何一种单一软硬件供应都不可能满足日益增长的用户需要。一切从用户利益出发，结合敏讯通公司为包括中国电信在内的众多的用户提供各种用途的系统平台的多年的经验，提供一整套最佳的系统解决方案，是我们所遵循的原则。
MXT多媒体系统平台中，不仅提供了完整建设方案，而且从软、硬件构造上准备了系统的扩充以及与其它系统、第三方数据源的连接，并采用多重措施来保障由此带来的安全问题；不仅考虑满足用户业务需求，而且以我们特有的经验选择合理配置的软硬件，即实用又节省用户的投资。总之我们本次提供的方案不仅仅是技术上的可行性分析，而是一套完整的系统解决方案。
应用系统设计思想
系统软件平台选用了开放式的符合国际标准的产品。这些系统平台包括服务器的操作系统、数据库管理系统、微机操作系统、Web服务器和浏览器等。
各个应用子系统和各工作节点之间的网络通讯协议采用工业标准的TCP/IP协议。
在各个应用软件的设计、开发过程中，采用了模块化的设计，便于对系统进行维护和管理。
充分利用敏讯通公司多年积累起来的经验，为各个系统提供最方便使用和管理的系统。
系统设计原则
在对本次一卡通呼叫中心客服信息管理系统平台进行设计时，我们遵循以下原则：
(1)、业务连续性：对目前运行在老平台上的重要业务，可以经过不间断平滑移植到新平台上，以保持对用户服务的连续性；
(2)、模块化设计：系统中的功能模块、接口模块等，可以有选择地运用、组合，完成各项业务功能，模块之间应相互独立，单一模块的损坏和更换不影响其他模块的应用，同时，对于部分重要模块，可以在系统中通过双重设计，以保证系统在运行过程中不会因为某模块的故障而导致业务的故障；
(3)、先进性与成熟性：系统平台采用成熟、先进的技术，保证整个系统在技术上处于领先地位，系统在建成后一段时间内不会因技术落后而大规模调整，并能够通过升级保持系统的先进性，延长其生命周期，同时又要保证先进的技术是稳定的、成熟的；
(4)、可扩展性：本系统的设计和建设充分考虑网络、硬件的扩展需要，以及支持未来可能出现的新业务的需要，保证以后可以方便地升级和不断增加新业务、增加容量、以及在同一平台上扩充其他业务功能；在业务量增长以及由其他业务需求的情况下，平台应设计成具有平滑扩容的能力；
(5)、可维护性：系统提供方便、灵活的维护手段，方便维护人员的维护和管理；
总体设计
整个客户服务中心示意如下：
图形说明：其中黑色的线表示ISDN专线，蓝色的线为网络线。其中CCS/DBProxy/QOS服务器为目前系统的CTI服务器立旧，在CTI服务器上安装3个服务程序（CCS、DBProxy、QOS），考虑到系统的安全与备份，我们在数据加载服务器上同时也安装这3个程序备用（CCS、DBProxy、QOS）在遇到机器故障时可以启用备份系统，详细的系统启用参见系统的使用手册。
主要体现三个部分：敏讯通公司呼叫中心平台部分，用户业务部分，与一卡通后台接口部分。
整个客服系统建立在敏讯通公司呼叫中心平台基础之上，在此平台之上建立所要完成的具体业务。整个客户系统提供客户三种手段来解答一些用户关心的问题，完成一些可以通过这些手段可以实现的业务操作。这三种手段为：
- 自动语音：通过打入呼叫中心电话根据语音提示自动完成，具体能完成的功能请参见自动语音实现部分。
- 座席系统：通过打入呼叫中心电话然后把电话转到话务员，由话务员协助用户解答问题或者完成其所要完成的业务。
- 客服网站：通过用户访问客服网站根据网站的形式完成其业务。
这三种实现业务的方式所实现的具体业务基本相同，只是由于某种具体方式在实现某些业务时可能会存在一定的差别。具体每种方式所实现的具体业务功能请参见需求规定及业务实现部分。
前面所提到整个客服系统建立在敏讯通公司呼叫中心平台基础之上，那么业务系统与平台之间的接口方式如下：
- 平台的座席系统是一个内嵌IE浏览器的模块，因此用户要求实现的业务功能就只要通过WEB方式开发即可与平台实现联接。而其中的座席业务与座席系统的接口就只有一小部分的信息交互，包括座席系统自动进入相关业务功能网页以及座席系统把相关的呼叫信息（如主叫号码等）传给WEB网页形式的业务系统。
- 自动语音部分通过平台脚本语言通过数据库代理访问数据库实现其业务功能。
- 客服网站与平台之间没有接口。不过客服网站和座席业务系统及自动语音部分使用同一套数据表，实现三者的统一。
三种手段的具体实现方式如下：
自动语音：
这一种业务的实现方式通过敏讯通公司的平台提供的脚本语言进行实现，此脚本语言可以通过播放语音文件提示用户按电话机上相应的键，然后系统根据用户的按键进行相应的数据库操作。
座席业务：
这一种业务的实现方式由用户呼入到敏讯通公司平台，然后把电话转接到话务员，然后由话务员利用座席系统访问座席业务系统协助用户完成。
客服网站：
客服网站在整个客服系统中比较独立，与平台之间不存在接口，只是与座席业务和自动语音部分通过共用一套数据表来达到数据的统一。
需求规定
这里仅提供一个需求列表，是基本保留或改进目前系统的现有功能，满足坐席和公司对外的网站需求。
公司网站功能性需求：
公司介绍、使用方法和规则、相关资费、一卡通充值点分布图、使用领域介绍、咨询服务、卡挂失解挂失、用卡查询、意见及反馈、个人购卡登记、集体购卡登记、大额充值登记、新闻栏、产品介绍、广告栏、个人信息修改、邮件系统、网络链接到相关的链接页面。
座席业务系统功能性需求：
业务咨询、余额查询、交易查询、转接用户电话到指定的号码（如：Bus热线、地铁客服、或有关的专家电话）用户投诉、用户建议、个人购卡登记、集体购卡登记、大额充值登记、业务知识管理。
自动语音功能性需求：
听取产品介绍、听取代理代办业务介绍、听取公司介绍、听取使用方法和规则、听取使用领域介绍、听取相关资费、自动卡查询、月票余次查询、充值续费查询、自动用户建议、自动用户投诉。
运行环境
本系统是利用敏讯通公司客户服务平台进行集成，此平台Web服务器系统是运行在Windows2003平台上，其余系统都运行在Windows2000环境下。在此平台基础之上的业务功能用Web方式完成。
平台功能概述
目前一卡通客服系统平台的突出问题主要体现在两个方面：1、系统的设备老化，带来故障率高，增加维护成本。2、应用系统随着业务的拓展和用户的增长，带来平台应用的局限性和功能的不足。
本次改造需要依据两个方面进行，首先要求解决目前系统出现的故障，减少人工对目前系统的维护量，淘汰更新落后的产品和技术，使系统稳定性和功能加强和加大，更大可能的减少日后对系统的维护投资。改善系统平台的设计适应目前的需求从技术上进行更新，满足客服系统的功能提高平台的效率。
电话平台更新设计
采用当前的先进技术，用NGN软交换代替目前的硬排队系统，从传统的以电路交换为主的PSTN网络中逐渐迈向以分组交换为主，它承载了原有PSTN网络的所有业务，把大量的数据传输卸载到IP网络中以减轻PSTN网络的重荷，又以IP技术的新特性增加和增强了许多新老业务。撤除排队机，减掉对目前排队机的维护，基于IP的坐席模式有极大的方便分布式的坐席接入，也去除掉基于排队机的远程模块，同时由于采用IP坐席接入，也省掉目前的坐席的语音专线。节约系统的维护成本，增大了系统的稳定性。同时在语音上增加转接功能，用户电话可以通过坐席或语音流程转接到指定的号码上去，如：李素丽热线，公交热线，地铁投诉电话等，只要需被转接方提供普通电话能呼入的号码就可以进行转接。
业务系统的更新设计
Web系统改造
应用上用Windows2003企业版＋Tomcat 开发环境为JSP，采用网络均载平衡技术，两台Web服务器并行工作，分担网络访问流量，每台服务器的并发访问量初步设计为300左右，在网络带宽的不限条件下能达到600个并发访问，利用集群技术最高能达到8个节点，目前的网路出口带宽为2M，考虑公司网站的页面流量数据为10k左右，正常情况下能支持200个并发量，在架用两个节点WEB服务器，可以满足6M的带宽的网路接入，由于目前公司的网站存在缺陷，无法准确估算出平均的访问量，参照目前门户网站如：sina每天访问量1亿左右，共15个站点，每个站点每秒并发量近200左右，考虑到访问时间的集中，其最大并发数为1000左右的数据，200个并发量能够满足目前一卡通公司的持卡用户为500万的WEB访问需求，同时采用集群架构，可以根据访问量动态调整，随着业务的拓展，网络流量的增加，基于集群的架构能够更好的适应需求，增加带宽或增加服务器，能满足公司的业务需求，同时也起到Web系统的安全性，某台服务器出故障时，不至于这个网站都无法访问，提高了系统的安全和处理性能。本次web改造在功能上，要有网络链接，或在网站的页面中嵌套一些和一卡通公司相关的行业的主页。
数据入库加载模块的改造
目前的卡用户近500万，每天的消费记录（分月票消费，普通卡消费）为近700万，其中月票消费和普通卡消费各将近300万左右，现在的入库平均速度约为180000条每小时，也就是本日的数据不能及时入库，这是有几个原因造成，
- 目前的数据结构设计不合理，普通卡的消费记录和月票卡的消费记录分别为各一个表，对于数据库oracle8i上亿条的数据，很难及时处理过来，
- 数据入库时是分拣入库，对每条数据都是解析后再入库，造成数据库的运算量加大。
- 数据库硬盘设备老化，造成I/O速度下降。
- 对于海量数据服务器的性能是个重要指标。
在本次改造中，首先更改数据库的表结构，为保证平台的平滑过渡，在目前的数据库服务器上新建出个库，供本次平台改造用，在割接完全后，再删除目前的老库。在数据结构上，为普通卡和月票卡的消费记录，每天建一个表，对于普通卡的消费记录保留近3个月的历史数据，月票卡的消费记录保留近1个月的数据。数据的加载程序采用入库时不解析原始数据，根据测试每小时入库量估算为150万，这样能保证每天的消费数据能当天入完库，根据卡的发行量和消费数据比可以满足1000万卡的消费数据当天入完库，能够解决用户的及时查询。
敏讯通
