投诉业务系统需求规格说明书
- 格式:docx
- 大小:406.31 KB
- 文档页数:16
文档操作历史xxx项目需求分析说明书部门: ________________________编写人: ________________________核准人: ________________________日期: _____年______月_______日阅读对象本文档的阅读对象包括:● 客户(客户方项目负责人及项目成员)● 总监/副总监● PMO● PM、PD、PO● 项目组成员目录xxx项目需求分析说明书 1阅读对象 21 概述 31.1 需求背景 31.1.1 需求概述 31.1.2 需求方 31.2 项目预期收益 31.3 需求风险 32 功能说明 42.1 功能列表 42.2 功能结构图 42.3 功能说明 42.3.1 功能1 42.4 系统接口列表(可选) 53 非功能性需求说明(可选) 64 运营计划 61 概述1.1 需求背景1.1.1 需求概述1.1.2 需求方需求方:此处填写部门名称接口人:此处填写部门接口人1.2 项目预期收益1.3 需求风险2 功能说明2.1 功能列表2.2 功能结构图2.3 功能说明2.3.1 功能12.3.1.1 简要说明2.3.1.2 业务规则2.3.1.3 执行角色2.3.1.4 权限管理2.3.1.5 功能用例图2.3.1.6 功能流程图2.3.1.7 功能序列图2.3.1.8 界面原型(线框图)2.3.1.9 操作规则说明:2.3.1.10 前置条件2.3.1.11 后置条件2.4 系统接口列表(可选)根据业务方的需求填写可预见的内部/外部接口,供设计参考3 非功能性需求说明(可选)4 运营计划5 上下线需求5.1 上线时限5.2 下线需求。
《需求规格说明书》编写参考指南1.概述(Summary)本文档是进行项目策划、概要设计和详细设计的基础,也是软件企业测试部门进行内部验收测试的依据。
1.1 用户简介(User Synopsis)在本章节中要将用户的基本情况描述清楚,以便于分析人员划定系统范围,进行功能、进度、成本、性能等方面的平衡决策。
对于产品开发类项目,需要在此将该产品定义的用户群的特点描述清楚。
1.2 项目的目的与目标(Purpose and Aim of Project)项目的目的是对开发本系统的意图的总概括。
项目的目标是将目的细化后的具体描述。
项目目标应是明确的、可度量的、可以达到的, 项目的范围应能确保项目的目标可以达到。
对于项目的目标可以逐步细化,以便与系统的需求建立对应关系,检查系统的功能是否覆盖了系统的目标。
1.3 术语定义(Terms Glossary)将该需求规格说明书中的术语、缩写进行定义, 包括用户应用领域与计算机领域的术语与缩写等。
1.4 参考资料(References)说明该用户需求报告使用的参考资料,如:[1] 商务合同[2] 招标书[3] 用户领域的资料[4] 用户需求调查表[5] 用户需求报告[6] 参照的标准每一个文件、文献要有标题、或文件号,发布或发表日期以及出版单位。
1.5 相关文档(Related Documents)[1] 项目开发计划[2] 概要设计说明书[3] 详细设计说明书1.6 版本更新信息(V ersion Updated Record)版本更新记录格式,如表5-19所示。
表5-19 版本更新记录2.目标系统描述(System in Target)2.1 组织结构与职责(Organizing Framework and Function)将目标系统的组织结构逐层详细描述,建议采用树状的组织结构图进行表达,每个部门的职责也应进行简单的描述。
组织结构是用户企业业务流程与信息的载体,对分析人员理解企业的业务、确定系统范围很有帮助。
[项目名称] 需求规格说明书建设单位:承建单位:编订时间:丫丫丫丫-MM-DD文件修订记录目录第 1 章前言 (1)1.1 目的.......................................................... 1 .1.2 项目概述...................................................... 1 .1.3 术语和缩写.................................................... 1 .1.4 参考资料...................................................... 1 . 第 2 章业务需求.. (2)2.1 用户组织结构.................................................. 2 .2.2 业务需求概述.................................................. 2 .2.3 业务需求一.................................................... 2 .2.4 业务需求二.................................................... 3 . 第 3 章功能需求.. (3)3.1 功能需求概述.................................................. 3 .3.2 用户角色...................................................... 3 .3.3 公共功能需求.................................................. 3 .3.4 模块一........................................................ 3 .3.5 模块二........................................................ 6 . 第 4 章用户界面需求 (6)第 5 章系统接口需求 (7)5.1 接口需求一.................................................... 7 .5.2 接口需求二.................................................... 7 .5.3 转换需求...................................................... 7 . 第 6 章代码集 .. (7)6.1 代码一........................................................ 7 .6.2 代码二........................................................ 8 . 第 7 章系统运行环境. (8)7.1 软件环境...................................................... 8 .7.2 硬件环境...................................................... 8 .7.3 网络环境...................................................... 9 . 第 8 章其它需求.. (9)8.1 性能需求...................................................... 9 .8.2 存储需求...................................................... 9 .8.3 易用性需求.................................................... 9 .8.4 可靠性需求.................................................... 9 .8.5 可维护性需求................................................. 1..08.6 安全需求..................................................... 1..08.7 设计约束..................................................... 1..1可编辑1.1 目的说明开发本软件的目的;说明编写文档的目的;说明本文档所预期的读者1.2 项目概述简述项目背景及目标:项目背景:项目的提出原因项目环境背景项目优势分析(资源、技术、人才、管理等方面)项目运作的可行性项目的独特与创新分析1.3 术语和缩写列出本需求说明书中专门术语的定义以及英语缩写词的原词组。
X X信息化应用项目需求规格说明书版本历史目录1引言 (5)1.1文档目的 (5)1.2文档范围 (5)1.3读者对象 (5)1.4参考文献 (5)1.5术语与缩写解释 (5)2项目概述 (6)2.1项目背景 (6)2.2建设目标 (6)2.3功能总体描述 (6)2.4处理流程 (6)2.5产品范围 (6)2.6系统角色 (6)3功能性需求 (6)3.1功能需求分类 (6)3.2角色划分和权限控制 (7)3.3功能1详细描述 (7)4数据的逻辑描述 (8)4.1静态数据 (8)4.2动态输人数据 (8)4.3动态输出数据 (8)4.4内部生成数据 (9)4.5数据管理能力要求 (9)5外部接口需求 (9)5.1硬件接口 (9)5.2软件接口 (9)5.3通信接口 (9)6产品的非功能性需求(根据需求选择) (9)6.1软硬件环境需求 (9)6.2性能需求 (10)6.3扩展性需求 (10)6.4安全性需求 (11)6.5故障处理要求 (11)6.6产品质量需求 (11)6.7用户文档 (12)6.8其它需求 (12)1引言1.1文档目的编写本文档的目的是描述项目具体用户需求,包括功能性需求和非功能性需求,对用户的需求进行标准化定义和描述,以作为后续概要设计的依据。
1.2文档范围文档包括产品介绍,产品范围,功能性需求分类,外部接口,产品的非功能性需求等。
1.3读者对象预期读者为用户方负责人、项目开发人员、测试人员、运行维护人员及其它重要项目干系人1.4参考文献本文档编写涉及的相关文档。
1.5术语与缩写解释2项目概述2.1项目背景2.2建设目标2.3功能总体描述以文字、模块图等方式描述系统的功能结构2.4处理流程2.5产品范围提示:对指定的软件及其目的的简短描述,包括利益和目标。
把软件与企业目标或业务策略相联系。
可以参考项目视图和范围文档而不是将其内容复制到这里。
阐述本产品“适用的领域”和“不适用的领域”,本产品“应当包含的内容”和“不包含的内容”。
XXX公司XXXX系统需求规格说明书XXX公司2013年8月修订记录目录1.引言 (1)1.1.编写目的 (1)1.2.项目背景 (1)1.3.术语定义 (1)1.4.参考资料 (2)2.任务概述 (3)2.1.建设目标 (3)2.2.建设内容 (3)2.3.用户要求 (3)2.4.假定和约束 (4)3.系统需求 (5)3.1.功能架构图 (5)3.2.通用需求 (5)3.2.1.系统通用工具栏 (5)3.2.2.其它通用需求 (6)3.3.XXX管理子系统 (7)3.3.1.系统管理 (7)3.4.集成需求 (12)3.4.1.基础数据对接 (12)3.4.2.单点登录(SSO) (12)3.4.3.文书跨系统审批 (12)3.4.4.短信提醒 (13)3.5.性能需求 (13)3.6.网络需求 (13)3.7.存储需求 (13)3.8.安全需求 (14)3.8.1.技术平台设计安全需求 (14)3.8.2.系统运行安全需求 (15)4.运行环境规定 (15)4.1.设备 (15)4.2.软件 (16)4.2.1.服务器操作系统版本 (16)4.2.2.客户机 (17)4.2.3.数据库版本 (17)4.2.4.中间件服务器版本 (17)4.3.接口 (17)4.3.1.外部接口 (17)4.3.2.内部接口 (18)名词缩写:1.XXX集团,即“XXX省XXX集团有限责任公司”;[引号里面为全称]2.XXX系统,即“XXX集团XXX系统”;[引号里面为全称]3.XXX公司,即“XXX有限公司”,系统承建单位。
[引号里面为全称]1.引言1.1.编写目的XXX公司项目团队在完成对XXX公司已有业务系统(财务、供应、销售和人力资源)的功能调研,并对其作深入研究,同时分别派驻项目组员到、公司进行调研,并对调研结果进行详细分析,在和相关人员对建设功能深入探讨的基础上,提交这份系统需求规格说明书。
本文档对XXX公司XXX系统做了全面细致的用户需求分析,明确所要开发的系统应具有的功能、性能与安全机制,使软件开发人员能清楚地了解用户的需求,并在此基础上完成后续设计与开发工作,同时本文档也作为项目评审验收的依据之一。
中国联通投诉管理用户需求书(V4.0)2009-xx-xx发布2009-xx-xx实施中国联通公司发布前言2006年联通公司将实施“首问负责,全面执行”一站式服务,同时规范管理,严肃查处违规定制,简化业务处理流程,限时解决用户投诉。
并要求各省分公司及市分公司切实提高客户投诉处理中心的流程执行能力,现场不能答复的咨询与投诉,由投诉处理中心集中处理并按时限处理回复,为广大消费者打造一个公平公正的消费环境。
一流的客户服务需要完善的呼叫中心平台作支撑,为满足联通公司“首问负责,全面执行”一站式服务的业务需要,按照“多点受理、集中处理”,“以省为主、全网联动”和“电子工单全程监控”的原则,特制定本系统建设需求书。
投诉处理系统主要功能为省级投诉电子工单的闭环管理,全国范围投诉电子工单的督办与监控以及客服系统与运营管理数据的统计分析,本需求书提出了建设省级投诉处理系统的方式及电子工单的具体形式,电子工单处理、流转、监督的相关规定,以及统计分析的要求。
本需求书是中国联通新一代BSS系统用户需求书的之一,属于业务受理类需求,本需求书正文与附录均为规范性的,是中国联通各省规划和建设投诉处理系统的依据,各省(直辖市、自治区)公司应以本需求为指导,进行客户服务系统具体项目的建设。
V4.0修订说明:1、增加至尊卡用户级别。
本规范由中国联通公司市场部提出本规范由中国联通公司技术部归口本规范主要起草人:田榕、吴献存、葛剑鹏本规范的修改和解释权属中国联通公司市场部1 范围本需求书根据投诉管理相关业务规范的规定,对投诉工单的组成及其流转功能提出系统的支撑需求。
主要概括为以下内容:为满足联通公司“首问负责、限时办结”一站式服务的业务需要,按照“多点受理、集中处理”,“以省为主、全网联动”的处理原则,建设总部级与省级投诉处理系统,实现投诉工单的在各渠道、各业务部门的全程流转、全程监控。
本需求书是根据《中国联通“联通10010”服务管理规范(1.0版)》及《中国联通客户品牌服务标准(1.0版)》中投诉管理的相关规范所编写,包括但不仅限于管理规范所要求的各项内容,并将根据管理规范的修订进行版本更新。
需求规格说明书在当今的数字化时代,软件和系统的开发变得日益复杂和关键。
为了确保项目的成功实施,清晰明确地定义需求是至关重要的。
一份详尽准确的需求规格说明书不仅是开发团队的工作指南,也是客户与开发团队之间沟通的重要桥梁。
需求规格说明书是对软件系统或产品的功能、性能、数据、安全等方面的详细描述,它为软件开发过程提供了明确的目标和约束。
接下来,让我们深入了解一下需求规格说明书的各个重要组成部分。
一、项目背景和目标首先,我们需要阐述项目的背景信息,包括为什么要开展这个项目,它是为了解决什么问题或者满足什么业务需求。
例如,一家电商公司可能需要开发一个新的订单管理系统,以应对日益增长的订单量和复杂的业务流程。
明确项目的目标也是必不可少的。
目标应该是具体、可衡量、可实现、相关且有时限的(SMART 原则)。
比如,新的订单管理系统要在三个月内上线,能够处理每天 10 万笔订单,并且订单处理错误率低于01%。
二、功能需求这是需求规格说明书的核心部分之一。
详细描述系统需要具备的各项功能,包括输入、输出、处理逻辑等。
以一个在线学习平台为例,功能需求可能包括用户注册与登录、课程浏览与搜索、课程购买与支付、在线学习、作业提交与批改、学习进度跟踪等。
对于每个功能,都要进行清晰的定义和描述。
比如,课程浏览功能应该能够按照课程分类、热门程度、评价等多种方式展示课程列表,并且提供课程详情页面,包括课程简介、大纲、授课教师信息等。
三、性能需求性能需求主要关注系统在处理业务时的响应时间、吞吐量、资源利用率等方面的要求。
例如,对于一个电商网站,在促销活动期间,页面加载时间不能超过 3 秒,系统能够同时处理 10 万个并发用户的请求,并且服务器的 CPU 利用率不能超过 80%。
性能需求的定义要结合实际业务场景和用户的期望,同时也要考虑到系统的可扩展性,以满足未来业务增长的需求。
四、数据需求数据需求涵盖了系统需要处理和存储的数据类型、数据量、数据格式、数据来源和数据流向等方面。
旅游消费投诉管理系统-需求规格说明书案场各岗位服务流程销售大厅服务岗:1、销售大厅服务岗岗位职责:1)为来访客户提供全程的休息区域及饮品;2)保持销售区域台面整洁;3)及时补足销售大厅物资,如糖果或杂志等;4)收集客户意见、建议及现场问题点;2、销售大厅服务岗工作及服务流程阶段工作及服务流程班前阶段1)自检仪容仪表以饱满的精神面貌进入工作区域2)检查使用工具及销售大厅物资情况,异常情况及时登记并报告上级。
班中工作程序服务流程行为规范迎接指引递阅资料上饮品(糕点)添加茶水工作要求1)眼神关注客人,当客人距3米距离时,应主动跨出自己的位置迎宾,然后侯客迎询问客户送客户注意事项15度鞠躬微笑问候:“您好!欢迎光临!”2)在客人前方1-2米距离领位,指引请客人向休息区,在客人入座后问客人对座位是否满意:“您好!请问坐这儿可以吗?”得到同意后为客人拉椅入座“好的,请入座!”3)若客人无置业顾问陪同,可询问:请问您有专属的置业顾问吗?,为客人取阅项目资料,并礼貌的告知请客人稍等,置业顾问会很快过来介绍,同时请置业顾问关注该客人;4)问候的起始语应为“先生-小姐-女士早上好,这里是XX销售中心,这边请”5)问候时间段为8:30-11:30 早上好11:30-14:30 中午好 14:30-18:00下午好6)关注客人物品,如物品较多,则主动询问是否需要帮助(如拾到物品须两名人员在场方能打开,提示客人注意贵重物品);7)在满座位的情况下,须先向客人致歉,在请其到沙盘区进行观摩稍作等待;阶段工作及服务流程班中工作程序工作要求注意事项饮料(糕点服务)1)在所有饮料(糕点)服务中必须使用托盘;2)所有饮料服务均已“对不起,打扰一下,请问您需要什么饮品”为起始;3)服务方向:从客人的右面服务;4)当客人的饮料杯中只剩三分之一时,必须询问客人是否需要再添一杯,在二次服务中特别注意瓶口绝对不可以与客人使用的杯子接触;5)在客人再次需要饮料时必须更换杯子;下班程序1)检查使用的工具及销售案场物资情况,异常情况及时记录并报告上级领导;2)填写物资领用申请表并整理客户意见;3)参加班后总结会;4)积极配合销售人员的接待工作,如果下班时间已经到,必须待客人离开后下班;1.3.3.3吧台服务岗1.3.3.3.1吧台服务岗岗位职责1)为来访的客人提供全程的休息及饮品服务;2)保持吧台区域的整洁;3)饮品使用的器皿必须消毒;4)及时补充吧台物资;5)收集客户意见、建议及问题点;1.3.3.3.2吧台服务岗工作及流程阶段工作及服务流程班前阶段1)自检仪容仪表以饱满的精神面貌进入工作区域2)检查使用工具及销售大厅物资情况,异常情况及时登记并报告上级。
投诉处理数据库说明书尊敬的用户,感谢您选择使用投诉处理数据库。
本说明书将帮助您了解该数据库的功能和使用方法。
请详细阅读以下内容,以便更好地使用该系统。
1. 数据库简介投诉处理数据库是专为企业组织和机构设计的一个高效的信息管理系统。
它旨在帮助用户追踪、记录和处理投诉事件,以提高客户满意度和处理效率。
2. 系统功能2.1 投诉信息录入该系统提供了一个用户友好的界面,便于用户录入投诉信息。
用户需要填写投诉人的基本信息、投诉的内容和相关的附件文件。
所有信息都将被自动记录并存储在数据库中。
2.2 投诉信息查询用户可通过系统查询功能快速找到需要查看的投诉信息。
支持按照时间、投诉类型、投诉人等多个维度进行筛选,以快速找到所需信息。
2.3 投诉信息统计系统具有强大的统计功能,可以根据不同的维度对投诉信息进行统计分析。
用户可以根据需要生成各类图表和报告,以便更好地了解投诉情况和问题热点。
2.4 投诉处理流程该系统支持自定义投诉处理流程。
用户可根据组织内部的投诉处理规定设置不同的流程,包括投诉受理、调查、处理和反馈等环节。
每个阶段的处理人员和处理时间都将被记录和追踪。
3. 系统使用方法3.1 登录系统用户需要使用有效的账号和密码登录系统。
如果是首次登录,需先进行账号注册并获取相应的权限。
3.2 录入投诉信息登录后,用户可点击“录入投诉信息”按钮,在弹出的界面上填写相关信息,并上传附件文件(如有必要)。
完成后,点击“保存”按钮将投诉信息存入数据库。
3.3 查询投诉信息用户可通过点击“查询投诉信息”按钮进入查询界面。
在界面上,用户可设置查询条件和参数,然后点击“搜索”按钮执行查询操作。
系统将根据设置的条件显示相关投诉信息。
3.4 统计分析点击“统计分析”按钮,用户可选择需要统计的维度和时间范围,然后点击“生成报表”按钮。
系统将自动生成相应的图表和报告,以直观地展示投诉情况和趋势。
3.5 处理投诉在处理投诉时,用户可点击“处理流程”按钮,查看当前投诉的处理进度和相关人员。
文档编号:BJFU_115_HKJP_001投诉业务系统需求规格说明书需求说明书所属项目:投诉业务系统需求规格说明书版本号:1.0编写者:BJFU审核者:BJFU批准者:BJFU1引言 (3)1.1编写目的 (3)1.2项目背景 (3)1.3定义 (3)1.4参考资料: (4)2任务 (4)2.1目的 (4)2.2运行环境 (4)2.3条件与限制 (4)3功能需求 (4)3.1系统流程 (4)3.2贵阳农行系统流程 (8)4数据描述 (9)4.1数据流图 (9)4.2静态数据 (11)4.3动态数据 (11)4.4数据字典 (11)5性能要求 (13)6运行需求 (13)1引言1.1编写目的本文档定义投诉业务系统的功能需求、数据描述、运行环境。
本文档可作为CALLCENTER系统设计人员,售前技术支持人员,程序员,测试人员、使用人员的参考资料。
1.2项目背景本设计文档参考了UT斯达康DSD R&D CALLCENTER开发小组“浙江移动呼叫中心”项目的客户呼叫中心投诉、建议功能模块设计说明书及业务需求分析而写的,对原有的说明书进行修改并增加了一些功能,如投诉处理、处理结果反馈等功能,使本子系统具有一定的通用性,不仅适合电信局,也适用于银行等。
1.3定义投诉:包括投诉与建议,是指CallCenter中,处理客户通过电话、信函、传真、EMAIL 等手段对服务质量的投诉和一些客户对有关部门的建议。
并且将客户的投诉、建议统一录入服务器中心数据库(或本地数据库),然后进行分类,再将投诉、建议发往相关部门处理。
对处理进行全过程追踪,并将处理结果反馈给客户,将客户对处理结果的意见进行记录。
作为评价处理部门的工作的依据。
UUI:系统各模块之间交换应用数据的桥梁,主要应用在以下几方面:呼叫从IVR转移到Agent、Agents之间呼叫互转和多个Agents、用户实现会议电话。
UUI携带的信息主要为语种、应用的识别号AppID、应用信息的标识符等等[1]。
信用投诉举报管理系统需求说明书V0.52011年12月保密须知本文档属商业机密,所有权属于辽宁立科信息工程有限公司。
其所涉及的内容和资料只限于本公司内部使用,使用本文件时,使用人应遵守以下的规定:在没有取得公司和项目组的书面同意前,任何人不得将本文件全部或部分地予以复制、传递给他人、影印、泄露或散布给他人。
修订记录*变化状态:A——增加,M——修改,D——删除1.引言1.1编写目的《投诉举报管理系统需求说明书》描述“投诉举报管理系统”处理投诉举报的流程、查看投诉举报的处理跟踪情况以及查询统计分析等功能。
目的:●为客户快速呈现投诉举报管理的处理流程●为客户快速呈现每个处理模块的功能●为进一步挖掘客户需求提供参考●为估算工作量和工期提供重要依据●为开发人员提供详细设计的依据●项目经理将根据说明书的主体功能布置和控制开发工作全过程●项目质量保证人员将按此说明书做阶段性跟踪和成果物验证和确认预期读者:●客户●部门经理●项目经理●项目开发人员●测试人员●执行软件质量保证计划的专门人员●其他相关干系人1.2术语定义1.3参考资料无。
2.需求分析2.1投诉举报信息的填报(1)网上举报信息填报。
征集网民提供的举报信息,举报社会中企业出现的诚信失信情况,通过广大社会民众监督企业社会行为,同时举报填报作为企业失信信息的采集途径,信息内容包括举报标题、举报内容描述、事件发生时间、填报人姓名、单位名称、身份证号、联系电话等,填报后点击“提交”按钮即可提交举报信息,系统将给出一个唯一反馈号码,字母和数字组合,用于之后查询。
(2)网上投诉信息填报,在社会企业与企业之间,企业与个人之前会发生由于失信造成企业或个人的损失,信用投诉提供了投诉他人失信信息的窗口,同时投诉填报能够作为企业失信信息的采集途径。
投诉者可以填报要投诉的详细信息,信息内容包括投诉对象、投诉内容描述、事件发生时间、填报人姓名、单位名称、身份证号、联系电话等,填报后点击“提交”按钮即可提交投诉信息,系统将给出一个唯一反馈号码,字母和数字组合,用于之后查询。
酒店投诉管理系统需求规格说明书目录1概述 (3)1.1编写目的 (3)1.2适用范围 (3)1.3术语和缩写 (3)2项目综述 (3)2.1项目介绍 (3)2.2项目面向的用户 (4)2.3项目应当遵循的标准或规范 (4)2.4主要特征 (4)2.5项目范围 (4)2.6项目中的角色 (4)3功能性需求 (5)3.1功能性需求分类 (6)3.2模块一 (7)3.2.1子模块一 (7)3.2.2子模块二 (8)3.2.3子模块三 (10)3.2.4子模块四 (11)3.3模块二 (12)3.3.1子模块一 (12)3.3.2子模块二 (13)3.3.3子模块三 (15)3.3.4子模块四 (19)3.4功能结构图 (20)3.4.1管理员 (20)3.4.2顾客投诉 (21)3.5接口需求 (21)4非功能性需求 (22)4.1用户界面需求 (22)4.2软件环境需求 (22)4.3硬件环境需求 (22)4.4产品质量需求 (22)4.5故障处理 (22)1概述本系统是根据酒店投诉的特点,集用户反馈,投诉于一体,为酒店量身定做的酒店投诉软件。
系统开发的总体任务是完成客户基本信息管理,投诉登记管理,投诉信息查询管理,投诉信息回复管理,投诉信息处理管理,反馈登记管理,反馈信息查询管理,反馈信息回复管理,反馈信息处理管理使之形成一个整体、一个系统,各项功能严谨,各模块相互独立,内部有机结合在设计过程中最大限度满足用户的要求,因此,该系统具有较强的实用性和针对性。
1.1 编写目的帮助酒店建立良好的管理秩序,在信息化时代充分利用计算机作为管理手段提高管理水平和业务处理。
1.2 适用范围中小型酒店。
1.3 术语和缩写术语和缩写解释2项目综述2.1 项目介绍1.现代酒店大多都集住宿、餐饮、娱乐为一体,提供食、住、娱一条龙服务。
有资料显示,在人民的物质文化生活有了很大改善的今天,在酒店消费的人民对饭店的投诉呈上升趋势。
成果上报申请书成果名称投诉客户自助服务系统成果申报单位重庆公司成果承担部门/分公司热线一部客户响应室/ 客户服务中心项目负责人姓名项目负责人联系电话和Email成果专业类别*其他成果研究类别*新产品开发研究省内评审结果*优秀关键词索引(3~5个)投诉处理客户服务自助服务短信IVR 电子渠道应用投资10-16万元(指别的省引入应用大致需要的投资金额)产品版权归属单位中国移动通信集团重庆有限公司对企业现有标准规范的符合度:重庆移动市电〔2009〕898号《中国移动通信集团重庆有限公司客户投诉管理办法V1.0》重庆移动市电[2010]28号《关于新增启用1008609投诉服务渠道的通知》中移市[2008]125号《关于印发〈中国移动客户投诉管理办法〉的通知》如果该成果来源于研发项目,请填写研发项目的年度、名称和类型(类型包括:集团重点研发项目、集团联合研发项目、省公司重点研发项目、其他研发项目),可填写多个:研发项目年度:2009年名称:投诉客户自助服务系统类型:其他研发项目成果简介:由重庆移动公司客户服务中心研发的投诉处理客户自助服务系统,积极响应集团公司“便捷服务,满意100”的号召,从便捷服务的角度出发,针对重庆移动投诉客户开发应用简单易用的投诉处理自助服务,结束了投诉处理全程全人工服务模式的历史。
投诉自助服务系统是一个针对重庆移动客户开放的多渠道多功能服务体系,目前开放IVR、短信和人工服务渠道。
它具备客户投诉进度查询、投诉信息反馈、新投诉受理、投诉预处理、投诉专席IVR导航等多种功能,使有投诉记录客户能够随心便捷地查询并与投诉处理人员保持沟通联系;提升投诉客户的满意度;同时有效减少投诉客户占用10086热线其他坐席资源的频次,同时也降低投诉处理专席普通问题的人工服务成本。
省内试运行效果:投诉自助服务系统分语音和短信两种自助服务方式,项目组成员多次组织投诉处理员工体验使用,并对短信内容等细节服务不断完善优化后,先后于09年4月和10年1月正式上线并面对投诉客户推广使用。
1、登录投诉系统
登陆地址:http://202.104.57.132/sp 输入帐号密码:
登陆后---点投诉管理:
2、新建投诉单
1)进入投诉界面—新建投诉单:
2)如新建短信投诉单-----选择短信投诉单
进入短信投诉单界面:
1、填写相关内容:红星的为必填项
填写相关内
容
2、选择路由:提交分公司专家处理,或提交给互增中心处理
选择其中的
一项路由
3、点提交:
选确定则提交出去,取消则不提交
点提交
选择其中的
一项路由
4、处理投诉单:
1)进入投诉界面---点开待办工单
2)填写相关处理结果待办工单
可选择投诉类型,显示某一类
分公司专家填写
互增中心
填写
Sp商填写
3)选择路由:
A 1000号:提交分公司专家处理,或提交给互增中心处理
B 分公司专家:提交给互增中心处理、或反馈处理结果给1000号
C、互增加中心:提交sp处理,或反馈处理结果给1000号
选择其中的
一项路由
4)点提交:
选确定则提交出去,取消则不提交
点提交
选择其中的
一项路由
3、其它说明:
1、功能按钮
:保存当前录入的信息
:把工单提交给其它人处理
:关闭当前页面,去到待办已办页面
2、待办、已办区
待办区域:放的是需要你处理的工单。
已办区域:放的是你已经提交给其它人处理的工单,不需要你处理。
3、 流程跟踪:打开每张工单,都可以看到流程,查看详细的工单流转情况:
待办工单
已办工单
可选择投诉类型,显示某一类
可选择投诉类型,显示某一类。
旅游消费投诉管理系统需求规格说明书学院:软件与通信工程学院课程:软件需求分析2016/6/13目录Part I 引言 (2)1.1文档目的 (2)1.2组织方式 (3)1.3项目范围 (3)1.4参考文献 (4)Part II 总体描述 (4)2.1产品前景 (4)2.2产品特性 (4)2.3用户类及其特征 (5)2.4运行环境 (6)2.5设计和实现上的约束 (6)2.6假设和依赖 (7)Part III 详细需求描述 (7)3.1对外接口需求 (7)3.1.1用户界面 (7)3.1.2硬件接口 (8)3.1.3软件接口 (8)3.2功能需求 (8)3.2.1信息流 (8)3.2.2 处理描述 (9)3.2.3 数据结构描述 (15)3.2.4 数据字典 (16)3.3 性能需求 (17)3.3.1 数据精确度 (17)3.3.2 时间特性 (17)3.3.3 适应性 (17)3.3.4 容量需求 (17)3.3.5 实时性 (18)3.3.6 负载 (18)3.4 质量属性 (18)3.4.1 完整性 (18)3.4.2 可靠性 (18)3.4.3 效率 (18)3.4.4 易用性 (19)3.4.5 可维护性 (19)3.4.6 可移植性 (19)3.5 其他需求 (20)3.5.1 安全性需求 (20)Part I 引言1.1文档目的编写此文档的目的在于进一步定制系统(旅游消费投诉管理系统)开发中的细节问题,以便于用户和旅行公司协调工作,主要面向的读者是项目委托单位的管理人员。
本文档定义了有关旅游消费投诉管理系统的功能需求,数据描述,运行环境等内容。
本文档也可作为系统设计人员,技术支持人员,测试人员,使用人员的参考资料。
1.2组织方式在文档的余下部分会阐述对系统总体的描述,系统特性的详细描述,对外接口的实现以及其他一系列功能需求和非功能需求的描述。
文档基本上按照由总体到局部的格局,首先对系统的总体概要描述,之后将对对外接口进行阐述,最后将列出一系列功能需求以及非功能需求。
客户投诉管理标准客户投诉管理标准1 目的规范客户抱怨及投诉处理程序,维护公司信誉,提高客户满意程度。
2 范围适用于公司所有客户抱怨和投诉。
3 职责分配3.1 营销中心负责核实客户投诉真实性。
3.2 质量部负责客诉合理性审核,以及登记、传递、跟踪、总结分析并存档管理。
3.3 质量部负责对产品质量问题客诉进行事实鉴定、处罚金额核定、责任划分,并组织责任部门进行改进。
3.4 公司其它相关部门协助质量部调查取证,处理本部工作质量问题引发的客户投诉,并将本部门责任落实到责任人。
3.5 各系统(主管)负责对投诉判定产生的首次争议进行核实处理。
3.6 客户投诉处理职位权限见下表:4.1 投诉时限4.1.1 产品质量不符合国家法律法规、国家标准及客户要求,客户有权在货到30天内提出投诉。
4.1.2 客户在使用过程中发现下列情形,确属我方责任的在60天内投诉视为有效投诉。
4.1.3若遇产品送货后出现在了瑕疵,需要客户消化处理的,在客诉有效时间内提供不了准确损失数据的,业代报需报销售副总批示。
(最长时间不能超过7个月)a 产品尺寸偏差超出国家标准的;b 产品用材不符合客户要求的;c 产品出现脱层、起泡、假粘的;d 产品缺材的;e 产品有明显印刷质量问题的;f 产品成型有明显质量问题,包括开槽、压线、模切、钉(粘)箱;g 产品其它明显属我方责任的。
4.1.3 客户收货后,60天内未使用的,除强度问题外,90天内视为有效投诉。
4.2 客户投诉办理4.2.1 客户通过经办业务员投诉。
业务员接到投诉后应到客户处核实投诉内容的真实性。
4.2.2 投诉证据提供。
(注:为使客户投诉内容合理成立的证明材料称之为客户投诉证据,包括质量问题样箱(板)、客户盖章的情况说明书、检验报告、退货通知、公司出库单(或客户入库单)或其它确切表明投诉真实性的材料。
)客户投诉须具备充分的证据。
下列情况必须提供相应的证据:a 客户投诉的质量问题能通过感观或检测装置验证的,须提供有质量问题的产品;b 客户投诉要求索赔、降价、罚款、退货的,须经本标准3.6条相关人员同意后方可处理,并出具客户盖章的说明(或扣款单)、与客户签订的处理协议、或由3.6条规定相应权限人员签字确认;否则视为无效投诉。
文档编号:BJFU_115_HKJP_001投诉业务系统需求规格说明书需求说明书所属项目:投诉业务系统需求规格说明书版本号:1.0编写者:BJFU审核者:BJFU批准者:BJFU第 1 页1 引言 (3)1.1 编写目的 (3)1.2 项目背景 (3)1.3 定义 (3)1.4 参考资料: (4)2 任务 (4)2.1 目的 (4)2.2 运行环境 (4)2.3 条件与限制 (4)3 功能需求 (4)3.1 系统流程 (4)3.2 贵阳农行系统流程 (8)4 数据描述 (9)4.1 数据流图 (9)4.2 静态数据 (11)4.3 动态数据 (11)4.4 数据字典 (11)5 性能要求 (13)6 运行需求 (13)第 2 页1 引言1.1 编写目的本文档定义投诉业务系统的功能需求、数据描述、运行环境。
本文档可作为CALLCENTE系R统设计人员,售前技术支持人员,程序员,测试人员、使用人员的参考资料。
1.2 项目背景本设计文档参考了UT斯达康DSDR&D CALLCENTER开发小组“浙江移动呼叫中心”项目的客户呼叫中心投诉、建议功能模块设计说明书及业务需求分析而写的,对原有的说明书进行修改并增加了一些功能,如投诉处理、处理结果反馈等功能,使本子系统具有一定的通用性,不仅适合电信局,也适用于银行等。
1.3 定义投诉:包括投诉与建议,是指CallCenter 中,处理客户通过电话、信函、传真、EMAIL等手段对服务质量的投诉和一些客户对有关部门的建议。
并且将客户的投诉、建议统一录入服务器中心数据库(或本地数据库),然后进行分类,再将投诉、建议发往相关部门处理。
对处理进行全过程追踪,并将处理结果反馈给客户,将客户对处理结果的意见进行记录。
作为评价处理部门的工作的依据。
UUI :系统各模块之间交换应用数据的桥梁,主要应用在以下几方面:呼叫从IVR 转移到Agent 、Agents 之间呼叫互转和多个Agents 、用户实现会议电话。
UUI 携带的信息主要为语种、应用的识别号AppID 、应用信息的标识符等等。
[1]CTI SERVER:联结PBX和LAN。
IVR SERVER:电话语音处理服务器。
DLL :动态链接库(Dynamic Link Library), WINDOWS 程序之间相互调用的一个机制。
第 3 页1.4 参考资料:[1]UUI 数据包结构(黄武)[2] 应用程序模板文件使用说明(张磊)[3] 开发部文档编写指南[4] 浙江移动客户呼叫中心项目建议书中有关投诉、建议的描述[5]CALLCENTER开发小组前台程序的体系结构和管理模块的设计[6] 贵阳市农业银行客户服务系统业务范围确认表(诸伟)注:由于投诉与建议的内容基本上是一样的,下面的内容只说明投诉部分,实际在处理时,可将两部分做在一起。
2 任务2.1 目的提供给系统分析员一个总体思想,是概要、详细设计的指导.可为CALLCENTER系统设计人员作参考,也可作为其他子系统程序员的参考资料.2.2 运行环境本系统既有前台部分,又有小部分后台模块(见后面的模块结构说明),前台主要是PC机,硬件要求:CPU:Pentium ,内存:8M以上,硬盘:100M以上软件要求:OS 为Windows95(Windows98 或NT Worksation),SyBase OpenClient (OracleOpenClient),TSAPI (Lucent 提供),CTI CLIENT ,2.3 条件与限制目前由于实际需要,我们不能做成WEB模式。
只能支持电话、FAX、E-mail 投诉方式。
3 功能需求3.1 系统流程投诉按工作流程可以划分为三部分:第 4 页投诉用户投诉受理投诉处理处理结果追踪反馈投诉受理包括:a). 电话投诉: 用户拨打服务中心特服号(如180 台)并选择投诉功能后,1. 如果没有空闲的座席,系统提示:座席全忙,请稍后再拨。
2. 如果是晚间处于系统无人值守时,系统提示系统现正处于无人值守状态,请留下录音,会尽快与用户联系,然后开始录音记下用户投诉的内容、在数据库中自动记下用户的电话信息等,或者给用户留下本服务台的地址(E-Mail 或信函地址)。
3. 如果有空闲的座席(AGEN)T,提示用户:X 号受理员接受您的投诉,然后将用户转往该人工座席。
b). 其他投诉:接受用户投诉的信函、E-Mail 、FAX。
操作员记下用户投诉的内容、用户的电话信息、地址等。
注:将投诉受理分为两部分是因为电话投诉要与CTIServer 、PBX有关系。
而其他的投诉相对比较独立的,除了几个数据表与其它的子系统有关联外,另外的部分相当于一个小的管理系统独自运行。
并且从后面的概要设计、详细设计的描述,可以知道电话投诉受理要继承一个模板(TTemplate )而其它受理不必继承。
[2]投诉处理:投诉查询、统计、落实、处理,追踪投诉的处理,回复客户投诉,监督和检查企业各部门的服务质量,收集和反馈社会对单位的意见和建议,并在数据库中记下投诉处理内容,投诉处理可能是本系统的难点。
投诉的处理要考虑四种情况:a).话务员接到投诉后能直接处理,这种方式比较简单,直接在数据库中记录处理信息,当场或以后回复投诉用户。
b).话务员认为应给其他的话务员处理,通过电话转移给其他的话务员处理,电话转移可在投诉受理中处理,如果转移后能直接处理,同a)。
c).话务员认为需要进行会议电话多人处理,此时进行会议电话,如果能直接处理,同a),会议电话的工作可在投诉受理中处理。
d).不同于a,b,c,a,b,c 的投诉处理是在话务员内部处理,一种比较常见的情况是话务员内部不能处理,可能需要转到其他的部门处理,其他的部门之间也有互相转移处理,甚至还有类似于会议电话的处理。
投诉反馈:将投诉处理的结果以电话(外拨)、FAX 、E-Mail 、信函的形式反馈给用户,并相应在数据库中记下标志。
有四种形式的反馈:a ) . 电话(外拨),根据投诉人的电话(如办公室电话,家庭电话等),直接外拨(可手工也要自动),并将结果反馈给用户。
a).FAX 可实时传真,也可不实时传真。
这需要通过IVRb).信函,将给投诉人的反馈信息、投诉人的地址打印出来即可。
c).E-mail ,根据投诉人的E-mail 地址,将给投诉人的反馈信息以E-mail 的形式反馈给用户。
第 5 页上面的三部分是投诉子系统的主要部分,其它的附加部分主要有统计分析与报表生成。
对所得到的业务数据进行统计,如:受理量统计、用户满意情况统计、投诉统计、故障情况统计等,统计结果可以按不同的形式(各类统计图、表等)进行报表输出和文件存储。
同时还能够对已有的数据进行分析,以便能够了解整个系统的运转情况,适时的对某些不合理的地方提出改进的方案和意见。
投诉信息分析及报表生成对用户的投诉、建议和障碍申告数据,系统受理和答复的数量、质量数据等,进行整理、分析,产生窗口服务质量的管理数据,系统运行维护情况的管理数据,系统建设方面的决策数据,分别供营业部门和运行维护部门的领导和移动通信业务主管部门和领导使用。
·客户服务中心自身服务情况统计:总受理量、每天平均受理量、来话平均受理时间、平均等待时间、最长等待时间,某一时间段受理量波形。
·营业系统服务投诉统计:服务员号、被投诉服务日期、投诉原因。
·运行维护系统投诉统计:各地区的投诉数与百分比、各障碍现象被投诉数和百分比。
上面的工作流程用图表表示如下:①投诉受理工作流程第 6 页投诉人电话拨入其它投诉( 信函、E-mail 、FAX)转Agent 转操作人员记录或修改投诉内容Y N能否立即处理N转移电话否YY会议电话否Yes 能否处理No N o是否转移到其投诉处理N Y它的部门处理投诉反馈转移到其它部门受理结束②投诉处理工作流程处理人( 操作人)主动被动自动查询未处理的信息从其他人员处发过来的内容Y N能否处理录入处理的信息N Y是否转发转发给其他的部门投诉处理结束第7 页③投诉结果反馈工作流程处理人( 操作人)主动被动自动查询处理过的信息从其他人员处发过来的内容录入用户反馈的信息根据投诉人不同的联系方式将反馈内容分发给用户投诉反馈结束④投诉信息分析及报表生成统计人对自身服务查询统计营业系统服务投诉查询统计运行维护系统查询统计系统的建议查询统计天平均受理量平均受理时间某一段时间受理量被投诉部门被投诉服务员号被投诉原因被投诉服务日期各地区投诉数各故障现象投诉数总受服务故障理量质量现象投诉建议量化信息3.2 贵阳农行系统流程根据[6] 贵阳市农业银行客户服务系统业务范围确认表, 贵阳农行CallCenter 的系统流程如第8 页下, 上面的系统流程具有通用性, 这在一般的系统中都是这样的, 可以在系统工作(功能)流程中设置:电话接入语音提示用户选择功能1 : 用户投诉2 : 投诉反馈系统自动获得主叫,送往空闲人工坐席,根据用户需要记录投诉内根据用户查询投诉处理结容果根据投诉内容书面转发不同责任部门责任部门处理投诉人工取得结果并外拨电话回复投诉人工取得结果并外拨电话回复投诉结束4 数据描述4.1 数据流图根据业务流程,总体的数据流图如下:电话号码、其它信息电话受理用户信息用户信息记录有关部门、人员信息投诉人操作员用户信息用户信息其他受理投诉内容循环处理处理投诉返回投诉人信息投诉处理内容由于电话受理是一个拨打电话的过程,从IVR 转AGENT( 当然也可能包括用户直接拨到IVR, 然后从IVR 请求如FAX 的功能,这在返回投诉人信息中可以看到),其它受理包括发送信函、E- mail、Fax 等,这与系统的设计工作不是很大,我们忽略这两部分。
主要对记录、处理投诉、第9 页返回投诉人信息三个部分进行细化,同时也给出了查询统计的DFD 图。
1、记录投诉用户信息部门信息操作员基本信息记录操作员量化信息投诉内容会议、转移电话来电、投诉内容OR转发处理人员处理投诉数据库2、处理投诉投诉数据库录入处理信息查询未处理内容OR处理人消息处理从其他人转转发发过来的消息第10 页修改投诉数据库外拨查询处理过的投诉OR E-mail操作人员投诉用户FAX信函用户反馈意见4、查询统计投诉数据库查询统计内容操作人员多条件组合查询统计打印输图表出输出4.2 静态数据主要包括单位的人员信息、部门信息(既包括投诉责任体,又包括处理投诉的部门)、基本的投诉内容(如常用投诉内容如服务员态度不好、收费过高、故障、系统出错等,以编码的形式保存)、不同操作人员的机器地址。
4.3 动态数据输入:主要是投诉人的信息、投诉内容、投诉方式等输出:主要是投诉的处理结果、反馈给用户的数据(如Fax、电话、E-mail 、录音)4.4 数据字典根据DFD 图,上面用到的数据表或数据文件如下(给出具体的数据项定义):操作人员信息(与其它子系统接口):1、编号=(1.999999)为操作人员的唯一标识2、姓名=8 个字符串3、性别={男|女}4、所属部门={A部|B部|C部|⋯⋯}5、其它信息部门单位1、部门编号=(1..1000)2、部门名称=小于长度是40位的字符串3、其它信息投诉人员信息1、投诉人编号=(000000000001..999999999999)为投诉人的唯一标识2、投诉人姓名=8 个字符串3、投诉人性别={男|女}4、投诉人投诉人年龄={10..100}5、投诉人所属单位名称=长度小于40 字符串6、投诉人联系电话=家庭电话+单位电话+BP机号码+手机号码7、投诉人Fax=小于长度是15位的数字、“-”字符串,以数字开头8、投诉人Email=小于长度是40位的字符串9、投诉人联系地址=小于长度是40位的字符串2、投诉人邮编=6位的数字字符串投诉内容1、投诉流水号=(000000000001..999999999999)为投诉受理的唯一标识,系统自动产生2、受理方式={电话受理|传真受理|EMAIL受理|信函}3、主叫号码=小于是15位的数字、“-”字符串,以数字开头主要功能为防止恶意呼叫,系统自动显示4、投诉人姓名=8 个字符串5、投诉人性别={男|女}6、投诉人年龄段={10~20|20~30|30~40 ⋯⋯}7、投诉人工作单位或住址=长度小于40 字符串8、投诉业务分类={故障|操作不当|话费争议|窗口服务质量|网络问题|其它}9、投诉业务分类详细(量化信息)={ 故障1.2.3 ⋯|操作不当 1.2.3 ⋯|话费争议1.2.3 ⋯|窗口服务质量 1.2.3 ⋯|网络问题 1.2.3 ⋯|其它 1.2.3 ⋯}10、投诉类型={投诉|建议}11、投诉性质分类={严重|一般|中等| 故意}12、责任体={被投诉的部门|被投诉的人|其它}投诉人需要答复的最后期限=大于当日的日期{yyyy-mm-dd}13、联系方法={电话|传真|信件|亲自查询|Email }14、16、操作人员编号=(1..9999999 )*注:对于数据项8 有待将投诉的分类进一步量化。