简介：这是一份面向产品经理、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里，这五个实体会反复出现：

我做过的多数项目，PRD里只会把“客户”当作核心，但实际开发时必须要拆到上述粒度，否则“客户视图”就画不出来。比如销售点开客户详情页，期望看到联系人列表、商机列表、跟进记录，如果只设计一张客户主表，这些关联数据就得额外拼接口。

从PRD提取实体的具体做法是：通读全文，把重复出现的名词圈出来。出现两次以上的业务名词大概率就是实体或字段。然后画一个单向箭头：线索→客户→联系人→商机。不要用复杂工具，纸上画也行。画完拿给产品经理确认一遍，你会提前暴露掉很多遗漏。

2.2 客户字段设计：必填项与业务规则

PRD里通常会给出一堆字段，但直接照单全收会让你上线后录入数据时叫苦不迭。我一般会把字段分成三类：基础信息（客户名称、行业、客户规模）、联系信息（电话、邮箱、地址）、业务信息（客户等级、来源渠道、下一次跟进时间）。在开发前，先自己整理成字段表，再找产品确认。

下面是一张客户字段设计示例，你可以直接用作对照：

必填项我只保留三个：客户名称、负责人、创建人。其余字段能省则省，因为销售录入意愿很低，字段越多，垃圾数据越多。校验规则不要写进PRD界面描述里，但业务边界必须在PRD中明确。比如“客户名称全局唯一”这一条，要确认是全局唯一还是仅仅在部门内唯一，这个决定直接影响数据库唯一的索引设计。我遇到过在唯一索引上没做好参数判断，导致同一个客户在总部和分公司系统里各建了一条，后面做合并数据时极其痛苦。

2.3 客户生命周期状态机：客户状态怎么流转

客户管理里最容易让开发和产品争论的就是状态机。PRD里常写“未跟进、跟进中、已合作、已流失”，看似简单，但代码一旦跑起来，状态直接改字段就会出现数据错乱。正确姿势是先定义状态流转表，并且每条迁移必须由特定角色触发。

举一个我在几个项目里用过的状态流转示例：

这里的关键是“状态不能随意改”。开发时，不能在前端对status字段做全局赋值，必须走一个服务端的状态机校验方法，检查当前状态与目标状态的迁移是否合法。PRD里如果没有写状态机，你要主动补一张表去问产品，否则后面测试用例都没法写，更别提自动化覆盖率。状态变更记录的日志表也要在一开始就加到设计里，不然回溯问题时只能看操作日志，又是一个黑匣子。

3. 从PRD到可开发的功能清单：搭建客户管理后台的步骤

把PRD里的长描述翻译成开发任务，是每一个接这活的工程师的必修课。我不建议直接按PRD的章节去搭模块，因为PRD是给业务看的，不是给代码看的。用用户故事重新切一遍，再排接口优先级，最后确定权限范围，这条路会比较稳。

3.1 把PRD转成用户故事：三步拆用法

用户故事格式固定：作为[角色]，我想要[功能]，以便[业务价值]。拆的时候按三步走：先列角色，再找动线，最后写故事。角色通常有三个——销售、销售主管、系统管理员。动线就是每个角色最常操作的那几个动作，比如销售要新增客户、搜索客户、转交客户；主管要看组员的客户、改分配；管理员要做客户导入导出。

直接套模板可以写成这样：

作为销售，我想要新增一个客户记录，以便把名片或微信里的联系人沉淀到公司客户池。

作为销售主管，我想要查看我团队成员的客户列表，以便掌握每个订单的推进状态。

作为管理员，我想要批量导入历史客户，以便把Excel里的几百条记录快速录入系统。

写完故事后，每个故事都要标注业务规则。比如“新增客户”的规则是客户名称不能重复；“查看列表”的规则是仅限本人名下客户。一个PRD章节拆下来通常会得到30到50个用户故事，但第一阶段不能全做，你只需要把所有故事按角色分类，再和产品现场排优先级。

3.2 最小可用版本：优先开发的六个接口

首版上线一般只做让销售能“干活”的闭环：录入客户、找得到客户、能跟进、能转移。围绕这个闭环，我通常会先定这六个接口，直接踩住主链路：

新增接口要注意幂等性，前端提交时连续点击可能重复创建，服务端最好用客户名称加来源渠道做唯一键。转移接口必须做权限校验：销售只能转移自己名下的客户，主管可以转移本部门名下客户，管理员可转移所有。状态统计接口如果数据量大，后面可以改成预聚合报表，但首版直接查表就行。

接口开发顺序也有讲究。先把列表查询和详情接口做出来，这样前端能出页面；再做新增和更新，让录入能走通；最后再碰转移和统计。如果我一开始就去做状态看板，后头你会发现连个像样的客户数据都没有，看板就是空转。

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如果还在你的仓库里躺着，别让它只当历史存档，把它拉出来照着清单过一遍，你会意外发现不少黑洞。希望帮到你。

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