简介《客户关系管理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只保留三组字段用一张字段表写清楚超出范围的一律进预留。分组字段类型必填说明基础识别客户名称、统一社会信用代码、电话、所在地区文本名称必填唯一性判断用的两个字段必须建索引归属管理归属人、归属团队、来源、状态、客户等级单选/文本归属人非必填归属人和归属团队要分开后面统计要各自维度时间字段创建时间、最后跟进时间、回收时间日期系统写入回收时间用于公海规则V1.0必须预留两组预留是自定义字段组和标签字段。自定义字段组让实施顾问在现场能加字段而不改代码标签字段用来支持临时的市场活动分组比如“展会渠道”“老客户转介绍”都可以用标签打不需要单独建字段。这样做的理由是字段一旦上线历史数据清洗的成本远大于开发成本能少做就少做。2.3 客户分级的逻辑打分模型还是手动等级客户等级是客户管理模块绕不开的设计点。分级怎么定直接决定了公海回收规则和销售的资源分配策略。这里有两套方案我在PRD里习惯用对比表把结论直接写死避免评审会上反复掰扯。方案实现成本数据依赖翻车点手动等级低一个下拉字段无销售直接维护销售懒得点等级数据失真打分模型高事件触发权重计算需要大量客户行为历史数据没数据时模型权重全是拍的上线就是玄学V1.0我建议用手动等级而且只分A、B、C三级加上一个“最后跟进时间”做兜底判断。理由很直白打分模型需要历史数据回归出权重一个新系统根本没有数据可供训练这时候硬做一个打分模型参数全是拍脑袋定的上线后销售也不信。手动等级虽然土但销售填了就是自己认的后续公海回收规则可以直接按等级设不同的天数比一个复杂的模型更容易让业务理解和接受。3. 把 PRD 写成可落地的规格文档结构与关键章节的写法范围定完之后PRD的正文怎么写决定研发和测试能不能照着干活。这一章不讲概念直接给可抄作业的写法。客户管理PRD和其它后台系统PRD不一样的地方在于它的大部分需求不在页面设计而在业务规则和异常分支。所以文档的重心要放在用户故事、规则表和权限矩阵上页面原型反而是辅助。3.1 需求背景与用户故事怎么写才不空很多PRD的需求背景写的是“为了提升销售效率、加强客户管理”这等于没写。研发看完只会觉得你要他做一个“客户信息的增删改查”。我一般会在文档开头用一段具体场景把问题钉死比如某销售团队目前用表格管理客户客户列表分散在多个工作表里员工离职后客户跟着邮件走超过两个月没跟进的客户没有任何人接管。销售总监每月要花两天时间人工统计谁在跟哪些客户、哪些客户已经失联。目标是在系统上线后每个客户会自动归属到唯一负责人超过设定天数未跟进的客户自动回到公海由其他人继续跟进。这段写完之后研发能理解自己做的每个功能是干什么用的。用户故事也要写具体不要写“作为销售我希望管理系统”。我习惯拆成三个角色销售、销售总监、系统管理员每个角色给一个带业务诉求的故事。销售关心的是“我新增的客户不会被人抢走”销售总监关心的是“客户不要死在个别人手里”管理员关心的是“离职交接不用导出再导入”。这三条写清楚整个模块的功能列表就自然出来了不用硬凑需求。3.2 业务规则表分配、认领、回收、公海的四条主线客户管理的业务规则是整份PRD里研发最依赖的部分。这里建议直接用表格把规则列出来每条规则写清楚触发时机、条件、动作和默认分支。最容易被漏掉的是默认分支也就是条件都不满足的时候系统怎么办。规则名称触发时机条件动作参数自动分配新建客户且没有指定归属人客户区域华东/华南权重按区域负载分配给在线且名下客户数低于上限的销售上限500权重比例区域销售人数手动认领销售在公海列表点击“认领”客户状态公海客户归属人变更为认领人状态改为跟进中无自动回收每日定时任务扫描客户状态跟进中最后跟进时间超过N天客户归属人清空状态改为公海N30天按等级可配置再次分配回收后第3天客户仍在公海触发自动分配规则无每条规则后面还要写正常分支和异常分支。自动分配的正常分支是分配给一个符合条件的人异常分支是当时没有在线销售那么客户保留在公海状态不变并记录一条分配失败日志。这个日志在排障的时候非常有用不加的话出问题只能翻代码找黑匣子。手动认领的异常分支是两个销售同时点了认领要写清楚用更新时间戳做先到先得而不是让数据库随机报错。3.3 数据字典与权限矩阵的呈现方式数据字典是研发建表和测试写用例的直接依据用文字描述会逼着研发去猜。最好直接给字段定义表逐字段过一遍我一般把表放在文档的附录位置但在评审前单独拉出来一起过。字段名字段类型长度必填默认值备注customer_idbigint20是自增主键customer_namevarchar128是无唯一性校验字段owner_idbigint20否空归属人ID空公海gradevarchar2否CA/B/C三级last_follow_timedatetime无否创建时间每次跟进自动更新权限矩阵按对象和操作来画而不是按部门来画。行是角色列是操作查看、新建、编辑、转移、删除。客户管理V1.0的权限矩阵只要四行三组就够老板看全部销售总监看本团队销售看自己和公海客服只看被分配给他的客户。删除权限这一列V1.0建议除了系统管理员其它角色全部置灰。客户数据删了没有后悔药做软删除比放开删除权限划算得多。4. 从 PRD 到实现的参数设计客户管理模块的三个必调参数PRD写得再细到了开发阶段还是会有一堆参数等着定。客户管理模块的核心参数集中在三个地方分配规则、去重合并、列表页默认行为。这几个参数定不好后面上线运维会一直被业务投诉。我在这个环节的建议是所有参数必须在PRD里给出默认值而不是写“可配置”三个字就完事“可配置”意味着没人配置最后按代码里的写死值运行。4.1 客户分配规则按什么条件、什么时候自动分配分配规则参数是销售最敏感的东西直接关系到业绩归属。参数包括分配时机、分配模式、分配上限、分配优先级。参数默认值说明分配时机新建时未指定归属人、公海被认领时同步检查不要等定时任务新建时实时分配体验最好分配模式按区域权重分配区域内轮询区域权重优先防止某个销售区域内客户全归自己名下客户上限500超过上限不再分配避免客户积压分配优先级在线状态 当前名下客户数 200 最后分配时间最旧保证公平性避免老销售永远优先这块常见的翻车点是只做轮询不做上限。轮询本身逻辑简单但如果没有上限老销售名下的客户会堆到几千个且大都不活跃新销售拿不到客户公海规则也形同虚设。另一个坑是分配时的并发控制两个定时任务同时扫到同一个客户必须用数据库行锁或者唯一索引兜底否则会出现一个客户同时归两个人的脏数据。4.2 去重合并策略匹配规则与操作权限客户管理模块上线三个月后数据质量的问题一定会爆发核心就是重复客户。重复的来源很多销售手动导入一次、公海认领时又新建了一个、移动端录入名称不统一。去重不做后面所有统计都是错的。去重策略建议分两层。第一层是自动拦截新建客户时按统一社会信用代码做精确匹配匹配到了直接提示“该客户已存在归属人为某某是否申请转移”。第二层是人工合并客户名称做模糊匹配把可能是同一个客户的列表推送给管理员由管理员人工确认合并。合并的参数也要定义清楚主记录保留哪个、被合并记录的跟进记录要不要带过去、字段冲突时以谁为准。我的默认方案是主记录选创建时间早的那一条被合并记录的跟进行为在合并后统一挂到主记录下归属人取最近一次有跟进行为的销售。这个方案不算最优但它是业务最容易接受的——不冤枉任何一个有实际跟进的销售。4.3 列表页与筛选条件的默认参数列表页是所有用户每天打开次数最多的页面它的默认参数虽然不起眼但直接影响用户对系统快慢和好用程度的感受。研发经常把列表页做成简单的全表查询上线后销售一打开就加载几千条数据翻好几页才能找到自己正在跟的客户。我建议PRD里明确规定列表页的默认行为参数默认值说明默认筛选我的客户防止“全部客户”导致的数据泄露感和性能压力默认排序最后跟进时间倒序让销售打开页面先看到最该跟进的客户分页大小20条一屏能看完翻页不卡列表显示字段客户名称、等级、所属地区、最后跟进时间其它字段进详情页自定义列表视图每个用户最多保存5个销售可以存“今天待跟进”“A级客户”两个视图这里要特别提一下“我的客户”这个默认筛选。很多客户管理项目上线后被销售抵制原因之一就是打开列表看到所有客户的手机号谁都能看到销售就不敢录真人数据了。按归属人隔离是保住数据真实性的第一道防线。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. 进阶用评审清单和验收用例验证你的 PRDPRD初稿写完不算完真正让它从文档变成可用系统靠的是评审和验收两个环节。这一章给一份可以拿来就用的评审清单和一组验收用例照着做能帮你把上面几类坑拦在开发之前。6.1 一份 20 分钟的 PRD 评审清单评审不用把全文过一遍那样会让大家困在字段细节里。我习惯在评审开始前先抛三个问题然后带着问题过文档客户和联系人是不是两张表每一条业务规则的默认分支有没有写谁有删除客户的权限这三个问题过了再扫一遍字段必填时机。评审项通过标准对象模型客户表不含联系人字段联系人支持一对多归属规则每条规则都有默认分支没有默认分支的标黄字段必填每个必填字段都标了必填时机回收规则按客户等级分档不是一刀切权限矩阵角色与部门解耦删除权限默认关闭去重策略有自动拦截和人工合并两层有明确主记录规则6.2 验收用例怎么设计正常流、边界流、异常流的三个例子测试同学拿着PRD写用例时最容易只写正常流因为正常流覆盖了页面上的主要按钮。客户管理的核心问题恰恰集中在边界和异常。下面三组用例是必选项可以直接搬进测试计划。用例类型操作步骤预期结果正常流销售新建客户填写名称和电话保存客户创建成功归属人当前销售状态跟进中边界流销售A和销售B同时点击公海中同一客户的“认领”只有一个人的认领成功另一人收到“客户已被认领”提示异常流管理员合并两条重名客户其中一条有跟进记录合并成功主记录保留跟进记录全部挂到主记录归属人取最近跟进人边界和异常用例的价值在于把PRD里没写清的规则逼出来。如果测试发现“无归属人的客户”这个用例没法写预期那就是PRD的默认分支确实没写趁开发还没动手赶紧补。把这三组用例当成最低标准哪怕没有完整测试计划也能守住客户管理模块最关键的几条生命线。我自己写客户管理PRD的时候就在联系人并进客户表这个坑里栽过一次评审会开到一半业务说“同一家公司的两个决策人怎么分开跟进”当场答不上来。那次之后养成的习惯是任何规则都先问自己一句“条件不满足会怎样”任何字段都先问“什么时候开始必填”。这两个问题成了我现在看所有PRD的第一反应。希望帮到你。本文还有配套的精品资源点击获取