客户关系管理系统需求说明书

客户关系治理系统需求讲明书
名目
1 概述
1.1 编写目的
客户是公司最宝贵的资源，为了更好的开掘老客户的价值，并开发更多新
客户，公司实施客户关系治理系统。

系统的功能是：通过那个系统完成对职员
全然信息、客户全然信息、交往信息、客户效劳信息的充分共享和标准化治理；通过对销售时机、客户开发过程的追踪和记录，提高新客户的开发能力；在客
户将要流失时系统及时预警，以便销售人员及时采取措施，落低损失。

客户效劳是一个涉及多个部门，存在一定流程的工作。

客户效劳水平的上
下决定着公司的核心竞争力。

该客户关系治理系统提供一个客户效劳在线平台，使客户效劳处理过程中的相关人员能够在线完成效劳的处理和记录工作。

1.2 读者对象
此文档针对各种不同的预期读者，要紧包括一下人员：
1）系统用户；
2）系统开发人员；
3）工程经理；
4）营销人员；
5）测试人员；
6）文档编写人员。

1.3 术语和缩写
1.4 参考资料
无
2 系统总体设计
2.1 总体功能结构图
图系统功能结构图
2.2 开发及运行环境
硬件平台：
❑CPU：i3及以上版本；
❑内存：1GB以上。

软件平台：
❑操作系统：Windowsxp/Windows7；
❑数据库：SQLServer2000；
❑扫瞄器：IE6.0，推举使用IE8.0；
❑Web效劳器：IIS6.0；
❑分辨率：最正确效果1024*768。

2.3 数据库设计
本系统数据库采纳SQLServer2021数据库，系统数据库名称为db_System。

数据库db_System。

3 功能设计
3.1 市场营销
图市场营销治理系统框架
营销治理系统包含销售时机治理系统和对客户开发过程的治理两大模块，具体框架如图2所示。

1〕营销的过程是开发新客户的过程。

客户经理有开发新客户的任务，在客户经理发觉销售时机时，应在系统中录进该销售时机的信息。

销售主管也能够在系统中创立销售时机。

2〕所有的销售时机由销售主管进行分配，每个销售时机分配给一个客户经理。

3〕客户经理对分配给自己的销售时机制定客户开发方案，方案开发步骤，以及每个步骤的时刻和具体事项。

4〕制定完客户开发方案后，客户经理按实际执行情况和功能填写方案中每步应该执行的效果。

5〕在开发方案结束的时候，依据开发的结果不同，设置该销售时机为“开发失败〞或“开发成功〞〔假设开发成功，需评估成功几率〕。

6〕假如开发客户成功，系统自动创立新的客户记录。

3.1.1 销售时机治理
图销售时机治理系统流程图
系统治理员：设置系统登录权限存储到数据库；
用户：输进验证信息，用户信息与数据库信息匹配，那么登录成功，否那么提示：非法用户。

销售主管，客户经理可登录销售时机治理界面进行相关操作。

3.1.1.1 创立销售时机
3.1.1.1.1 业务概述
客户经理有开发新客户的任务，在客户经理发觉销售时机时，应在系统中录进该销售时机的信息。

销售主管也能够在系统中创立销售时机。

3.1.1.1.2 使用者
销售主管、客户经理
3.1.1.1.3 输进要素
创立销售时机所需信息：
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 输进要素
在编辑页面，能够对时机来源、客户名称〔必填〕、成功机率〔必填〕、
概要〔必填〕、联系人、联系人、时机描述〔必填〕，创立时刻〔必填〕，创
立人〔必填〕进行编辑。

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 输进要素
在“未指派〞的销售时机列表中选择一项删除。

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 输进要素
进行指派时需要选择输进客户经理，系统自动输进指派时刻。

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 输进要素
在制定开发方案时，应显示出销售时机的具体信息。

客户经理能够通过新建方案项，编辑差不多有的方案项，即删除方案项来针对一个销售时机来制定客户开发方案。

每个方案项包括两个输进要素：日期和方案内容〔必填〕。

日期的输进格式为“2011-7-1〞。

编辑方案项时，日期不能够编辑。

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 输进要素
对每个方案项填写执行效果，并保留。

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个月没有购置公司产品的客户应予以特殊关注，防止现有客户流失。

图客户治理系统框架图
3.2.1 客户信息治理
图客户信息治理流程图
3.2.1.1 编辑客户信息
3.2.1.1.1 业务概述
客户经理能够编辑状态为“正常〞的客户信息。

3.2.1.1.2 使用者
客户经理
3.2.1.1.3 输进要素
地区、客户等级的候选项由数据字典维护；客户经理候选项为所有状态为“正常〞的系统用户。

客户满足度和客户信用度候选项的值基本上1~5。

从列表中选择要编辑的用户点选“编辑〞按钮，编辑特定客户的信息，输
进新信息后点“保留〞按钮，返回列表页面。

3.2.1.1.5 输出要素
提示“保留成功〞或报告错误。

3.2.1.2 治理客户联系人
3.2.1.2.1 业务概述
每个客户能够有多个联系人。

3.2.1.2.2 使用者
客户经理
3.2.1.2.3 输进要素
新建联系人时要输进姓名、性不、职位和办公，必输。

还可输进号码和备
注信息。

注重：联系人是属于某个客户的。

编辑联系人时姓名、性不、职位和办公为必输项。

3.2.1.2.4 处理流程
选择一个客户，显示其所有联系人的列表，从中选择进行编辑或删除操作，还能够给该客户添加联系人。

客户的联系人信息。

3.2.1.3 治理客户交往记录
3.2.1.3.1 业务概述
系统能够保留每个客户的交往记录。

3.2.1.3.2 使用者
客户经理
3.2.1.3.3 输进要素
客户经理完成客户效劳后，需记录和客户交往的内容，特殊是里程碑事件或有重大妨碍的事件。

添加一个客户交往记录时需要记录事件发生的日期、地点、概要和具体信息，还能够填写一个备注信息。

交往记录能够修改。

但必输项不能修改为空。

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 输出要素
针对某一客户显示其全部已发货或已回款的历史订单，分页显示，最新的订单显示在前面。

需要在列表中显示订单的编号、下单日期、送货地址、订单状态。

对每个订单能够查瞧明细。

在订单明细中需要显示订单的总金额。

显示样式如以下图所示。

3.2.2 客户流失治理
图客户流失治理流程图
系统将对超过6个月没有购置行为的。

3.2.2.1 客户流失预警
3.2.2.1.1 业务概述
系统自动检查超过6个月没有下单的客户，并在本系统中提出预警。

订单数据需要从销售系统中获得。

3.2.2.1.2 使用者
客户经理
3.2.2.1.3 输进要素
本功能由后台程序完成，没有输进界面。

每周六凌晨02：00系统自动检查订单数据，假如发觉有超过6个月没有下单的客户，那么自动添加一条客户流失预警记录。

客户经理登录本系统后在客户流失治理中就能够瞧到。

对客户流失预警能够采取“暂缓流失〞和“确认流失〞两种措施。

但在确认流失前一定要采取措施“暂缓流失〞。

3.2.2.1.5 输出要素
客户流失预警记录。

3.2.2.2 暂缓客户流失
3.2.2.2.1 业务概述
关于系统自动产生的客户流失预警，负责该客户的客户经理要第一时刻采取措施，充分了解客户流失的缘故，并采取应对措施。

然后在系统中使用“暂缓流失〞功能点，填写采取的措施。

3.2.2.2.2 使用者
客户经理
3.2.2.2.3 输进要素
暂缓措施能够不断追加，系统要保留每次追加的暂缓措施。

3.2.2.2.4 处理流程
选择客户流失预警记录，追加暂缓措施。

系统保留每次追加的暂缓措施。

3.2.2.3 确认客户流失
3.2.2.3.1 业务概述
假如确是存在不可逆转的因素，客户不可能再购置本公司的产品，那么确认该客户的流失。

3.2.2.3.2 使用者
客户经理
3.2.2.3.3 输进要素
在确认客户流失时要填写客户流失的缘故。

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 输进要素
当客户经理收到客户效劳请求的时候，要创立一条效劳单据。

效劳单据录进内容如以下图所示。

效劳编号由系统自动生成；效劳类型由数据字典维护，选择输进；创立人为当前登录用户；创立时刻为当前系统时刻。

3.3.1.4 处理流程
效劳添加成功后仍返回效劳创立页面，显示空表单预备填写下一条效劳。

3.3.1.5 输出要素
添加成功的效劳数据，状态为“新创立〞。

3.3.2 效劳分配
3.3.2.1 业务概述
销售主管对状态为“新创立〞的效劳单据进行分配，专事专管。

3.3.2.2 使用者
销售主管
3.3.2.3 输进要素
分给的对象通过选择输进，候选项包括所有状态为“正常〞的系统用户。

3.3.2.4 处理流程
选择一条状态为“新创立〞的效劳单据，分配给专人。

3.3.2.5 输出要素
效劳分配给专人后，效劳单据的状态修改为“已分配〞。

需要记录分配时刻。

3.3.3 效劳处理
3.3.3.1 业务概述
被分配处理效劳的客户经理负责对效劳请求做出处理，并在系统中录进处理的方法。

3.3.3.2 使用者
客户经理
3.3.3.3 输进要素
填写处理的方法，系统自动记录处理人和处理时刻。

3.3.3.4 处理流程
首先查询得到状态为“已分配〞的效劳单据，选择一个进行处理。

填写处理方法后提交。

3.3.3.5 输出要素
处理完成的效劳单据状态改为“已处理〞。

3.3.4 效劳相应
3.3.
4.1 业务概述
对状态为“已处理〞的效劳单据主动联系客户进行相应，填写处理结果。

3.3.
4.2 使用者
客户经理
需要填写处理结果，并选择客户对效劳处理的满足度。

客户满足度为1~5的值。

3.3.
4.4 处理流程
首先查询得到状态为“已处理〞的效劳单据，选择一个进行相应。

填写处理结果和满足度后提交。

3.3.
4.5 输出要素
依据客户满足度不同，效劳单据的流转也不同。

假如客户满足度大于等于3，效劳单据状态改为“已回档〞。

假如效劳满足度小于3，效劳状态改为“已分配〞，重新进行处理。

3.3.5 效劳回档
3.3.5.1 业务概述
系统能够对已回档的效劳进行查询、查阅。

便于参考解决类似咨询题。

3.3.5.2 使用者
客户经理、销售主管
3.3.5.3 输进要素
能够依据客户、概要、效劳类型、创立日期进行查询。

对每条效劳单据还能够查瞧明细。

效劳单据信息。

4 系统内容分析
4.1 信息内容
本系统的信息内容包括：公司人事信息，客户信息，客户交往信息，客户
效劳信息。

这些信息内容要紧对比稳定，变动的时机小。

4.2 业务内容
营销治理业务涉及到内容：编号，时机来源，客户名称，成功几率，概要，联系人，联系，时机描述，创立人，创立时刻。

客户治理业务涉及到内容：客户编号，名称，地区，客户经理，客户等级，客户满足度，客户信用度，地址，邮政编码，，，网址，营业执照注册号，法人，注册资金，年营业额，开户银行，开户帐号，地税登记号，国税登记号。

效劳治理业务涉及到内容：编号，效劳类型，概要，客户，状态，效劳请求，创立人，创立时刻。

4.3 内容存储
系统涉及到的全然信息存储在数据库。

系统的业务流程处理中涉及到的各种状态存储在数据库。

4.4 数据字典
参考?数据字典?
5 系统功能分析
5.1总体功能分析
客户关系治理分为以下三大模块：市场营销治理，客户治理，效劳治理。

每个大模块分不包含各自的自模块。

6 用户界面分析
提供友好方便的操作界面及联机讲明，支持图形用户界面和扫瞄器界面。

整个页面分为三个局部：
名称：top，页面顶层，用于展示软件的名称、LOGO等；
名称：left，页面左部，导航栏局部，显示两大模块及各模块的相关子菜单；
名称：main，页面的要紧内容，通过导航栏链接显示具体信息〔见具体设计〕。

1、单击页面left局部的四模块之一，将展开显示其各模块所包含的内容链接；
2、点击内容链接，将在页面的main局部显示其对应的页面；
3、在页面main局部，依据需要进行选择或点击等操作
整个结构清楚，轻易操作，Main局部采纳列表和具体信息相结合的方式来表达。

7 系统接口分析
本系统有两个外部接口：
1.OA接口。

2.知识库接口。

3.统一用户库接口，要紧提供客户信息。

本系统有一个内部接口
1.效劳接口，要紧提供客服与销售系统对接效劳。

8 系统性能分析
性能需求能够同时答应100并发，系统响应时刻8秒以内。

9 系统环境分析
网络环境：可在已建立的公司局域网上运行，基于以TCP/IP传输协议为根底的数据联网模式。

数据库效劳器：SqlServer2021
效劳器操作系统平台：WINSERVER2021
10 系统平安分析
10.1 应用级平安操纵
应用级平安操纵要求保卫合法用户对数据的合法存取，重点解决数据平安
咨询题，并制定可操作性及平安性较强的全面的数据备份及恢复策略。

10.2 系统级平安操纵
要紧指效劳器、操作系统一级的平稳定义。

重点解决系统平安咨询题。

定
义效劳器、操作系统以及数据库等系统平安要求。

10.2.1 网络级平安操纵
保卫网络效劳的可用性，重点解决网络平安咨询题。

定义系统局域网和广
域网的平安性要求，制定网络平安访咨询的平安策略，明确防火墙的平安级不、用户访咨询操纵、网络数据加密和解密、用户认证等方面的平安策略。

系统的主机应放在防火墙之后，以防止非法网络用户的攻击。

11 信息字典。