民生热线服务方案

民声热线服务建设方案

1.服务方案

1.1.系统建设内容

1.1.1.建设方案需求

需求名称

数字中继

IVR

人工坐席

录音系统

定制型业务软件系统

需求内容

PRI信令数字中继

交互式语音应答

IP话机+耳麦

手机APP+网站+PC端

1

10

10

10

1

数量

1.1.2.业务软件要求

分类模块

我要发帖

结果查询

满意度评价

功能名称

我要发帖

结果查询

满意度评价

天气查询

公积金查询

随手拍

便民服务

公共自行车查询

违章查询

PM2.5查询

快递查询

手机版民声手机版结果查询（手机版）

模块

模块

模块

模块

模块

1

1

1

1

1

火车票查询

飞机票查询

单位

模块

模块

模块

模块

模块

模块

模块

数量

1

1

1

1

1

1

1

满意度评价（手机版）

我要发帖（手机版）

民声简介（手机版）

民声发布（手机版）

常见问题（手机版）

结果查询

满意度评价

我要发帖

民声网站民声网站

民声简介

民声发布

常见问题

热线管理来电受理

事件管理

延期申请

审核部门回复

事件查询

知识提交审批

受理热线

转办未查看

后台管理系统

后台管理

转办处理中

已回复/撤销/退回/催办/超时

/办结事件

本人受理事件

知识提交

知识库查询

未接收事件

未处理事件

已处理事件

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

延时事件

已办结事件

事件打印/导出

在线预览

回访记录

流转记录

不满意工单

登录/退出

公告发布

通知公告

公告管理

组织架构

即时通讯

信息框

满意度统计

办结率统计

回复率统计

一次办结统计

每日受理事件

事件总统计

数据分析

各部门承办情况统计

事件类型统计

镇街事件统计

坐席工作量统计

坐席回访量统计

坐席的一次办结率统计

权限维护

系统设置

栏目内容维护

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

模块

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1.2.“随手拍”系统

1.2.1.系统功能介绍

我要发帖

市民通过手机进入随手拍，进入我要发帖界面，选择发帖类型（咨询、投诉、

建议、举报、求助）。

用手机拍照上传图片，写问题描述，描述清楚自己需要发布的信息；设置查

询密码。设置6位字母+数字查填询密码，方便快速查询到自己帖子的回复情况。

填写姓名、等个人信息；点击提交按钮，发帖成功。

结果查询

市民通过帖子编号和查询密码来查询自己的帖子处理情况，结果查询为保密

查询。

满意度评价

市民查看帖子后，可对部门的处理结果进行满意度评价，选择满意、基本满

意或不满意。

便民服务

可进行天气查询、公积金查询、火车票查询、飞机票查询、公共自行车查询、

违章查询、PM2.5查询、快递查询。

1.2.2.流程说明

1.2.3.系统功能

1.2.3.1.网站平台

A.上传人：

上传人在网站平台无操作。

B.管理者

1)待受理信息列表

显示待受理的信息，包括上传人提交的和被处理者退回的信息。

2)已受理信息列表

显示已受理但未处理的信息

3)已处理信息列表

显示已处理的信息

4)信息分类与转发

选择该信息的分类并将信息转发给相应的处理人，信息状态变为已受理，上传人

将不能修改此信息。

如信息为垃圾信息，管理员直接关闭该条信息，此信息将停止流转，状态变成已

处理，处理意见默认为“垃圾信息”。

5)查询统计

可根据处理种类或者处理人查询统计相应的信息量。

6)向上传人下达“月度任务”

管理者通过网站向上传人简要下达月度工作任务，推送至上传人手机客户端，上

传人据此安排月度重点工作，并每月据此填写“工作总结”。

7)设置上传人等级和星级

默认可每周统计一次，通过受理数量区分等级；管理者可手动设置用户的等级。

每月由管理者根据受理数量和月度完成情况评定上传人星级（按五星级评定），

并在网站手动将星级推送至上传人手机客户端显示。

C.处理者

1)本人待处理信息列表

本人未处理的信息列表，可通过信息分类筛选。

2)本人已处理信息列表

本人已处理的信息列表，可通过信息分类筛选。

3)反馈处理结果

如能处理，上传相应的图片、音视频和处理人、处理时间、处理描述的处理结果

提交，信息状态变为已处理；

4)退回无法处理的信息

如不能处理，则填写意见退回到管理员处重新分配，信息状态对于上传人仍是已

受理，但对于管理员是待分配状态，能看到是被退回的和退回原因。

5）任务分解到下一人处理

如需要其他人处理或多人处理，可进行层级分解

D.系统管理员

1)组织机构管理和授权

单位、部门的管理，按模块或人员进行授权管理。

2)上传人用户信息管理

可添加、禁用、修改上传人用户信息及其密码。

包括姓名、性别、头像、手机号（用户名）

3)管理者用户信息管理

可添加、禁用、修改管理者用户信息及其密码。

4)处理者用户信息管理

可添加、禁用、修改处理者用户信息及其密码。

包括姓名、性别、手机号（用户名）、单位、部门信息。

5)信息分类类别维护

维护信息分类的名称，可添加、禁用、修改。

1.2.3.2.手机客户端

A.上传人：

1)用户注册与登录

用户注册需要提供手机号、密码、姓名、性别，以手机号作为唯一验证，可通

过验证码短信验证手机号是否正确

2)首页

a/纯介绍类信息：分为关于随手拍、使用帮助、审核流程说明、。

b/互动信息：在同一个页面显示“月度任务”和“月末总结”两个窗口。

“月度任务”：由管理者编辑下达后，推送至上传者手机客户端，上传者只阅看，

无编辑权限。

“月末总结”：由上传者在手机客户端小窗口编辑，上传至管理者，供管理者评

价。

3)我的信息列表

可通过待受理、已受理、已处理进行筛选；进入页面后先显示全部、待受理、已

受理、已处理三类和相应数量，再次点击后显示信息列表，列表中包含问题标题、

提交时间、受理时间、受理状态。

4)信息上传

内容包括上传时间、相关位置、问题标题、问题描述、语音（1个）、视频（1个）、

图片（6个以内）。

5)设置

包括我的账号、修改密码、退出。我的账号中包括头像、姓名、手机号、性别、

等级、星级等信息，其中：“等级”和“星级”信息由管理者赋值后，推送至上

传者手机客户端显示。

B.管理者

1)用户登录

2)首页

a/纯介绍类信息：分为关于随手拍、使用帮助、审核流程说明、。

b/互动信息：显示个上传人列表，点击每个上传人后，在同一个页面显示“月

度任务”和“月末总结”两个窗口。

“月度任务”：由管理者从网站后台/手机客户端编辑下达后，推送至不同的上传

者手机客户端，上传者只阅看，无编辑权限。

“月末总结”：由上传者在手机客户端小窗口编辑，上传至管理者，供管理者评

价。

3)已受理列表

进入已受理列表后，先出现全部、分类1、分类2等列表，列表后面有相应的信

息总数量和红数字显示新增未读数量，可通过右上方按钮过滤显示全部、待处

理、已处理进行筛选。点击每个分类后进入显示具体的上传信息列表。

4)待受理列表

形式同3），但只显示待受理的信息。

5)设置

包括我的账号、修改密码、退出。我的账号中包括头像、姓名、手机号、性别信

息。

C.处理者

1)用户登录

2)首页

分为关于随手拍、使用帮助、审核流程说明、。都是纯介绍类。

3)本人已处理列表

进入已处理列表后，先出现全部、分类1、分类2等列表，列表后面有相应的信

息总数量和红数字显示新增未读数量，点击每个分类后进入显示具体的上传信

息列表。

4)本人待处理列表

形式同3），只显示待处理信息。

5)设置

包括我的账号、修改密码、退出。我的账号中包括头像、姓名、手机号、性别信

息。

D.系统管理员

系统管理员在手机端无操作。

1.2.4.民声网站（含手机版）

我要发帖(手机版)

为方便市民随时随地都能发帖，电脑端的民声网站和手机端的随手拍都有独

立发帖功能，为方便使用和高效反馈，其功能设计如下：

市民通过网站、手机进入某区民声，选择发帖类型（咨询、投诉、建议、举

报、求助），进入发帖界面。

填写问题标题、问题内容，描述清楚自己需要发布的信息，也可上传图片；

针对自己所提问题选择相关部门。设置6位字母+数字查询密码，方便快速查询

到自己帖子的回复情况。填写姓名、、等个人信息。点击提交

按钮，发帖成功；民声服务平台后台可审核和接收发帖信息，进行处理。

结果查询

市民通过吗密码查询自己帖子处理情况。

满意度评价

市民查看帖子后，可对部门的处理结果进行满意度评价，选择满意、基本满

意或不满意。

民声简介

对民声的基本信息进行介绍。

民声发布

根据实际发布通知、部门公告等文件。

常见问题

各部门可自行维护、更新常见问题知识库

1.2.5.统一后台管理平台

民声热线、声网站（含手机版和随手拍）和政务，三个平台管理系

统整合建设，后台管理数据整合，市民问题统一处理和回复，三个系统管理后台

融合成为统一的后台管理系统，三个系统的数据归属于同一后台管理，单位回复

途径统一化，部门管理规范化。

将已有三个业务系统整合成民声服务平台，硬件资源充分利旧，融合到民声

服务平台物理资源池内，实现业务系统统一运维管理、物理资源统筹调度分配和

信息化建设整体合力。

建设数据资源统一存储与管理系统，具备分布式、可扩展、存储与管理海量

异构数据的能力，将各个业务系统数据资源、政府部门单位信息资源、互联网信

息资源，经清洗、转换、加工、标准化后，加载到统一存储与管理平台。全局信

息资源的统一整合，实现全局视角的信息资源价值发现。

1.2.5.1.民声热线

有的市民不想通过发布帖子的途径来提出诉求，还可以通过拨打民声热线提

出问题或诉求，坐席人员接听电话后，进行来电受理登记，登记下用户基本情况，

包括：姓名、性别、来电电话、（可复制来电）、家庭住址。受理内容：

处理情况、满意度、处理意见、事件备注。并可通过短信方式将相关部门的联系

电话和地址及相应的处理流程推送至众手机上。

1.2.5.2.统一后台管理

为了减少职能部门来回切换系统，充分利用后台资源，提高工作效率，市民

发布的帖子信息与来电内容，统一汇总至同一后台进行回复处理，进行统一后台

管理。

某区政务的数据字段与民声热线和网站及随手拍的帖子信息差异

较大，信息无法汇总统一，将某区政务的来电事件采用“一键复制”

方式录入。信息统一管理后，职能部门无需切换系统，在同一系统内完成接收并

进行处理，其后台管理设计功能如下：

事件管理

市民通过电话、网站反映的内容，信息统一汇总至同一后台，某区政务服务

热线承办单直接导入，能区分信息来源，管理员查看市民的反映内容，初审后通

过平台转交至责任单位处理。审核不通过的，管理人员根据实际情况处置。

延期申请

因特殊原因不能及时处理的事项，责任单位可申请延期，但需管理员审核通

过后。

审核部门回复

管理员查看回复信息，审核回复内容，通过后发布“前台”。审核不通过的，

退回相关部门继续处理。

事件查询

查询模块是整个平台的核心功能，可根据的栏目内容、信息关键字、问题分

类等进行单词组和多词组联合查询，展示不同的内容。

知识提交与审核

审核承办单位和话务人员上传的针对某事件的解决方案及法律法规。

热线受理

市民通过拨打热线提出问题或诉求，座席人员接听电话后，进行来电受理登

记，登记用户基本情况，包括：姓名、性别、来电电话、（可复制来电）、

家庭住址。信息情况：客服工号、受理来源（用户来电等）、内容分类、处理时

限（天）、来电性质。受理内容：是否保密、处理情况、满意度、处理意见、事

件备注。

坐席人员可根据姓名、电话查信息存根打入电话是否有记录，是否问过同

样的问题。可根据座席号、编号、部门、电话、提问时间、来电人反映查看历史

记录和事件答复情况。

转办未查看

提示办理相应事件的部门还未查看的事件。

转办处理中

已经转到相应部门正在处理的事件。

已回复/撤销/退回/催办/超时/办结事件

对事件处理的进度分类显示。

本人受理事件

对座席人员已受理的事件进行统计和查看。

知识库提交

承办单位和话务人员上传事件解决方案及法律法规。

知识库查询

快捷完成知识库的查询。

未接收/未处理/已处理/延时/已办结

系统内分类设置

事件打印/导出

系统内信息内容可导出Excel表格，打印承办单等。

在线预览

民声热线信息内容在线查看，方便职能部门处理。

回访记录

展示事件的回访记录情况。

流转记录

展示事件的流转记录情况。

不满意工单

满意情况以某区政务处理系统为准，可一键覆盖本平台内所有编号

相同的工单。

登录/退出

用户和管理员通过用户名、密码、验证码登录系统，可修改密码、退出系统。

1.2.5.3.数据分析

满意度统计

根据满意度调查结果完成统计。

办结率统计

根据限时内办结数量统计，区分一次、二次、三次、四次及以上。

回复率统计

根据实际回复数量统计。

一次办结统计

根据一次办结数量进行统计。

每日受理事件

对每个坐席人员每日处理的事件进行统计。

事件总统计

对所有事件进行汇总统计和查看。

各部门承办情况统计

对各部门承办的情况进行统计。

按事件类型统计

按事件类型进行分类统计。

座席工作量统计

统计座席的工作量。

座席回访量统计

统计座席的回访量。

1.2.5.4.通知公告

该模块主要包括公告发布和公告管理功能，通过相关权限用户进行公告发布

操作，系统内所设置相关用户均可接收到公告通知，简化线下公告通知繁杂的流

程，提升公告信息发布的效率。

1.2.5.5.即时通讯

各类即时通讯设备已成为日常工作和生活交流的必备工具，但未经安全防护

的即时通讯设备可能会带来风险，安全起见，该模块需要满足工作人员内部沟通

需求（消息浏览和消息管理）。

1.2.5.6.系统设置

权限设置

上级部门可根据需要设置下级部门所能查看的内容。

栏目内容维护

事前维护工单中可点选栏目的内容。

1.3.资源数据库建设

某区民声服务平台数据库的建设。某区民声热线、某区民声网站（含手机版

和随手拍）和政务，通过不同途径获取数据，大量的基础数据整合到同

一后台，需要建设强大的资源数据库来存储和分析基础数据。

以“业务导向”和“数据导向”为出发点，通过资源数据库的建设，解决数

据的存储、管理、共享问题，使分散不规范、难以共享的数据标准化、集中化，

形成数据的快速访问和高效利用。通过云计算、大数据技术来改变传统数据库的

建设思路，最终把某区民声服务平台建设成为具备“物理资源按需分配”、“海量

存储”、“高效检索”、“智能分析”、“可控共享”的应用平台。同时资源数据库的

建设需要保证平台的扩展性、高效性及先进性，为某区民声服务平台打下坚实的

基础。

坚持统一规划，三个系统将在统一规划指导下开展工作，共同规划、统一落

实。

坚持统一标准，统一标准是实现互联互通、资源共享、避免业务条块化、信

息孤岛化的根本前提。

坚持统一建设，避免各层级、各系统之间存在壁垒、互不兼容的情况，实现

系统平台统一设计、统一开发、统一接口，做到上下统一、有效对接，形成完整

统一的平台。

坚持统一平台，建立统一平台是实现业务融合、数据整合、资源共享、协调

同步的重要基础，在统一平台上，才能形成一个完善、规范、可控、高效的信息

化系统建设和业务支撑。

坚持统一管理。统一管理是提高效率、规范操作的重要基础。从树立长远的、

全局的、统一的观点着手，做到统一运维、统一监管，降低运维管理的复杂度和

成本，提高信息化建设成效。

资源数据库规划将以某区政务受理中心基本业务需求为基础，实现

以下建设目标：

（1）全面盘活现有信息资源，解决信息孤岛问题，建立统一的数据资源平

台。

（2）整合各类数据，建立统一的标准规范，为业务决策提供更多视角的可

视化分析，出各类诉求背后的共性、倾向性问题，为领导决策提供更加科学的

参考依据。

1.4.呼叫中心功能描述

呼叫中心业务支撑层介绍

1、综述

为了更加方便、快捷地部署IPT呼叫中心系统，使最终用户通过简单的配置

或少量的编程就能完成整个呼叫中心的实施，我们提供基于CTI技术，实现了呼

叫中心控制的很多高级功能，如：IVR（自动语音应答），ACD（人工座席排队），

REC（数字录音），Conf（语音会议），FAX（传真），DB（数据库），E-mail（邮

件），SMS（短信），TTS（文本转语音），信息到达提醒，知识库，工单生成/

流转，座席监管，黑红名单，排班表，数据统计，报表生成等功能，中间件还向

应用层（系统集成、应用开发商）提供标准的开发程序接口，方便第三方厂商开

发各种具体应用。其具有强大的灵活性和可扩展性，同时这些所有组件功能都集

成与一个硬件设备中，为呼叫中心稳定运行提供了可靠的软件平台，并广泛适用

于各种行业的呼叫中心的建设，有效降低了呼叫中心的建设和维护难度。

2、IPT呼叫中心中间件的基本组成

自动语音应答系统（IVR）；

智能话务排队系统（ACD）；

通用座席接口（AGET）；

座席全程录音系统（REC）；

统计报表系统（REPORT）；

座席监管系统等；(MAAGER)

知识库系统；(KBS)

工单生成；(WORKFLOW)选配

自动外呼系统；(OUTBOUD)选配

黑/红名单系统；(BRL)

3、呼叫中心中间件协同工作流程

呼叫中心的系统运行过程中，为了使系统运行效率达到最佳状态，及时处理

各种事件，中间件中的各部件是紧密结合，相互协调工作的。

首先，座席工作人员启动座席应用程序，通用座席接口（AGET）即将该座

席的状态以及座席信息等告知智能话务排队系统（ACD）,自动排队系统将座席的

这些信息保存并实时维护这些信息。

当一个来自PST或WEB的呼叫进入呼叫中心时，自动语音应答系统（IVR）

首先应答该来话并获取来话信息（主叫号码），甚至可以向该用户播放语音提示

音收集用户的相关资料，同时通知ACD有一个来电要转移到座席并把来电的相

关信息一起送给ACD，ACD根据有关信息（排队策略）去查一个最适合的空闲

座席，如果到相应的座席，则将该座席的分机号码告诉IVR，IVR将来电转移

到分机，由座席继续为该来电服务，直至通话结束。如果没有合适的座席，IVR

将对来话播放等待音乐或提示“没有空闲座席”，用户可选择是否继续等待，如

果用户继续等待，则ACD将该来话纳入排队队列，一旦有合适的空闲座席，V_IVR

将收到来自ACD的通知，此时IVR即可将来话转到对应座席。

呼叫中心中间件各功能组件介绍

1.4.2.1.自动语音应答系统(IVR)

我们提供的IVR系统是动态的，应用设计人员可以很轻松的修改语音流程。

我们提供了一种直观的图形化编辑工具----自动业务流程编辑器（下图），客户

可在应用编成器里自行设计自己的语音应答流程，设计人员只须将语音流程的步

骤组件从组件面板中拖放到主设计窗口，设置相应的属性即可。修改后，一个叫

做应用引擎的流程实施工具将加载以文件形式存储的语音流程文件。

如给IVR服务器配备传真卡，IVR还可实现对客户传真访问响应，通过自动

业务流程生成器还可实现传真自动外拨服务，并且，IVR支持对任何关系型数据

库的访问和文本到语音的转换（TTS）技术。

主设计窗

组件面板

1.4.2.2.智能话务排队系统（ACD）

ACD也是呼叫中心中间中的一个重要组成部分，它也是一个纯软件的产品，

它运行于一台独立服务器上，对所有的座席进行实时监控、对来话进行智能排队，

为了让每一个访问的客户都能得到恰当的服务，需要按不同的策略分配话务至座

席，对呼叫中心内部的所有具备接待能力的座席进行分组、排队，每次从队列中

选出队首，分配给当前呼叫用户。

目前，系统提供多种座席排队策略，比如，将所有座席按照空闲时间长短进

行排队，每次选择空闲时间最长的座席来接待当前的来话，或者按工作强度、技

能等级的顺序进行分配，并可依据用户需求订制特殊排队策略。

1.4.2.3.通用座席应用示例（AGET）

AGET是中间件产品中的座席应用接口模块，它是连接客户具体应用程序与

中间件其它产品的纽带。通过AGET，系统集成应用开发商在开发座席应用程序

过程中无须投入太多的精力来实现复杂的座席端电话功能，可以把精力集中在具

体应用上，这样能大大缩短开发的时间。

图标说明：

状态条

操作条

客户信息记录

分机号

置闲：表示座席员现在的状态可以正常接电话，这时如有电话会分配到

该座席。

置忙：表示座席员现在正在接电话或处理别的事情，这时电话不会不会

被分配到该座席。

离席：表是座席员暂时不在作为上。

摘机：如有电话进来，按此键表示将电话接起来以进行通话。

挂机：当结束一个电话时，按此键挂断电话。

外拨：往外拨电话。

外拨分机：如果往外打电话，而对方需要输入分机号等按键提示时，按

此键。

呼叫转移：接到一个电话后转给其他的座席。

保持：在与某个客户进行通话时，选此键后则客户听到背景音乐，而听不

见座席员的声音。

释放：选此键后则客户有可以与座席员正常对话。

1、登陆

（1）双击及运行桌面的快捷方式TelControl；弹开状态条；

（2）在左侧的红箭头处点右键，选“座席注册”，在弹开的登陆界面上输入用

户名和密码（通过E-mail方式告知），点确定登陆。

（3）在左侧的红箭头处点右键，选“修改密码”，在弹开的修改密码界面上输

入用新的密码和确认密码（最长为10位），点确定后下次登陆时新密码生效。

（4）在左侧的红箭头处点右键，选“座席复位”，可以在座席工具条的状态非

正常时重新使状态条的工作状态恢复初试状态，从而继续正常工作。

（5）登陆后状态条最上方兰区域会显示出该座席员的工号和姓名，以及最近

来电人的电话、联系人、处理电话的次数。右册的小框则显示时间和该分机的号

码。

（6）刚登陆后系统会自动默认为空闲状态，这时如果有客户打电话进来，服务

器会将电话分配给该座席。

2、接电话

（1）当有电话呼入的时候，状态条如下，选“摘机”键可以接听。该人的电话

号码在上方兰条框会显示出来点号码，如果以前该人已经来过电并做过记录，

还会显示出该人的姓名。

（2）摘机后，则可以和客户进行通话，兰状态条会显示通话时间。当摘机后，

该座席被标记为置忙状态，再有电话近来服务器则不会分配给该座席。

（3）点开左侧的红箭头，显示客户信息记录条，如果该客户已经做过记录，则

会显示出该用户的记录，可以点修改或删除对该用户信息进行操作。如果该用户

未被登记，则先按“新建”键，然后可以在该栏下进行信息登记，登记后选保存

即可。

（4）当结束一个通话后，可以按“挂断”挂断电话。

挂断键

（5）当一个电话被挂断后，该座席默认为置忙状态，因为在刚挂断电话后，座

席员可能会做一些录入之类的操作，因此，需要座席手动点一下“置闲键”以确

认自己可以接下一个电话。

置

3、转移电话

置闲键

（1）当接到一个电话需要转给其他座席人员，点一下转移键，会弹开转移窗口；

转移

（2）在弹开的窗口下输入要转移的分机或从列表中选择座席，按确定键，这时

将拨通对方的电话。

4、外拨电话

（1）先按“置忙键”，将座席状态变为“忙”；

置忙

（2）在“置忙”状态下点“外拨”键，在弹开的窗口输入分机号码，然后按确

定；

外拨

高级外

（3）在外拨电话窗口点“高级拨号”键，在弹出的窗口中进行高级的用户号码

查，选定用户进行外拨。

（4）拨通后如果需要再次输入分机号码或双音频键，则选“拨双音频键”，在弹

开的窗口下输入双音频即可；

拨双音

通用状态条由

网音提供

电话控制区

应用数据查询区

1.4.2.4.座席全程录音系统（REC）

录音模块REC可以对座席实行全程纯软件录音方式，所有录音记录由录音服

务器（班长席）集中管理，在录音服务器上可进行录音记录的查询、回放等，同

时也可实现对座席的进行实时监听。IPT呼叫中心系统不需采用任何语音板卡，

这样既降低了硬件投资成本，省去了录音布线的麻烦与多故障根源，也大大提高

了录音系统与呼叫中心的整合程度，提高了监控水平。这是国内第一套纯软件的

录音实现方案，充分体现了IP呼叫中心系统的优势。

主要优势：

纯软件，无须数字信号处理（DSP）卡，无须部署任何语音线路，从根本

上避免了传统录音解决方案中由于录音线路松动而造成的无效录音记录

等故障，同时解决了语音板卡普遍存在录音有所失真的现象；

分散式录音、集中式管理模式，避免了传统录音解决方案的集中式录音

由于录音服务器发生故障，而导致录音系统整个瘫痪的状况；

支持IP应用环境，录音服务器可置于IP网络的任何地点；

支持多个录音站、多个录音查询站；

1.4.2.5.统计报表系统（REPORT）

REPORT支持各种统计报表输出，直观地反映出呼叫中心各个时间段内的各

种环节的具体运营情况，帮助管理人员进行决策。REPORT支持多种统计方式如：

IVR呼叫总量统计、平均座席服务时间统计、线路占用时间统计、座席话务量统

计、呼叫损失量统计、接通率统计，排队占用时间统计等，另外REPORT还支持

用户自行定义的统计模式。

数据统计管理系统在新的版本中做了很大的改动和完善，以下列出了一些功

能特点：

统计结果的体现形式灵活多样

系统将统计结果自动导入到Excel表格中，用户可以方便灵活地生成各种

图表

1.4.2.6.座席监管系统(MAAGER)

IPT呼叫中心提供了对系统各个部件的全面监视能力，提供了针对座席的多

种媒体的全面质检能力，包括：

提供了对各个核心部件的监视能力，可以查看系统的各个资源的占用，

直观查看各个部件的运行状况，收集各种运行参数。

提供传统的质检，如强制置忙、强制置闲、强制插入功能，以及多种媒

体的全面拦截功能。

提供班长对座席的录制、回放功能。

提供针对多种媒体的监视、监听、录制功能，能够进行多种媒体的同步

回放。提供按业务类型对呼叫进行监听的功能。

1.5.安装测试方案

从广泛意义上讲，安装、测试需要经过以下列性能测试，包括：压力测

试、稳定性测试、负载能力测试和可扩展性测试等。在不同应用系统的性能测

试中，需要根据应用系统的特点和测试目的的不同来选择具体的测试方法。

在性能测试中，压力测试主要是为了获取系统在较大压力状况下的性能表

现而设计并实现的，压力测试主要是获取系统的性能瓶颈和系统的最大吞吐

率。稳定性测试主要是测试系统的稳定性，即在不同情况下，系统仍能够正常

运行。负载测试是测试系统的承受能力，测试其在大量并发情况下的运行情

况。而可扩展性测试指的是系统的扩展能力，即本系统跟其他系统直接的交互

对接能力以及本系统功能、性能等方面的扩展能力。

1.5.1.衡量系统性能的常见指标

一般来说，性能是一种指标，表明软件系统或构件对于其及时性要求的符

合程度；其次，性能是软件产品的一种特性，可以用时间来进行度量。

软件系统常见的性能指标如下：

➢响应时间（Responsetime）

响应时间就是用户感受软件系统为其服务所耗费的时间，对于网站系统来

说，响应时间就是从点击了一个页面计时开始，到这个页面完全在浏览器里展

现计时结束的这一段时间间隔，看起来很简单，但其实在这段响应时间内，软

件系统在幕后经过了一系列的处理工作，贯穿了整个系统节点。根据“管辖区

域”不同，响应时间可以细分为：

（1）服务器端响应时间，这个时间指的是服务器完成交易请求执行的时

间，不包括用户端到服务器端的反应（请求和耗费在网络上的通信时间），这个

服务器端响应时间可以度量服务器的处理能力。

（2）网络响应时间，这是网络硬件传输交易请求和交易结果所耗费的时

间。

（3）用户端响应时间，这是用户端在构建请求和展现交易结果时所耗费的

时间，对于普通的瘦用户端Web应用来说，这个时间很短，通常可以忽略不

计；但是对于胖用户端Web应用来说，比如Javaapplet、AJAX，由于用户端

内嵌了大量的逻辑处理，耗费的时间有可能很长，从而成为系统的瓶颈，这是

要注意的一个地方。

那么用户感受的响应时间其实是等于用户端响应时间+服务器端响应时间+

网络响应时间。细分的目的是为了方便定位性能瓶颈出现在哪个节点上。

➢吞吐量（Throughput）

吞吐量是常见的一个软件性能指标，对于软件系统来说，“吞”进去的是请

求，“吐”出来的是结果，而吞吐量反映的就是软件系统的“饭量”，也就是系

统的处理能力，具体说来，就是指软件系统在每单位时间内能处理多少个事务/

请求/单位数据等。但它的定义比较灵活，在不同的场景下有不同的诠释，比如

数据库的吞吐量指的是单位时间内，不同SQL语句的执行数量；而网络的吞吐

量指的是单位时间内在网络上传输的数据流量。吞吐量的大小由负载（如用户

的数量）或行为方式来决定。举个例子，下载文件比浏览网页需要更高的网络

吞吐量。

➢资源使用率（Resourceutilization）

常见的资源有：CPU占用率、内存使用率、磁盘I/O、网络I/O。

➢点击数（Hitspersecond）

点击数是衡量WebServer处理能力的一个很有用的指标。需要明确的是：

点击数不是我方通常理解的用户鼠标点击次数，而是按照用户端向WebServer

发起了多少次http请求计算的，一次鼠标可能触发多个http请求，这需要结

合具体的Web系统实现来计算。

➢并发用户数（Concurrentusers）

并发用户数用来度量服务器并发容量和同步协调能力。在用户端指一批用

户同时执行一个操作。并发数反映了软件系统的并发处理能力，和吞吐量不同

的是，它大多是占用套接字、句柄等操作系统资源。

另外，度量软件系统的性能指标还有系统恢复时间等，其实凡是用户有关

资源和时间的要求都可以被视作性能指标，都可以作为软件系统的度量，而性

能测试就是为了验证这些性能指标是否被满足。

1.5.2.软件性能的不同层面

通常，对软件性能的关注是多个层面的：用户关注软件性能，管理员关注

软件性能，产品的开发人员也关注软件性能，这些不同的关注者所关注的“性

能”的具体内容也是不同的。因此，对于不同的人，软件的性能标准也是不

同的，需要做不同的应对。

➢用户视角的软件性能

从用户的角度来说，软件性能就是软件对用户操作的响应时间。说得更明

确一点，对用户来说，当用户单击一个按钮、发出一条指令或是在Web页面上

单击一个链接，从用户单击开始到应用系统把本次操作的结果以用户能察觉的

方式展示出来，这个过程所消耗的时间就是用户对软件性能的直观印象。下图

以一个Web系统为例，说明了用户的这种印象。

图WEB系统的响应

必须要说明的是，用户所体会到的“响应时间”既有客观的成分，也有主

观的成分。例如，用户执行了某个操作，该操作返回大量数据，从客观的角度

来说，事务的结束应该是系统返回所有的数据，响应时间应该是从用户操作开

始到所有数据返回完成的整个耗时；但从用户的主观感知来说，如果采用一种

优化的数据呈现策略，当少部分数据返回之后就立刻将数据呈现在用户面前，

则用户感受到的响应时间就会远远小于实际的事务响应时间。

➢管理员视角的软件性能

从管理员的角度来看，软件系统的性能首先表现在系统的响应时间上，这

一点和用户视角是一样的。但管理员是一种特殊的用户，和一般用户相比，除

了会关注一般用户的体验之外，他还会关心和系统状态相关的信息。例如，管

理员已经知道，在并发用户数为100时，A业务的响应时间为8秒，那么此时

的系统状态如何呢？服务器的CPU使用是不是已经达到了最大值？是否还有可

用的内存？应用服务器的状态如何？我方设置的JVM可用内存是否足够？数据

库的状况如何？是否还需要进行一些调整？这些问题普通的用户并不关心，因

为这不在他们的体验范围之内；但对管理员来说，要保证系统的稳定运行和持

续的良好性能，就必须关心这些问题。

另一方面，管理员还会想要知道系统具有多大的可扩展性，处理并发的能

力如何；而且，管理员还会希望知道系统可能的最大容量是什么，系统可能的

性能瓶颈在哪里，通过更换哪些设备或是进行哪些扩展能够提高系统性能，了

解这些情况，管理员才能根据系统的用户状况制定管理措施，在系统出现计划

之外的用户增长等紧急情况的时候能够立即制定相应措施，进行迅速的处理；

此外，管理员可能还会关心系统在长时间的运行中是否足够稳定，是否能够不

间断地提供业务服务等。

因此，从管理员的视角来看，软件性能绝对不仅仅是应用的响应时间这么

一个简单的问题。

下表给出了管理员关注的部分性能相关问题的列表。

管理员关心的问题

服务器的资源使用状况合理吗

应用服务器和数据库的资源使用状况合理吗

系统是否能够实现扩展

系统最多能支持多少用户的访问？系统最大的业

务处理量是多少

系统性能可能的瓶颈在哪里

更换哪些设备能够提高系统性能

系统能否支持7×24小时的业务访问

➢开发视角的软件性能

从开发人员的角度来说，对软件性能的关注就更加深入了。开发人员会关

心主要的用户感受——响应时间，因为这毕竟是用户的直接体验；另外，开发

人员也会关心系统的扩展性等管理员关心的内容，因为这些也是产品需要面向

的用户（特殊的用户）。但对开发人员来说，其最想知道的是“如何通过调整设

计和代码实现，或是如何通过调整系统设置等方法提高软件的性能表现”，和

软件性能描述

资源利用率

资源利用率

系统可扩展性

系统容量

系统可扩展性

系统可扩展性

系统稳定性

“如何发现并解决软件设计和开发过程中产生的由于多用户访问引起的缺陷”，

因此，其最关注的是使性能表现不佳的因素和由于大量用户访问引发的软件故

障，也就是我方通常所说的“性能瓶颈”和系统中存在的在大量用户访问时表

现出来的缺陷。

举例来说，对于一个没有达到预期性能规划的应用，开发人员最想知道的

是，这个糟糕的性能表现究竟是由于系统架构选择的不合理还是由于代码实现

的问题引起？由于数据库设计的问题引起？抑或是由于系统的运行环境引发？

或者，对于一个即将发布到现场给用户使用的应用，开发人员可能会想要

知道当大量用户访问这个系统时，系统会不会出现某些故障，例如，是否存在

由于资源竞争引起的挂起？是否存在由于内存处理等问题引起的系统故障？

因此，对开发人员来说，单纯获知系统性能“好”或者“不好”的评价并

没有太大的意义，他们更想知道的是“哪些地方是引起不好的性能表现的根

源”或是“哪里可能存在故障发生的可能”。

下表给出了开发人员关注的部分性能相关问题的列表。

开发人员关心的问题

架构设计是否合理

数据库设计是否存在问题

代码是否存在性能方面的问题

系统中是否有不合理的内存使用方式

系统中是否存在不合理的线程同步方式

系统中是否存在不合理的资源竞争

问题所属层次

系统架构

数据库设计

代码

代码

设计与代码

设计与代码

1.5.3.系统测试目标

通过对定制系统进行单元测试、与业务系统组合后的系统测试以及用户现

场业务模拟测试三个阶段，对功能正确性、可靠性、易用性、安全性、系统性

能等进行测试，为潍坊市某区委宣传部民生热线服务系统顺利上线并运行、后

期维护提供可靠、安全的质量保障。

1.5.4.系统测试流程

1.5.5.系统应用测试

1.5.5.1.功能测试

功能测试主要在单元集成测试阶段完成，目的是确保测试的功能正常，如

数据输入，处理、查询是否正确，以及业务规则是否恰当。即对交互的输出或

结果进行分析，以此来核实系统所涉及到的各模块的工作正常。

1、测试目标

单元测试完成，确保为潍坊市某区委宣传部民生热线服务系统定制开发系

统各功能及业务流程正常等。

2、测试方法及要点

整体各功能点测试基于黑盒方法，通过图形用户界面与应用程序交互并分

析输出结果来验证应用程序及其内部进程。利用有效的和无效的数据执行各用

例、用例流或功能，核实以下内容：

➢在使用有效数据时得到预期的结果。

➢在使用无效数据时显示相应的错误消息或警告消息。

➢各业务规则都得到了正确的应用。

3、完成标准

➢所计划的测试已全部执行。

➢所发现的缺陷已全部解决或遗留的缺陷给出解决方案。

1.5.5.2.接口测试

用于验证潍坊市某区委宣传部民生热线服务系统与其他业务系统间的交互

是否正常，确保本系统与其他系统数据传递的正确性。

1、测试目标

验证本管理平台内部模块之间以及跟其他业务系统间数据传递的正确性。

2、测试方法及要点

通过该管理平台传递到其他业务系统中的数据，验证功能及数据正确性。

通过其他业务系统传递到该管理平台中，验证数据传递及回写正确性。

3、完成标准

各接口数据传递正确。

1.5.5.3.易用性测试

验证各功能用户操作体验及易用性，确保各种浏览以及各种访问方法（鼠

标移动、快捷键等）都使用正常，确保窗口对象及其特征（菜单、大小、位

置、状态和中心），各功能说明及提示信息都符合标准。

1、测试目标

验证潍坊市某区委宣传部民生热线服务系统是否符合《我方软件产品易用

性规范及指南》，主要包括页面大小是否合适，布局是否合理，颜搭配是否易

于接受，链接功能是否正常，提示信息正确、易理解。

2、测试方法及要点

测试人员依据《我方软件产品易用性规范及指南》对定制系统各功能点逐

一验证。

3、完成标准

确保各功能窗口都达到需求，符合《我方软件产品易用性规范及指南》。

1.5.5.4.性能测试

主要验证定制开发系统对响应时间、事务处理速率和其他与时间相关的需

求进行评测和评估。性能评测的目标是核实性能需求都已满足。

1、测试目标

验证定制开发系统常用、重点业务功能在以下情况下的性能行为：

➢正常的预期工作量。

➢预期的最繁重工作量。

➢测试用户对服务器访问的反应时间。

➢大数据量的各功能的单点性能测试。

2、测试方法及要点

➢通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事务的迭代次

数。

➢脚本应该在一台计算机上运行（最好是以单个用户、单个事务为基准），并在多

台用户机（虚拟的或实际的用户机，请参见下面的“需考虑的特殊事项”）上重

复。

➢通过创建“虚拟的”用户负载来模拟许多个（通常为数百个）用户机。

➢使用多台实际用户机（每台用户机都运行测试脚本）在系统上添加负载。

3、完成标准

➢单个事务或单个用户：在每个事务所预期或要求的时间范围内成功地完成测试

脚本，没有发生任何故障。

➢多个事务或多个用户：在可接受的时间范围内成功地完成测试脚本，没有发生

任何故障。

1.5.5.5.压力测试

从负载测试，强力测试以及压力测试等方面，测试定制开发系统在给定时

间内能够持续处理的最大负载或工作量（包括长时间处理多个用户相同的且性

能最坏的业务）；确定并确保系统在超出最大预期工作量的情况下仍能正常运

行，并评估其性能特征，包括响应时间、事务处理速率和其他与时间相关的内

容。

1、测试目标

测试定制开发系统正常工作时，能够承受的最大并发用户达到潍坊市某区

委宣传部民生热线服务系统要求的并发数量，且系统能够正常工作。

➢正常的预期工作量。

➢预期的最繁重工作量。

➢测试用户对服务器访问的反应时间。

➢大数据量的各功能的单点性能测试。

2、测试方法及要点

➢用脚本模拟并发用户数量，同时对系统进行访问，逐步增大模拟的用户数，测

试直到系统出现故障为止。

➢在潍坊市某区委宣传部民生热线服务系统要求的并发用户数量下，测试服务器

能够正常运行的时间。

➢减少或限制服务器的内存，增加并发用户数量。

3、完成标准

➢达到潍坊市某区委宣传部民生热线服务系统所要求的并发用户数时，定制开发

系统运行正常，服务器不会出现故障，可以正常工作，检查其性能指标是否符

合要求。

1.5.5.6.安全保密测试

确保定制开发系统的安全性，各人员权限控制正确，并确认系统是否有超

时的限制，相关的重要信息是否写进日志、是否可追踪，测试加密是否正确，

信息是否完整。

➢系统认证鉴别管理

1、测试目标

通过系统认证鉴别管理测试，检查定制开发系统是否符合认证方式、口令

复杂度、登录失败控制、空闲重鉴别控制以及密码定期更换控制等安全保密要

求。

2、测试方法及要点

➢系统登录认证方式选择，复杂口令录入设置，以及登录重鉴别控制设置等。根

据设置的认证方式进行登录检查，验证口令是否符合安全保密要求。

➢系统需具有基本的“账号/密码”验证方式。

➢用户设置密码时，系统强制位数要达到机关事务管理局要求，且需是复杂组合

（即大小写英文字母、数字、特殊字符三种字符中的两者以上组合而成）的密

码。

➢登录密码强制要求规定时间内至少修改一次，如不修改密码则不允许访问其它

功能。可以设置修改密码不能重复的次数。

➢登录密码在存储和传输过程中都以加密方式存在。

➢用户身份鉴别成功后，当其空闲操作的时间超过规定值（通常为10分钟）后，

本系统会要求对该用户重新进行身份鉴别。

➢当用户身份鉴别尝试连续五次失败时，本系统会对该账号实行冻结，再由专门

的系统管理员进行解冻。如身份鉴别成功，则重新进行次数累计。

➢安全保密员能够为指定的账号重置登录密码，任何人都无法查阅登录密码的原

文。

3、完成标准

以上测试要点实现并控制正确。

➢安全审计日志管理

1、测试目标

通过安全审计日志测试，检查定制开发系统是否具有完整、可追溯的日志

记录，保障系统的安全可靠。

2、测试方法及要点

安全审计员可以通过日志审计功能根据授权查看相应的操作记录。

1）系统具有完整、可追溯的日志记录：

➢每条日志记录都按照时间顺序编制顺序号，从而保证完整性。

➢在日志中记录各种相关信息以保证其可追溯性。

➢人员信息：操作人员的账号；所使用的机器的IP地址。

➢时间信息：操作发生的日期和时间。

➢操作内容：所访问的功能模块，具体的功能点，必要时还要记录所操作的具体

内容（比如创建账号的操作，就要记录所创建的是哪个账号）。

2）应在日志中进行记录的事项包括：

➢使用人员进入、退出系统。

➢使用人员在系统中进行的各项操作（增、删、改、查等等）。

3）对系统日志中诸如人员、日期、时间、IP地址、功能模块、操作内容

等等的分类检索、排序、数据输出等。支持以下查询条件以及“逻辑与”组

合：

➢日期和时间范围。

➢所操作的功能模块名称。

➢操作的类型名称。

4）系统日志的管理同样受制于系统权限控制，除安全审计员以外，其他用

户不能访问日志信息。

5）安全审计员可以对系统日志进行审计，并可以将日志以XLS文件形式导

出。安全审计员不能进行其他与日志无关的操作。

3、完成标准

以上测试要点实现并控制正确。

➢关键信息防篡改

1、测试目标

定制开发系统涉密信息在传输、存储过程中的可靠性。

2、测试方法及要点

➢涉密信息传输过程中以密文传输，存储在数据库以密文存储并不允许非法篡改

➢数据传输防篡改。

➢数据库（存储）防篡改。

3、完成标准

以上测试要点实现并控制正确。

1.5.5.7.故障恢复测试

确保系统能从各种意外数据损失或完整性破坏的各种软/硬件故障中恢复包

括：用户/服务机断电，网络通信中断，异常关闭某个功能，错误的操作顺序

1、测试目标

➢确保恢复进程（手工或自动）将数据库、应用程序和系统正确地恢复到了预期

的已知状态。测试中将包括以下各种情况：

➢用户机断电。

➢服务器断电。

➢通过网络服务器产生的通信中断。

➢周期未完成（数据过滤进程被中断，数据同步进程被中断）。

➢数据库指针或关键字无效。

➢数据库中的数据元素无效或遭到破坏。

2、测试方法及要点

➢用户机断电：关闭PC的电源。

➢服务器断电：模拟或启动服务器的断电过程。

➢通过网络服务器产生的中断：模拟或启动网络的通信中断（实际断开通信线路

的连接或关闭网络服务器或路由器的电源）。

➢一旦实现了上述情况（或模拟情况），就应该执行其他事务。而且一旦达到第二

个测试点状态，就应调用恢复过程。

➢在测试不完整的周期时，所使用的方法与上述方法相同，只不过应异常终止或

提前终止数据库进程本身。

➢对以下情况的测试需要达到一个已知的数据库状态。当破坏若干个数据库字

段、指针和关键字时，应该以手工方式在数据库中（通过数据库工具）直接进

行。其他事务应该通过使用“应用程序功能测试”和“业务周期测试”中的测

试来执行，并且应执行完整的周期。

3、完成标准

在所有上述情况中，应用程序、数据库和系统应该在恢复过程完成时立即

返回到一个已知的预期状态。

1.5.5.8.配置和兼容性测试

1、测试目标

测试该系统可在潍坊市某区委宣传部民生热线服务系统项目要求的硬件和

软件配置中正常运行。在各种浏览器下工作正常。

2、测试方法及要点

➢在测试过程中或在测试开始之前，打开各种与非测试对象相关的软件（例如

Microsoft应用程序：Excel和Word），然后将其关闭。

➢执行所选的事务，以模拟主角与测试对象软件和非测试对象软件之间的交互。

➢用户端操作系统，系统软件兼容性测试。

3、完成标准

对于测试对象软件和非测试对象软件的各种组合，所有事务都成功完成，

没有出现任何故障。

1.5.5.9.系统集成测试

1、测试目标

集成测试的主要目标是检测潍坊市某区委宣传部民生热线服务系统所涉及

的应用支撑平台、定制开发系统的集成是否达到要求，对业务流程及数据流的

是否可以平滑处理，检测各个系统之间业务流处理是否存在逻辑不严谨及错

误，并对全部功能进行回归测试。

2、测试方法及要点

利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内

容：

➢在使用有效数据时得到预期的结果。

➢在使用无效数据时显示相应的错误消息或警告消息。

➢各业务规则都得到了正确的应用。

➢各系统直接数据流传递正确。

3、完成标准

潍坊市某区委宣传部民生热线服务系统可以稳定运行。

1.5.6.业务模拟测试

1.5.6.1.业务模拟测试流程

图业务模拟测试流程

1.5.6.2.业务模拟测试组织

图业务模拟测试组织

1.5.6.3.业务模拟测试过程

测试经理与项目经理、实施经理沟通制定业务模拟测试计划、确定业务模

拟测试环境。

测试人员、实施人员依据项目实施方案，以用户基础数据、业务表单、业

务操作流程，形成本次业务模拟测试用例集，并提交用户确认。

测试执行：由测试人员、实施人员、用户代表组成测试团队按业务模拟测

试计划，依据业务模拟测试用例集验证我方平台产品与定制开发系统满足项目

实施方案。

业务模拟测试发现的缺陷，必须24小时响应解决。

测试结果统计：测试经理依据项目要求，按时汇总、分析业务模拟测试情

况，编制业务模拟测试进展报告及最终的业务模拟测试报告。

业务模拟测试完成，系统可以上线试运行。