北京市政交通一卡通客户服务中心概要设计

1. 自动语音：通过打入呼叫中心电话根据语音提示自动完成，具体能完成的功能请参见自动语音实现部分。
   
   
2. 座席系统：通过打入呼叫中心电话然后把电话转到话务员，由话务员协助用户解答问题或者完成其所要完成的业务。
   
   
3. 客服网站：通过用户访问客服网站根据网站的形式完成其业务。

1. 平台的座席系统是一个内嵌IE浏览器的模块，因此用户要求实现的业务功能就只要通过WEB方式开发即可与平台实现联接。而其中的座席业务与座席系统的接口就只有一小部分的信息交互，包括座席系统自动进入相关业务功能网页以及座席系统把相关的呼叫信息（如主叫号码等）传给WEB网页形式的业务系统。
   
   
2. 自动语音部分通过平台脚本语言通过数据库代理访问数据库实现其业务功能。
   
   
3. 客服网站与平台之间没有接口。不过客服网站和座席业务系统及自动语音部分使用同一套数据表，实现三者的统一。

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

　　自动语音：

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

　　座席业务：

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

　　客服网站：

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

需求规定

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

　　公司网站功能性需求：

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

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

　　业务咨询、余额查询、交易查询、转接用户电话到指定的号码（如：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条每小时，也就是本日的数据不能及时入库，这是有几个原因造成，

1. 目前的数据结构设计不合理，普通卡的消费记录和月票卡的消费记录分别为各一个表，对于数据库oracle8i上亿条的数据，很难及时处理过来，
2. 数据入库时是分拣入库，对每条数据都是解析后再入库，造成数据库的运算量加大。
3. 数据库硬盘设备老化，造成I/O速度下降。
4. 对于海量数据服务器的性能是个重要指标。

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

敏讯通