简介这是一份面向产品经理、CRM系统设计及开发人员的客户管理模块软件需求说明书旨在解决企业客户信息分散、服务跟进低效等问题。文档由蜂网供应链管理上海有限公司于2017年8月发布完整规划了客户档案、联系人跟踪、销售漏斗、营销自动化、客户服务及数据分析等功能可作为需求评审、系统设计与测试验收的参考基线。资源包内含1个PDF文档压缩包大小3.11MB内容共54页涵盖项目背景、目标顾客、平台政策、竞品分析、名词解释、业务流程、功能列表等章节目录结构完整便于按需查阅。目前已有314人学习下载适合需要快速了解CRM客户管理需求框架或编写同类PRD的从业者参考。1. 从PRD标题看CRM客户管理这份PDF到底在讲什么如果你在项目文件夹里看到一份文件名叫“客户关系管理CRM-客户管理-PRD-V1.0-20170825.pdf”的文档大概率是产品经理丢过来的需求文档也可能是系统里沉淀的历史资产。这个标题直接把三个关键词摆在你脸上CRM客户关系管理系统、客户管理核心模块、PRD产品需求文档V1.0是版本号20170825代表文档创建日期。这份PDF的实质不是一段代码也不是一套接口而是把「客户管理」这个业务域拆成功能的说明书——客户数据有哪些字段、状态怎么流转、谁有权看到哪些客户、销售与主管的操作边界在哪。它能解决的问题是让研发、产品、测试对业务口径达成一致避免各做各的。适合读这份文档的人不只是后端开发还有前端、测试、项目经理甚至是刚接手CRM维护的新人。你不需要把PDF里每句话都背下来但一定要能找到实现需要的关键信息实体关系、字段清单、状态机、权限规则。这篇笔记会沿着拆文档、转功能、排雷的路径走一遍最后给你一份能拿来验收的复盘技巧。2. 拆解客户管理PRD核心模块与数据字段设计拿到PRD后第一步不是看界面原型而是先把业务对象捞出来。客户管理模块看似只处理“客户”这一个对象实际背后至少藏着一组实体公司客户我们通常说的Account、个人联系人Contact、销售机会Opportunity、线索Lead和客户归属人Owner。PRD里如果只写“客户”二字你需要自己去区分这些名词因为它们对应数据库里的不同表混在一起就会造成宽表灾难。2.1 客户管理模块的五个核心实体在一份合格的CRM客户管理PRD里这五个实体会反复出现实体业务定义典型字段关系说明公司客户企业或组织客户名称、行业、规模、地址一个公司客户下挂多个联系人联系人客户公司里的具体人物姓名、电话、邮箱、职务联系人与公司客户多对一销售机会和客户进行的交易机会预计成交金额、阶段、赢单率挂在公司客户或联系人下线索未验证的潜在客户来源渠道、线索状态线索转换后生成公司客户和联系人归属人负责跟进该客户的销售员工ID、姓名、部门每个客户必须有一个负责人我做过的多数项目PRD里只会把“客户”当作核心但实际开发时必须要拆到上述粒度否则“客户视图”就画不出来。比如销售点开客户详情页期望看到联系人列表、商机列表、跟进记录如果只设计一张客户主表这些关联数据就得额外拼接口。从PRD提取实体的具体做法是通读全文把重复出现的名词圈出来。出现两次以上的业务名词大概率就是实体或字段。然后画一个单向箭头线索→客户→联系人→商机。不要用复杂工具纸上画也行。画完拿给产品经理确认一遍你会提前暴露掉很多遗漏。2.2 客户字段设计必填项与业务规则PRD里通常会给出一堆字段但直接照单全收会让你上线后录入数据时叫苦不迭。我一般会把字段分成三类基础信息客户名称、行业、客户规模、联系信息电话、邮箱、地址、业务信息客户等级、来源渠道、下一次跟进时间。在开发前先自己整理成字段表再找产品确认。下面是一张客户字段设计示例你可以直接用作对照字段名称类型必填默认值校验规则客户名称字符串是无长度不超过100且全局唯一所属行业枚举否未设置固定选项制造业、互联网、金融等联系电话字符串否无符合手机号或座机正则客户等级枚举否C级A级/B级/C级按销售反馈动态调整来源渠道枚举否广告投放广告投放、转介绍、线下活动负责人关联员工是当前用户员工ID必须是有效用户必填项我只保留三个客户名称、负责人、创建人。其余字段能省则省因为销售录入意愿很低字段越多垃圾数据越多。校验规则不要写进PRD界面描述里但业务边界必须在PRD中明确。比如“客户名称全局唯一”这一条要确认是全局唯一还是仅仅在部门内唯一这个决定直接影响数据库唯一的索引设计。我遇到过在唯一索引上没做好参数判断导致同一个客户在总部和分公司系统里各建了一条后面做合并数据时极其痛苦。2.3 客户生命周期状态机客户状态怎么流转客户管理里最容易让开发和产品争论的就是状态机。PRD里常写“未跟进、跟进中、已合作、已流失”看似简单但代码一旦跑起来状态直接改字段就会出现数据错乱。正确姿势是先定义状态流转表并且每条迁移必须由特定角色触发。举一个我在几个项目里用过的状态流转示例当前状态触发动作下一状态允许角色未跟进首次跟进并记录跟进内容跟进中销售跟进中标记赢单已合作销售跟中进连续90天无跟进记录已流失系统自动已流失重新分配并首次跟进跟进中销售、主管已合作合同到期但未续约跟进中销售这里的关键是“状态不能随意改”。开发时不能在前端对status字段做全局赋值必须走一个服务端的状态机校验方法检查当前状态与目标状态的迁移是否合法。PRD里如果没有写状态机你要主动补一张表去问产品否则后面测试用例都没法写更别提自动化覆盖率。状态变更记录的日志表也要在一开始就加到设计里不然回溯问题时只能看操作日志又是一个黑匣子。3. 从PRD到可开发的功能清单搭建客户管理后台的步骤把PRD里的长描述翻译成开发任务是每一个接这活的工程师的必修课。我不建议直接按PRD的章节去搭模块因为PRD是给业务看的不是给代码看的。用用户故事重新切一遍再排接口优先级最后确定权限范围这条路会比较稳。3.1 把PRD转成用户故事三步拆用法用户故事格式固定作为[角色]我想要[功能]以便[业务价值]。拆的时候按三步走先列角色再找动线最后写故事。角色通常有三个——销售、销售主管、系统管理员。动线就是每个角色最常操作的那几个动作比如销售要新增客户、搜索客户、转交客户主管要看组员的客户、改分配管理员要做客户导入导出。直接套模板可以写成这样作为销售我想要新增一个客户记录以便把名片或微信里的联系人沉淀到公司客户池。作为销售主管我想要查看我团队成员的客户列表以便掌握每个订单的推进状态。作为管理员我想要批量导入历史客户以便把Excel里的几百条记录快速录入系统。写完故事后每个故事都要标注业务规则。比如“新增客户”的规则是客户名称不能重复“查看列表”的规则是仅限本人名下客户。一个PRD章节拆下来通常会得到30到50个用户故事但第一阶段不能全做你只需要把所有故事按角色分类再和产品现场排优先级。3.2 最小可用版本优先开发的六个接口首版上线一般只做让销售能“干活”的闭环录入客户、找得到客户、能跟进、能转移。围绕这个闭环我通常会先定这六个接口直接踩住主链路接口方法路径请求参数说明POST/api/crm/customerbody含客户名称、电话、行业、负责人ID新增客户服务端做名称排重GET/api/crm/customerpageSize、pageNo、keyword、ownerId分页查询列表支持关键字搜索GET/api/crm/customer/{id}无客户详情含联系人列表和跟进记录PUT/api/crm/customer/{id}同新增字段加客户ID更新客户基本资料POST/api/crm/customer/transfercustomerIds、newOwnerId批量转移客户负责人必须有权限校验GET/api/crm/customer/status-count无按状态统计客户数量供看板使用新增接口要注意幂等性前端提交时连续点击可能重复创建服务端最好用客户名称加来源渠道做唯一键。转移接口必须做权限校验销售只能转移自己名下的客户主管可以转移本部门名下客户管理员可转移所有。状态统计接口如果数据量大后面可以改成预聚合报表但首版直接查表就行。接口开发顺序也有讲究。先把列表查询和详情接口做出来这样前端能出页面再做新增和更新让录入能走通最后再碰转移和统计。如果我一开始就去做状态看板后头你会发现连个像样的客户数据都没有看板就是空转。3.3 权限设计销售、主管、管理员分别能看到什么PRD里最常出现的一句话是“销售只能看自己的客户”但这句描述根本不够开发用。你需要把这个口径转成可执行的权限规则。常见做法是分为三种数据权限仅本人销售只能看到自己名下客户本级及以下主管能看到本部门全部客户全部管理员能看到所有客户及数据操作。角色和操作的关系要画成矩阵作为接口权限校验的输入角色可见范围可操作内容销售自己名下客户新增、编辑、跟进、转移给我名下、标记状态主管本部门所有客户查看所有、转移给部门内任意销售、批量编辑管理员全部客户所有操作包括删除、导入、导出、修改负责人这里有一条我踩过的血泪经验权限逻辑必须放在服务端校验不能只靠前端按钮隐藏。原因很简单接口是人人都能调用的前端隐藏只是用户体验不是安全边界。后端在查询参数中必须拼接类似“where owner_id 当前用户id or 当前用户是主管”这样的条件否则某人手动调接口就能看到全系统数据。另外关于删除操作PRD里一般会写成“销售人员可以删除客户”但真正上线后物理删除是件后悔药也补不回来的事。我在好几个项目里都强制改成逻辑删除也就是加一个delete_flag字段查询时默认过滤管理后台才允许彻底删除。这个如果PRD里没写一定要争取写进去不然后面客户投诉时连原始数据都找不到连排查都无从下手。4. CRM客户管理的五大踩坑点从PRD到上线的常见问题排查一套CRM客户管理从PRD到真实跑起来翻车点比想象中多。这里挑五个高频场景每条都按照我平时排查的思路写出来现象、原因、解决三步走免得你在会议室里跟产品来回绕圈。4.1 坑一字段设计过度导致录入阻力现象销售反馈录一个客户要填四十个字段很多人宁愿写在Excel里也不往系统录系统上线的第一个月新增客户数为零。原因PRD里的“理想数据”被产品做成了“必填数据”每项都担心以后报表用得上结果全设成必填项。销售在拜访完客户后只剩两三分钟根本没耐心填完。解决把必填字段砍到三个——客户名称、负责人、创建时间其余全部改成选填。客户等级、来源渠道这些业务信息可以放到跟进记录页里让销售按节奏补而不是在新建页里一上来就逼问一遍。上线后看一个月真实数据再回头决定哪些字段升级为必填。4.2 坑二状态机混乱导致数据不一致现象同一个客户在客户列表显示“已合作”点进详情页却显示“跟进中”销售业绩报表里的数字也对不上财务和销售开始互相怀疑。原因代码里多处直接更新了status字段有的在新增客户时设了跟中进状态有的在赢单时直接改成已合作但过程没走统一的流转接口导致状态被非法覆盖。解决服务端加状态机校验类所有状态变更必须调用同一个方法先校验迁移合法性再写变更记录。同时在数据库加status_version字段更新时比对版本号避免并发覆盖。这样无论前端怎么点后台都能守住最后的防线。4.3 坑三权限只做了前端隐藏后端裸奔现象某位销售人员用自己的账号登录后猜测接口地址直接拿到其他销售部门的客户列表录屏发到群里整个系统安全性被质疑。原因前端只做了按钮和菜单的隐藏后端查询接口没有校验当前用户身份也没有拼数据权限条件相当于门没锁。解决全量检查后容器内的每个客户查询接口都必须从Token中解析用户ID和角色然后动态拼接SQL条件。销售人员只能查owner_id等于自己ID的记录主管查询时用子查询或递归CTE查部门员工的ID集合。如果有批量查询或导出接口也要同步拦截这一层不做等于白干。4.4 坑四数据迁移时客户归属不明确现象历史客户从Excel导入系统后所有客户都显示由管理员负责销售要用的客户却找不到负责人公共池乱成一锅粥。原因PRD没有说明老客户分配规则迁移脚本里缺少负责人字段的映射逻辑默认写了当前导入人的ID。解决导入模板增加“负责人手机号”列导入时按手机号在员工表里匹配匹配不上就放进公共客户池。对应接口里加上“分配人”参数同时生成分配日志。如果历史数据里没有负责人信息宁可先放入公共池也不能挂给管理员不管否则所有新客户都会被管理员一个人压着。4.5 坑五PRD版本更新后需求漂移代码没同步现象PRD从V1.0更新到V1.1新增了“客户渠道”字段页面里始终没有出现客户问起来时再临时去查接口文档开发说不知道有这需求。原因没有需求变更跟踪机制开发只盯着最原始的PRD后面更新没人通知也没有统一的需求矩阵。解决把PRD作为活文档每次变更必须附一条变更日志写清版本号、日期、变更内容。开发环境里建一张需求矩阵表把Story ID、模块、版本号关联起来验收时逐条勾选。不要相信群里的聊天记录全部要求产品在PRD里落笔这样就算出了分歧翻文档也比翻聊天记录容易。5. 验证PRD落地的技巧用一份检查清单复盘你的CRM客户管理需求文档写得再厚最终还是要回到客户管理功能能不能跑通。复盘PRD时直接拿一份检查清单逐项打勾比一遍一遍开会强。5.1 客户管理需求完整性检查清单用以下十项对照你的PRD或现有系统缺哪一项就补哪一项[ ] 客户主数据字段是否区分必填和选填[ ] 状态机是否定义了合法迁移路径[ ] 状态变更是否记录日志[ ] 数据权限是否区分角色并可扩展[ ] 删除操作是否有逻辑删除设计[ ] 客户转移是否留有操作记录[ ] 导入导出的模板是否定义字段映射[ ] 客户与联系人、商机的关联是否明确[ ] 列表和详情的统计口径是否统一[ ] 异常提示是否覆盖重复客户和越权操作这套检查清单可以直接拿去开评审会每一项都对应具体的代码接口和前端页面没有模糊地带。5.2 一个实用的PRD评审技巧角色扮演式走查在评审会上不要只对着文档看找两个人现场扮演销售和管理员走一遍新增客户、跟进、转移、查询列表的流程。每走一步就问我现在能看到什么、我能点哪些按钮、我跳回上一个页面数据还在吗。用这个方式我上次在十分钟内就发现了转移客户后没有刷新列表、详情页没有权限拦截两处问题。我现在的习惯是项目验收前会再拉着连我在内的三个人做一次“用户视角走查”专门挑文档里没写的数据边界问题比如分页越界、空数据状态、断网重试。这个小动作帮我排掉了不少上线后的紧急工单。日常维护CRM时我会把PRD连同接口文档放在同一个代码仓库里每次改需求就同步更新避免文档和代码分家。这份客户管理PRD如果还在你的仓库里躺着别让它只当历史存档把它拉出来照着清单过一遍你会意外发现不少黑洞。希望帮到你。本文还有配套的精品资源点击获取