企业官网建设流程全解析

简介：《客户关系管理CRM-客户管理-PRD-V1.0-20170825.pdf》是一份由蜂网供应链管理（上海）有限公司于2017年发布的软件需求说明书，编写人为周旭丽，面向CRM产品经理、需求分析师、开发与测试人员，用于指导客户管理模块从需求梳理到落地上线的全过程。文档覆盖项目背景、目标顾客、平台政策、竞品分析及方案概述，系统展开客户档案、联系人跟踪、销售漏斗、市场营销自动化、客户服务等核心功能，并补充数据集成、移动支持、安全性、性能等非功能要求；同时包含名词解释、业务用例、功能列表、业务流程与变更记录，可作为需求评审、开发排期、验收测试及后续迭代的参考基线。资源为单个PDF文件，压缩包大小约3.11MB，目录完整、可直接按章节查阅。目前已有314人浏览学习，适合需要借鉴规范需求文档结构、搭建CRM客户管理功能框架或梳理客户全生命周期管理的产品与研发人员。

1. 这是一份什么文档：CRM客户管理PRD的边界与价值

拿到一份文件名带版本号和日期的客户关系管理CRM文档，很多人第一反应是“历史存档，翻翻就算了”。但做过系统改造的从业者都知道，客户关系管理CRM产品的第一份PRD，十有八九是从客户管理模块写起的。这份V1.0的客户管理PRD，定义的是整个CRM最底层的地基：客户档案长什么样、数据归谁所有、没有归属的客户怎么流转、重复数据怎么拦下来。它不解决营销活动怎么投放，也不管订单回款怎么算，只回答一个问题——客户这个核心对象在系统里怎么被创建、分配、跟进和回收。适合产品经理、后端研发、测试和CRM实施顾问读，尤其是后端，评审会上最需要靠它对齐数据模型和状态机。

2. 客户管理模块的范围拆解：从哪里开始画第一版边界

写客户管理PRD的第一件事不是填字段，而是把“客户”这两个字圈出边界。很多团队在这里翻车，要么把范围画得太大，把商机、订单、回款全塞进来，V1.0做了半年上不了线；要么画得太小，只做一张客户登记表，上线之后销售说“这跟Excel有什么区别”。客户管理的边界，应该是围绕客户对象自身的生命周期来画的：从进入到归属、从跟进到回收、从重复到合并。这块画清楚了，后面每一条规则才有地方挂。

2.1 客户管理的对象模型：客户、联系人与商机的三角关系

最常见的错误，是以为客户管理就是“一张客户表加一张跟进记录表”。实际做下来，最基础的对象模型至少是客户、联系人两张表，商机可以放V2.0，但客户和联系人必须在一开始就拆开。客户的粒度是“一家公司”，联系人的粒度是“这家公司里的一个人”。一家公司有多个决策人，如果联系人字段直接做在客户表里，销售跟进的时候会痛苦不堪。

我一般会在PRD里用一张极简的表结构来定调，让研发一眼看懂要建几张表：

V1.0只做客户和联系人，商机表留出接口但不在本期实现，这个决定要写在文档开头。原因很实际：客户管理的核心是把“有没有客户、客户是谁的、跟进了没有”先跑通，商机的漏斗分析是建立在客户数据稳定之后的第二层需求。对象模型定了，字段才能跟着定，否则后面每加一张表，就要改一遍归属和权限逻辑。

2.2 字段的取舍：V1.0 必须有的三组字段与两组预留

客户管理PRD里最容易被评审挑战的就是字段清单。销售提需求的时候会说出二十个字段，管理层可能又加五个，如果照单全收，录入成本高，数据质量必然崩。我的经验是V1.0只保留三组字段，用一张字段表写清楚，超出范围的一律进预留。

两组预留是自定义字段组和标签字段。自定义字段组让实施顾问在现场能加字段而不改代码；标签字段用来支持临时的市场活动分组，比如“展会渠道”“老客户转介绍”都可以用标签打，不需要单独建字段。这样做的理由是：字段一旦上线，历史数据清洗的成本远大于开发成本，能少做就少做。

2.3 客户分级的逻辑：打分模型还是手动等级

客户等级是客户管理模块绕不开的设计点。分级怎么定，直接决定了公海回收规则和销售的资源分配策略。这里有两套方案，我在PRD里习惯用对比表把结论直接写死，避免评审会上反复掰扯。

V1.0我建议用手动等级，而且只分A、B、C三级，加上一个“最后跟进时间”做兜底判断。理由很直白：打分模型需要历史数据回归出权重，一个新系统根本没有数据可供训练，这时候硬做一个打分模型，参数全是拍脑袋定的，上线后销售也不信。手动等级虽然土，但销售填了就是自己认的，后续公海回收规则可以直接按等级设不同的天数，比一个复杂的模型更容易让业务理解和接受。

3. 把 PRD 写成可落地的规格：文档结构与关键章节的写法

范围定完之后，PRD的正文怎么写，决定研发和测试能不能照着干活。这一章不讲概念，直接给可抄作业的写法。客户管理PRD和其它后台系统PRD不一样的地方在于：它的大部分需求不在页面设计，而在业务规则和异常分支。所以文档的重心要放在用户故事、规则表和权限矩阵上，页面原型反而是辅助。

3.1 需求背景与用户故事怎么写才不空

很多PRD的需求背景写的是“为了提升销售效率、加强客户管理”，这等于没写。研发看完只会觉得你要他做一个“客户信息的增删改查”。我一般会在文档开头用一段具体场景把问题钉死，比如：

某销售团队目前用表格管理客户，客户列表分散在多个工作表里，员工离职后客户跟着邮件走，超过两个月没跟进的客户没有任何人接管。销售总监每月要花两天时间人工统计谁在跟哪些客户、哪些客户已经失联。目标是在系统上线后，每个客户会自动归属到唯一负责人，超过设定天数未跟进的客户自动回到公海，由其他人继续跟进。

这段写完之后，研发能理解自己做的每个功能是干什么用的。用户故事也要写具体，不要写“作为销售，我希望管理系统”。我习惯拆成三个角色：销售、销售总监、系统管理员，每个角色给一个带业务诉求的故事。销售关心的是“我新增的客户不会被人抢走”，销售总监关心的是“客户不要死在个别人手里”，管理员关心的是“离职交接不用导出再导入”。这三条写清楚，整个模块的功能列表就自然出来了，不用硬凑需求。

3.2 业务规则表：分配、认领、回收、公海的四条主线

客户管理的业务规则，是整份PRD里研发最依赖的部分。这里建议直接用表格把规则列出来，每条规则写清楚触发时机、条件、动作和默认分支。最容易被漏掉的是默认分支，也就是条件都不满足的时候系统怎么办。

每条规则后面还要写正常分支和异常分支。自动分配的正常分支是分配给一个符合条件的人；异常分支是当时没有在线销售，那么客户保留在公海，状态不变，并记录一条分配失败日志。这个日志在排障的时候非常有用，不加的话，出问题只能翻代码找黑匣子。手动认领的异常分支是两个销售同时点了认领，要写清楚用更新时间戳做先到先得，而不是让数据库随机报错。

3.3 数据字典与权限矩阵的呈现方式

数据字典是研发建表和测试写用例的直接依据，用文字描述会逼着研发去猜。最好直接给字段定义表，逐字段过一遍，我一般把表放在文档的附录位置，但在评审前单独拉出来一起过。

权限矩阵按对象和操作来画，而不是按部门来画。行是角色，列是操作：查看、新建、编辑、转移、删除。客户管理V1.0的权限矩阵只要四行三组就够：老板看全部，销售总监看本团队，销售看自己和公海，客服只看被分配给他的客户。删除权限这一列，V1.0建议除了系统管理员，其它角色全部置灰。客户数据删了没有后悔药，做软删除比放开删除权限划算得多。

4. 从 PRD 到实现的参数设计：客户管理模块的三个必调参数

PRD写得再细，到了开发阶段，还是会有一堆参数等着定。客户管理模块的核心参数集中在三个地方：分配规则、去重合并、列表页默认行为。这几个参数定不好，后面上线运维会一直被业务投诉。我在这个环节的建议是：所有参数必须在PRD里给出默认值，而不是写“可配置”三个字就完事，“可配置”意味着没人配置，最后按代码里的写死值运行。

4.1 客户分配规则：按什么条件、什么时候自动分配

分配规则参数是销售最敏感的东西，直接关系到业绩归属。参数包括分配时机、分配模式、分配上限、分配优先级。

这块常见的翻车点是只做轮询不做上限。轮询本身逻辑简单，但如果没有上限，老销售名下的客户会堆到几千个且大都不活跃，新销售拿不到客户，公海规则也形同虚设。另一个坑是分配时的并发控制，两个定时任务同时扫到同一个客户，必须用数据库行锁或者唯一索引兜底，否则会出现一个客户同时归两个人的脏数据。

4.2 去重合并策略：匹配规则与操作权限

客户管理模块上线三个月后，数据质量的问题一定会爆发，核心就是重复客户。重复的来源很多：销售手动导入一次、公海认领时又新建了一个、移动端录入名称不统一。去重不做，后面所有统计都是错的。

去重策略建议分两层。第一层是自动拦截：新建客户时按统一社会信用代码做精确匹配，匹配到了直接提示“该客户已存在，归属人为某某，是否申请转移”。第二层是人工合并：客户名称做模糊匹配，把可能是同一个客户的列表推送给管理员，由管理员人工确认合并。

合并的参数也要定义清楚：主记录保留哪个、被合并记录的跟进记录要不要带过去、字段冲突时以谁为准。我的默认方案是：主记录选创建时间早的那一条，被合并记录的跟进行为在合并后统一挂到主记录下，归属人取最近一次有跟进行为的销售。这个方案不算最优，但它是业务最容易接受的——不冤枉任何一个有实际跟进的销售。

4.3 列表页与筛选条件的默认参数

列表页是所有用户每天打开次数最多的页面，它的默认参数虽然不起眼，但直接影响用户对系统快慢和好用程度的感受。研发经常把列表页做成简单的全表查询，上线后销售一打开就加载几千条数据，翻好几页才能找到自己正在跟的客户。

我建议PRD里明确规定列表页的默认行为：

这里要特别提一下“我的客户”这个默认筛选。很多客户管理项目上线后被销售抵制，原因之一就是打开列表看到所有客户的手机号，谁都能看到，销售就不敢录真人数据了。按归属人隔离，是保住数据真实性的第一道防线。

5. 客户管理 PRD 的五个常见坑与排查清单

这部分是血泪经验汇总。以下几类问题在我评审过的客户管理需求里反复出现，每一条都对应着一个上线后要返工的事故。写PRD阶段多花十分钟检查，能省掉开发阶段好几天的返工。

5.1 坑一：把「联系人」并进「客户」，审核时才发现丢数据

现象：PRD的客户表里直接设计了“联系人姓名、联系人电话、联系人职务”三个字段，一家公司有多个人，就手工新建好几条客户记录，客户名称一样，但归属到了不同销售名下。

原因：写文档的人想省一张表，觉得联系人就是客户的附属字段，V1.0先这么干，以后再说。审核时业务提出“同一个客户怎么归两个人”，才发现模型已经错了。

解决：对象模型上客户和联系人必须是一对多，客户表里不允许出现“联系人姓名”这种字段。如果已经写了，趁还没开发赶紧改。这个改动在PRD阶段只是一张表的调整，到开发阶段就是建表结构返工、数据迁移、权限重做，代价完全不同。

5.2 坑二：客户归属规则只写了例外，没写默认分支

现象：PRD里写了“销售在公海认领的客户归销售”“销售总监导入的客户按区域分配”，但没写“新建客户时没有指定归属人，怎么办”。研发实现的时候只能自己猜一个逻辑，结果就是所有没有归属人的客户直接进了公海，销售总监月底一看数据，抱怨客户丢了。

原因：写规则的时候，人脑会自动聚焦在“正常情况”上，异常分支在文档里被默认成“不用写”。研发拿到文档后按默认理解实现，两边都没有把规则补全。

解决：每条规则必须写一个默认分支，哪怕默认分支就是“保持原状并记录日志”。我习惯在PRD中用引用块把默认分支单独标出来，评审时逐个问：“如果所有条件都不满足，系统做什么？”问不出来答案的规则，就不要写进V1.0。

5.3 坑三：字段“必填”定义不清，上线后被销售投诉

现象：客户名称、行业、规模、地区全部设成必填，销售在手机上新建客户时，填到一半发现不知道客户规模选什么，页面卡住退不出去，一气之下卸载App用回表格。

原因：PRD里只写了“必填”，没区分这个字段是新建时必填，还是进入某个销售阶段后必填。所有字段一把抓，结果是录入成本过高，数据量直线往下掉。

解决：把必填字段分成两类。新建客户时只必填客户名称和联系电话，保证能建卡、能联系；行业、规模、等级放到“销售阶段转入跟进中”之后必填，因为那时候销售对客户已经有了解，填出来的数据才靠谱。这条规则要在数据字典的“必填时机”列里写清楚，不能光写一个“是”。

5.4 坑四：公海回收时间拍脑袋，老客户被误回收

现象：系统设了“超过30天未跟进自动回收”，大客户销售手里的客户因为采购周期长，两个月没联系，结果被系统自动回收，转给了另一个销售，原有的跟进记录全部作废，销售之间起了冲突。

原因：公海回收时间没有区分客户等级，V1.0一刀切设了30天。但不同等级的客户，合理的跟进频率天然不一样。大客户的采购周期可能是半年，小客户可能两周没跟进就丢了。

解决：公海回收时间按客户等级分档，A级客户90天、B级客户60天、C级客户30天，每个等级可独立配置。再加一条兜底：回收前7天，系统给归属人发通知，提醒“该客户即将被回收，请尽快跟进”。这条通知逻辑成本很低，但能避免绝大多数误回收投诉。

5.5 坑五：权限矩阵和部门架构绑定，组织调整后全崩

现象：权限矩阵做成了一张按部门列权限的表，华东销售部、华南销售部、渠道部各有不同权限。半年后公司组织架构调整，部门合并，权限矩阵没有人维护，销售发现能看别人的客户了，或者自己负责的客户看不到了。

原因：权限设计直接引用了部门名称，组织架构一变，权限数据就失效。很多团队在PRD阶段觉得“按部门管权限很合理”，没有考虑组织架构是易变的。

解决：权限角色与部门解耦，角色只定义数据范围：本人、本团队、全部。组织架构调整时，只改人员与团队的关系，不动角色本身。权限矩阵里出现具体部门名称的地方，一律改成“数据范围”的描述方式。

6. 进阶：用评审清单和验收用例验证你的 PRD

PRD初稿写完不算完，真正让它从文档变成可用系统，靠的是评审和验收两个环节。这一章给一份可以拿来就用的评审清单和一组验收用例，照着做，能帮你把上面几类坑拦在开发之前。

6.1 一份 20 分钟的 PRD 评审清单

评审不用把全文过一遍，那样会让大家困在字段细节里。我习惯在评审开始前先抛三个问题，然后带着问题过文档：客户和联系人是不是两张表？每一条业务规则的默认分支有没有写？谁有删除客户的权限？这三个问题过了，再扫一遍字段必填时机。

6.2 验收用例怎么设计：正常流、边界流、异常流的三个例子

测试同学拿着PRD写用例时，最容易只写正常流，因为正常流覆盖了页面上的主要按钮。客户管理的核心问题恰恰集中在边界和异常。下面三组用例是必选项，可以直接搬进测试计划。

边界和异常用例的价值，在于把PRD里没写清的规则逼出来。如果测试发现“无归属人的客户”这个用例没法写预期，那就是PRD的默认分支确实没写，趁开发还没动手赶紧补。把这三组用例当成最低标准，哪怕没有完整测试计划，也能守住客户管理模块最关键的几条生命线。

我自己写客户管理PRD的时候，就在联系人并进客户表这个坑里栽过一次，评审会开到一半，业务说“同一家公司的两个决策人怎么分开跟进”，当场答不上来。那次之后养成的习惯是：任何规则都先问自己一句“条件不满足会怎样”，任何字段都先问“什么时候开始必填”。这两个问题成了我现在看所有PRD的第一反应。希望帮到你。

本文还有配套的精品资源，点击获取