crm客户关系标准管理系统需求文档.doc

用户关系管理系统
需求规格说明书
编号：JB-RM-CRM
版本：1.0

作者：
H.L.
日期：
-12-12
审批：

日期：

状态
修订人
修改日期
版本
备注
新创建
PM
-12-12
1.0

1 概述
用户是企业最宝贵资源，为了愈加好发掘老用户价值，并开发更多新用户，XX企业决定实施用户关系管理系统。期望经过这个系统完成对用户基础信息、联络人信息、交往信息、用户服务信息充足共享和规范化管理；期望经过对销售机会、用户开发过程追踪和统计，提升新用户开发能力；期望在用户将要流失时系统立即预警，方便销售人员立即采取方法，降低损失。并期望系统提供相关报表，方便企业高层随时了解企业用户情况。
用户服务是一个包含多个部门，存在一定步骤工作。用户服务水平高低决定着企业关键竞争力。该用户关系管理系统应提供一个用户服务在线平台，使用户服务处理过程中相关人员能够在线完成服务处理和统计工作。
1.1 目标
本文档是北京信息技术在和XX企业用户关系管理系统实施协议基础上编制。本文档编写为下阶段设计、开发提供依据，为项目组组员对需求详尽了解，和在开发开发过程中协同工作提供强有力确保。同时本文档也作为项目评审验收依据之一。
1.2 范围
本系统包含：营销管理、用户管理、服务管理、统计报表和基础数据五个功效模块。另包含权限管理模块用于系统用户、角色和相关权限。系统功效为本说明书和附件Demo版界面描述中功效并集。在上述文件未明确描述情况下，应能满足协议和相关投标书所描述功效。
1.3 读者对象

1.4 参考文档
无
1.5 术语定义
系统用户：
XX企业职员。

用户：
购置XX企业产品或有意向购置XX企业产品单位用户，不包含个人用户。

用户服务：
由用户提出申请，需要XX企业职员对其做出响应活动。分咨询、提议、投诉等类型。
2 系统说明
2.1 概述
用户关系管理系统用于管理和用户相关信息和活动，但不包含产品信息、库存数据和销售活动。这三类数据将由XX企业X销售系统进行管理。但本系统需要提供产品信息查询功效、库存数据查询功效、历史订单查询功效。
2.2 用户和角色
和本系统相关用户和角色包含：

系统管理员：
管理系统用户、角色和权限，确保系统正常运行。

销售主管：
对用户服务进行分配。
创建销售机会。
对销售机会进行指派。
对特定销售机会制订用户开发计划。
分析用户贡献、用户组成、用户服务组成和用户流失数据，定时提交用户管理汇报。

用户经理：
维护负责用户信息。
接收用户服务请求，在系统中创建用户服务。
处理分配给自己用户服务。
对处理服务进行反馈。
创建销售机会。
对特定销售机会制订用户开发计划。
实施用户开发计划。
对负责流失用户采取“暂缓流失”或“确定流失”方法。

高管：
审查用户贡献数据、用户组成数据、用户服务组成数据和用户流失数据。
2.3 系统功效
系统用例图图1所表示，子用例图及具体用例描述见“功效性需求”部分。

图 1
2.4 当遵照标准或规范
本系统采取Microsoft SQL Server数据库，使用Java EE进行开发，采取B/S架构。数据库设计标准上符合第三范式，且规范，易于维护。
程序需使用MVC模式，采取三层架构，确保系统可维护性和可扩展性。
3 功效性需求
本系统分营销管理、用户管理、服务管理、统计报表、基础数据和权限管理六个模块。
3.1 营销管理
营销管理模块包含销售机会管理和对用户开发过程管理，子用例图图2所表示。

图2
营销过程是开发新用户过程。对老用户销售行为不属于营销管理范围。
用户经理有开发新用户任务，在用户经剪发觉销售机会时，应在系统中录入该销售机会信息。销售主管也能够在系统中创建销售机会。
全部销售机会由销售主管进行分配，每个销售机会分配给一个用户经理。
用户经理对分配给自己销售机会制订用户开发计划，计划好分几步开发，和每个步骤时间和具体事项。
制订完用户开发计划后，用户经理按实际实施请跨功效填写计划中每个步骤实施效果。
在开发计划结束时候，依据开发结果不一样，设置该销售机会为“开发失败”或“开发成功”。
假如开发用户成功，系统自动创建新用户统计。
3.1.1 销售机会管理
3.1.1.1 创建销售机会
3.1.1.1.1 业务概述
见3.1节描述。
3.1.1.1.2 使用者
销售主管、用户经理
3.1.1.1.3 输入要素
创建销售机会系统界面图3所表示。

图 3
创建销售机会时需录入以下信息：
表 1
数据项
说明
输入格式
是否必填
编号
系统自动生成
输入框只读

机会起源

文本

用户名称

文本
是
成功机率
从0到100数字
数字
是
概要
对销售机会简明描述
文本
是
联络人

文本

联络人电话

文本

机会描述

文本
是
创建人
自动填入目前登录用户，用户不可更改
输入框只读
是
创建时间
目前系统时间
输入框只读
是

3.1.1.1.4 处理步骤
从页面获取输入信息，在数据库中创建新统计。
3.1.1.1.5 输出要素
提醒“保留成功”，或汇报对应错误。页面必填项未填时不许可提交表单。
3.1.1.2 修改销售机会
3.1.1.2.1 业务概述
对未分配销售机会统计能够编辑。
3.1.1.2.2 使用者
销售主管、用户经理
3.1.1.2.3 输入要素
在销售机会管理列表页面列出全部状态为“未分配”销售机会统计，可选择一条进行编辑。

图 4
在编辑页面，能够对机会起源、用户名称、成功机率、概要、联络人、联络人电话、机会描述进行编辑。
其它信息不可编辑。

图5
3.1.1.2.4 处理步骤
在列表页面选择“未分配”销售机会进行编辑，跳转到编辑页面；在编辑页面填入更新信息，提交表单，保留新信息到数据库。
3.1.1.2.5 输出要素
提醒“保留成功”，或汇报对应错误。页面必填项未填时不许可提交表单。
3.1.1.3 删除销售机会
3.1.1.3.1 业务概述
状态为“未分配”销售机会能够删除。
删除时需要判定目前登录用户为该销售机会创建人，不然不可删除。
3.1.1.3.2 使用者
销售主管、用户经理
3.1.1.3.3 输入要素
图4所表示，在“未指派”销售机会列表中选择一项删除。
3.1.1.3.4 处理步骤
点选删除操作后应提醒“确定删除？”，用户选“确定”则实施删除操作，不然不实施。
3.1.1.3.5 输出要素
删除成功后提醒“删除成功”。
3.1.1.4 指派销售机会
3.1.1.4.1 业务概述
销售主管依据各用户经理负责分区、行业专长等对销售机会进行指派。
每个销售机会指派给一个用户经理，专事专员。
指派成功后，销售机会状态改为“已指派”。
3.1.1.4.2 使用者
销售主管
3.1.1.4.3 输入要素
进行指派时需要选择输入用户经理，系统自动输入指派时间。两相皆未必输项。

图 6
3.1.1.4.4 处理步骤
选择要指派销售机会，察看销售机会具体信息并选择用户经理进行指派。
3.1.1.4.5 输出要素
指派成功后提醒“指派成功”，该销售机会状态改为“已指派”（即“开发中”）。
3.1.2 用户开发计划
对“已指派”销售机会制订开发计划，实施开发计划，并统计实施结果。用户开发成功还将创建新用户统计。
3.1.2.1 制订开发计划
3.1.2.1.1 业务概述
用户经理对分配给自己销售机会制订开发计划。
3.1.2.1.2 使用者
用户经理
3.1.2.1.3 输入要素
在制订开发计划时，应显示出销售机会具体信息。
用户经理能够经过新建计划项，编辑已经有计划项，即删除计划项来针对一个销售机会来制订用户开发计划。
每个计划项包含两个输入要素：日期和计划内容，全部是必输项。日期输入格式为“-12-13”。
编辑计划项时，日期不能够编辑。

图 7
3.1.2.1.4 处理步骤
首先选择一“已指派”销售机会进行指定计划操作，然后制订计划。
3.1.2.1.5 输出要素
提交并更新目前页面时在计划项列表中显示新建计划项。
3.1.2.2 实施开发计划
3.1.2.2.1 业务概述
完成用户开发计划制订后，用户经理开始根据计划内容实施用户开发计划，并按时统计实施结果。
3.1.2.2.2 使用者
用户经理
3.1.2.2.3 输入要素
对每个计划项填写实施效果，并保留。

图 8

3.1.2.3 开发成功
3.1.2.3.1 业务概述
某个用户开发计划实施过程中或实施结束后假如用户同意购置企业产品，已经下订单或签署销售协议，则标志用户开发成功。
用户开发成功时，需修改销售机会状态为“开发成功”。并依据销售机会中对应信息自动创建用户统计。
3.1.2.3.2 使用者
用户经理
3.1.2.3.3 输入要素
从列表中选择一个状态为“已指派”销售机会，点选“开发成功”操作。
或在实施计划页面点选“开发成功”操作。
3.1.2.3.4 处理步骤
修改销售机会状态为“开发成功”。
依据销售机会中对应信息（包含用户名称、联络人和联络人电话）自动创建用户统计。
3.1.2.3.5 输出要素
操作成功后提醒“操作成功”。

3.1.2.4 开发失败
3.1.2.4.1 业务概述
某销售机会在确定用户确实没有采购需求后，或不含有开发价值时可认为“开发失败”。
3.1.2.4.2 使用者
用户经理
3.1.2.4.3 输入要素
从列表中选择一个状态为“已指派”销售机会，点选“终止开发”操作。
或在实施计划页面点选“终止开发”操作。
3.1.2.4.4 处理步骤
修改销售机会状态为“开发失败”。
3.1.2.4.5 输出要素
操作成功后提醒“操作成功”。

3.2 用户管理
用户信息是企业资产组成部分之一，应对其进行妥善保管、充足利用。
每个用户经理有责任维护自己负责用户信息，随时更新。在本系统中，用户信息将得到充足共享，从而发挥最大价值。
有调查表明，企业大部分利润来自老用户，开发新用户成本相对较高而且风险相对较大。所以我们有必需对超出6个月没有购置企业产品用户应给予特殊关注，预防现有用户流失。
用户管理子用例图图9所表示。

图 9
3.2.1 用户信息管理
3.2.1.1 编辑用户信息
3.2.1.1.1 业务概述
用户经理能够编辑状态为“正常”用户信息。
3.2.1.1.2 使用者
用户经理
3.2.1.1.3 输入要素
以下图所表示，有“*”标识为必输项。地域、用户等级候选项由数据字典维护；用户经理候选项为全部状态为“正常”系统用户。用户满意度和用户信用度候选项值全部是1~5。

图 10
3.2.1.1.4 处理步骤
从列表中选择要编辑用户点选“编辑”按钮，编辑特定用户信息，输入新信息后点“保留”按钮，返回列表页面。
3.2.1.1.5 输出要素
提醒“保留成功”或汇报错误。
3.2.1.2 管理用户联络人
3.2.1.2.1 业务概述
每个用户能够有多个联络人。

图 11
3.2.1.2.2 使用者
用户经理
3.2.1.2.3 输入要素
新建联络人时要输入姓名、性别、职位和办公电话，必输。还可输入手机号码和备注信息。
注意：联络人是属于某个用户。

图表 2
编辑联络人时姓名、性别、职位和办公电话为必输项。

图表 3
3.2.1.2.4 处理步骤
选择一个用户，显示其全部联络人列表，从中选择进行编辑或删除操作，还能够给该用户添加联络人。
3.2.1.2.5 输出要素
用户联络人信息。
3.2.1.3 管理用户交往统计
3.2.1.3.1 业务概述
系统能够保留每个用户交往统计。

图表 4
3.2.1.3.2 使用者
用户经理
3.2.1.3.3 输入要素
用户经理完成用户服务后，需统计和用户交往内容，尤其是里程碑事件或有重大影响事件。
添加一个用户交往统计时需要统计事件发生日期、地点、概要和具体信息，还能够填写一个备注信息。

图表 5
交往统计能够修改。但必输项不能修改为空。

图表 6
3.2.1.3.4 处理步骤
首先选择一个用户，然后针对这个用户维护交往统计信息。
3.2.1.3.5 输出要素
用户交往统计数据。
3.2.1.4 查看用户历史订单
3.2.1.4.1 业务概述
用户历史订单数据是一个用户关键信息。本系统中不提供订单管理功效。订单数据需要从销售系统中读取。读取时只读取订单状态为“已发货”或“已回款”数据（对应订单统计状态为5或6）。
3.2.1.4.2 使用者
用户经理
3.2.1.4.3 输入要素
本系统依据用户展示历史订单。
3.2.1.4.4 处理步骤
首先选择一个用户，然后查看这个用户历史订单，再选择一条历史订单查看订单明细。
3.2.1.4.5 输出要素
针对某一用户显示其全部已发货或已回款历史订单，分页显示，最新订单显示在前面。需要在列表中显示订单编号、下单日期、送货地址、订单状态。

图表 7
对每个订单能够查看明细。在订单明细中需要显示订单总金额。显示样式以下图所表示。

图表 8
3.2.2 用户流失管理
系统将对超出6个月没有购置行为。
3.2.2.1 用户流失预警
3.2.2.1.1 业务概述
系统自动检验超出6个月没有下单用户，并在本系统中提出预警。订单数据需要从销售系统中取得。
3.2.2.1.2 使用者
用户经理
3.2.2.1.3 输入要素
本功效由后台程序完成，没有输入界面。
3.2.2.1.4 处理步骤
每七天六凌晨02：00系统自动检验订单数据，假如发觉有超出6个月没有下单用户，则自动添加一条用户流失预警统计。
用户经理登录本系统后在用户流失管理中就能够看到。

图表 9
对用户流失预警能够采取“暂缓流失”和“确定流失”两种方法。但在确定流失前一定要采取方法“暂缓流失”。
3.2.2.1.5 输出要素
用户流失预警统计。
3.2.2.2 暂缓用户流失
3.2.2.2.1 业务概述
对于系统自动产生用户流失预警，负责该用户用户经理要第一时间采取方法，充足了解用户流失原因，并采取应对方法。然后在系统中使用“暂缓流失”功效点，填写采取方法。
3.2.2.2.2 使用者
用户经理
3.2.2.2.3 输入要素
暂缓方法能够不停追加，系统要保留每次追加暂缓方法。

图表 10
3.2.2.2.4 处理步骤
选择用户流失预警统计，追加暂缓方法。
3.2.2.2.5 输出要素
系统保留每次追加暂缓方法。
3.2.2.3 确定用户流失
3.2.2.3.1 业务概述
假如确是存在不可逆转原因，用户不可能再购置本企业产品，则确定该用户流失。
3.2.2.3.2 使用者
用户经理
3.2.2.3.3 输入要素
在确定用户流失时要填写用户流失原因。

图表 11
3.2.2.3.4 处理步骤
选择一条用户流失预警，填写用户流失原因，确定用户流失。
3.2.2.3.5 输出要素
确定用户流失后，该用户状态修改为“已流失”。
3.3 服务管理

图
处理步骤

图

3.3.1 服务创建
3.3.1.1 业务概述
用户服务是用户管理关键工作。经过用户服务我们销售团体能够立即帮助用户处理问题、打消顾虑，提升用户满意度。还能够帮助我们随时了解用户动态，方便采取应对方法。
3.3.1.2 使用者
用户经理
3.3.1.3 输入要素
当用户收到用户服务请求时候，要创建一条服务单据。服务单据录入界面以下图所表示。
服务编号由系统自动生成；服务类型由数据字典维护，选择输入；创建人为目前登录用户；创建时间为目前系统时间。

图表 12
3.3.1.4 处理步骤
服务添加成功后仍返回服务创建页面，显示空表单准备填写下一条服务。
3.3.1.5 输出要素
添加成功服务数据，状态为“新创建”。
3.3.2 服务分配
3.3.2.1 业务概述
销售主管对状态为“新创建”服务单据进行分配，专事专管。
3.3.2.2 使用者
销售主管
3.3.2.3 输入要素
分给对象经过选择输入，候选项包含全部状态为“正常”系统用户。

图表 13
3.3.2.4 处理步骤
选择一条状态为“新创建”服务单据，分配给专员。
3.3.2.5 输出要素
服务分配给专员后，服务单据状态修改为“已分配”。需要统计分配时间。
3.3.3 服务处理
3.3.3.1 业务概述
被分配处理服务用户经理负责对服务请求做出处理，并在系统中录入处理方法。
3.3.3.2 使用者
用户经理
3.3.3.3 输入要素
填写处理方法，系统自动统计处理人和处理时间。

图表 14
3.3.3.4 处理步骤
首先查询得到状态为“已分配”服务单据，选择一个进行处理。

图表 15
填写处理方法后提交。
3.3.3.5 输出要素
处理完成服务单据状态改为“已处理”。
3.3.4 服务反馈
3.3.4.1 业务概述
对状态为“已处理”服务单据主动联络用户进行反馈，填写处理结果。
3.3.4.2 使用者
用户经理
3.3.4.3 输入要素
需要填写处理结果，并选择用户对服务处理满意度。用户满意度为1~5值。

图表 16
3.3.4.4 处理步骤
首先查询得到状态为“已处理”服务单据，选择一个进行反馈。

图表 17
填写处理结果和满意度后提交。
3.3.4.5 输出要素
依据用户满意度不一样，服务单据流转也不一样。
假如用户满意度大于等于3，服务单据状态改为“已归档”。
假如服务满意度小于3，服务状态改为“已分配”，重新进行处理。
3.3.5 服务归档
3.3.5.1 业务概述
系统能够对已归档服务进行查询、查阅。便于参考处理类似问题。
3.3.5.2 使用者
用户经理、销售主管
3.3.5.3 输入要素
能够依据用户、概要、服务类型、创建日期进行查询。对每条服务单据还能够查看明细。

图表 18
3.3.5.4 处理步骤
3.3.5.5 输出要素
服务单据信息。

图表 19
3.4 统计报表

图
3.4.1 用户贡献分析
3.4.1.1 业务概述
对用户下单总金额进行统计，了解用户对企业贡献。
3.4.1.2 使用者
销售主管、高管
3.4.1.3 输入要素
能够依据用户名称或年份查询，默认列出全部用户和全部年份订单金额总和。
3.4.1.4 处理步骤
3.4.1.5 输出要素
显示用户名称和该用户下单总金额。

图表 20

3.4.2 用户组成份析
3.4.2.1 业务概述
了解某种类型用户有多少及所占百分比。
3.4.2.2 使用者
销售主管、高管
3.4.2.3 输入要素
能够选择报表方法，按用户等级统计、按信用度统计或按满意度统计。
3.4.2.4 处理步骤
3.4.2.5 输出要素
列出统计项，和该统计项下有多少个用户。

图表 21

3.4.3 用户服务分析
3.4.3.1 业务概述
依据服务类型对服务进行统计。
3.4.3.2 使用者
销售主管、高管
3.4.3.3 输入要素
能够输入年份，只统计该年服务数据。
3.4.3.4 处理步骤
3.4.3.5 输出要素

图表 22
3.4.4 用户流失分析
3.4.4.1 业务概述
查看已经确定流失用户流失统计。
3.4.4.2 使用者
销售主管、高管
3.4.4.3 输入要素
能够依据用户名称和用户经理名称进行查询。
3.4.4.4 处理步骤
3.4.4.5 输出要素
列出符合查询条件已经确定流失用户流失统计。

图表 23
3.5 基础数据

图
3.5.1 数据字典管理
3.5.1.1 业务概述
对系统中需要已选择方法输入输入项候选项，统一经过数据字典来配置。比如服务类型、用户等级等。
3.5.1.2 使用者
系统管理员
3.5.1.3 输入要素
每个数据字典项包含系统自动生成编号、类别（如：服务类型）、条目（如：咨询）和值（如：1）组成。
数据字典项有能编辑。有不可编辑，只能查看。

图表 24
对于能够编辑数据字典项，能够修改其类别、条目和值。还能够设为不可编辑。

图表 25
在数据字典项列表中，对可编辑数据字典项显示“编辑”和“删除”操作按钮。

图表 26
3.5.1.4 处理步骤
3.5.1.5 输出要素
数据字典数据。
3.5.2 查询产品数据
3.5.2.1 业务概述
本系统中没有产品数据，需要从销售系统中取得。
3.5.2.2 使用者
用户经理
3.5.2.3 输入要素
能够依据产品名称、型号、批次进行查询。
3.5.2.4 处理步骤
3.5.2.5 输出要素
列出符合查询条件产品信息。

图表 27
3.5.3 查询库存
3.5.3.1 业务概述
为了处理用户服务需要，本系统需要从销售系统中读取并查询库存数据。
3.5.3.2 使用者
用户经理
3.5.3.3 输入要素
能够依据产品和仓库进行查询。
3.5.3.4 处理步骤
3.5.3.5 输出要素
列出符合查询条件库存统计。

图表 28

3.6 权限管理
参见权限管理系统需求规格说明书。
4 非功效性需求
4.1 技术需求
4.1.1 软硬件环境需求
系统应可运行于Windows平台或Unix平台（数据库服务器运行于Windows平台）。
系统采取B/S架构，可经过浏览器访问，使用IE6.0或更高版本可顺利完成全部系统操作。
系统运行于局域网环境中。
系统采取Java SDK版本为6.0（或更高版本）。
系统数据库使用MS SQL Server （或更高版本）。
系统需要和X企业销售系统集成，访问其产品、库存和订单数据。
4.1.2 性能需求
本系统在正常网络环境下，应能够确保系统立即响应：
统计报表模块对应功效响应时间不超出30秒。
其它模块对应功效响应时间不超出15秒。
4.1.3 安全保密需求
本系统系统架构，和权限机制能够确保系统安全性。
首先，从系统架构看，本系统采取B\S模型，从而使服务器数据源和用户端分离，确保了数据物理独立性；
其次，本系统用户授权机制经过角色定义管理实现，经过定义一些角色能进行操作权限，和定义用户拥有角色，限定用户操作权限，实现对用户授权。
4.1.4 可维护性和可扩展性
本系统应用平台设计中选择B/S结构，采取基于JAVA技术而且符合Java EE开发规范系统应用平台，并采取三层结构，使系统含有良好可维护性和可扩展性
4.2 文档需求
4.2.1 文档清单
交付验收时需交付文档清单：
《需求规格说明书》
《概要设计说明书》
《具体设计说明书》
4.2.2 用户手册
5 验收标准
人力资源管理系统验收标准为：
Ø 实现全部功效需求
Ø 满足非功效性需求
Ø 系统设计文档完整，且符合规范
Ø 代码符合规范，且和系统设计一致
6 附录
附录A：系统原型
Demo.zip。