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萬卡的消費數據當天入完庫，能夠解決用戶的及時查詢。

敏訊通