简介蜂网供应链管理上海有限公司于2017年8月正式发布《客户关系管理CRM客户管理软件需求说明书V1.0》由周旭丽编写全文54页详细定义了客户管理模块的项目背景、目标用户、平台政策、竞品分析、名词解释、业务流程、业务用例与功能列表。资源为单个PDF文件压缩包大小3.11MB便于打印与团队共享适合CRM产品经理、需求分析师及开发测试人员阅读。已有312人学习下载关注度稳定。文档不仅拆解了客户信息录入、联系人跟踪、销售预测、市场营销自动化、客户服务模块、报告分析工具等具体功能需求还覆盖了客户档案、交互历史、销售漏斗等核心概念并包含用户界面设计、性能指标、系统安全性、移动设备支持及变更控制等内容可作为撰写同类PRD的模板也可作为需求评审与系统设计的重要依据。1. 一份 2017 年的 CRM 客户管理 PRD为什么到现在还能当模板用真正做过 CRM 后端的人应该都有这种感觉客户列表、查询方案、新增编辑、详情页动态、团队成员这些功能三年五年都不会有本质变化。我拿到手的这份《客户关系管理 CRM 客户管理 V1.0》软件需求说明书是蜂网供应链管理上海有限公司在 2017 年 8 月发布的 PRD 文档一共 54 页内容只有一个大模块——客户管理。它没有花哨的原型图但是把“客户名称超过 200 字符就不能保存”“工商注册是系统判定、不可编辑”“全部客户 我所在组织”这种细节一条条钉死在文档里。这正好是现在很多团队画原型时最懒得写、开发时又最容易吵架的部分。这份资源的适用人群是三类正在设计或重构 CRM 客户模块的产品经理要给客户管理写接口和权限的开发以及想补全用例的测试。它不是 CRM 科普是一份可以照着拆、照着评审的原始需求。2. 先拆文档骨架需求来源、范围边界、功能优先级拿 PRD 第一步看什么拿到一份 PRD我习惯不是先看原型而是把 1.1 需求来源、1.3 项目目标、2.5 功能列表这几页先过一遍。这三块能直接告诉你这份文档是被谁推动写的、到底要做到哪一步、哪些功能只是占位。很多新入行的产品会忽略这些前置章节直接翻到页面交互结果评审时被问“这个需求哪来的、为什么做”就答不上来。这套骨架顺序本身也值得复用先讲来源和边界再讲方案和细节最后补预置数据和遗留问题。2.1 需求来源分级BRD、MRD、ECR 决定 PRD 的变更合法性这份文档的第 1.1 节很简短但分类很明确需求来源要么是“直接为 PRD 等级”也就是这份 PRD 不是由上层文档推导而来的要么是“BRD 或 MRD 等级”需要注明来源文档要么是“ECR 转为 PRD”涉及一个以上 ECR 的还要注明 ECR bug。很多人觉得这一页是套话其实不是。常见做法是PRD 需要一个独立的变更追溯入口。没有需求来源两个月后开发问“这个客户合并功能是谁提的”你只能说是“会上定的”有 ECR 编号就能从变更记录一路查回去。我一般在评审前一晚会先拿这一页对照三件事如果功能来自 BRD/MRD确认 BRD 的版本号和结论没有过期如果来自 ECR确认 ECR 的 bug 编号还在开放状态免得把已撤销的问题做进去如果是直接 PRD 级那 PRD 本身要写清楚要解决什么业务问题不要靠口头解释。你现在自己写 PRD 也可以直接用这个分类来源空着、或者写着“讨论决定”的需求优先级再高我也只当它是个草案。PRD 章节这份文档怎么处理开发时怎么用1.1 需求来源三种来源分级注明来源文档和 ECR 编号变更追溯评审前核对需求合法性1.3 项目目标只写两条一期目标二期单列核定模块边界排期时防止范围蔓延1.5 平台政策 / 1.6 竞品分析文档里留了空位未展开自己项目里补上合规约束和竞品对照2.5 功能列表客户关系管理—客户菜单优先级 P1排期与迭代划分3.1 产品详细需求按界面、按钮、字段、规则拆解提测和验收依据4 预置数据 / 5 遗留问题预置数据和遗留问题独立成章主数据初始化和二期规划用这份文档的变更记录区域是空白的但文件状态写的是“正式发布”编写人周旭丽2017 年 8 月 25 日。从这里能看出一个习惯正式发布的前提是内容冻结而不是“写完了”。我见过太多标着正式发布的文档正文还在大量使用“待确认”“待补充”这种情况评审时根本没法锁定需求。变更记录不写内容等于告诉后人“这份文档从草稿到发布之间发生了什么对不起查不到”。2.2 项目目标与范围边界二期功能先写进文档后面少吵三成文档的 1.3 项目目标只写了两条客户资料管理为销售、服务、营销等人员提供快速查询入口对客户销售活动、计划安排、联系人、商机的管理记录销售过程中的行为并实现计划安排的提醒。而二期功能写得很明确客户跟客户通讯信息的自动读取邮件往来、电话、短信记录、线索获取和分配、统计分析、销售漏斗。这里的价值点在于范围边界不是评审时才说的而是写进了正式文档。做需求最怕的是“先做个简单的客户管理”上线后发现销售天天要报表然后报表功能临时插入迭代PRD 没有对应章节研发只能边问边做。把二期功能列进去等于给所有人都画了一条线一期不含统计报表不是漏了是明确延后。这个做法可以直接抄。我现在的习惯是PRD 第一章就加一张范围表功能块、一期做不做、二期做不做、哪些只是远期设想。不需要写很细但必须让项目干系人签字前看到这张表。相比在最后补“遗留问题”前置管住范围返工少很多。值得注意的是这份文档命名是“软件需求说明书”不是“产品需求文档”或者“原型说明”。这个词很关键说明交付对象是研发和测试不是老板或者销售。所以它才会用大量篇幅写字段表、按钮清单、状态转换而不是把重点放在美观的原型上。如果你的团队习惯只出原型不加字段说明这份文档正好是个对照原型解释交互软件需求说明书解释数据和规则两件事不能互相替代。2.3 功能列表与优先级 P1/P2/P3优先级要和备注一起看文档 2.5 功能列表页定义得很直白P1 是最高优先级P2 或 P3 可视开发资源与上线时间调整到下一期开发。同时标注“数字为 P1 表示最高优先”表格里把“客户关系管理菜单— 客户菜单”列为 P1。这里有个容易踩的误区优先级标记不是排期承诺。P1 只代表“本期必须做”不代表“本期必须全部做完”。真正决定做多做少的是开发资源的排期所以优先级必须和备注配合看。这份文档里客户模块是 P1但其中导入、导出、高级查询、合并这些子功能没有被逐个标记优先级。你在复用这个模板时建议把优先级标到二级功能点甚至标到具体按钮。导入可以 P2导出可以 P1查重可以 P2。颗粒度越细迭代排期就越有弹性。另外文档末尾还有“预置数据”和“遗留问题”两章。预置数据在 PRD 里很容易被忽略但对开发来说数据字典、枚举值、初始查询方案不给全页面做了也只能空转。遗留问题则要区分“本次不做”和“没想清楚”如果是前者列出延后版本如果是后者别用“遗留”两个字糊弄过去至少要写当前建议方案和一个备选方案。3. 客户列表页与查询方案五种视角背后的数据权限和字段口径客户管理模块里列表页是最容易“看着简单、做起来一堆口径”的地方。这份文档用三个小节把列表页拆开了界面交互说明、按钮清单、默认关键数据项。我最想看的是那五个预置查询方案因为查询方案约等于数据权限。列表页做什么字段、怎么排序、哪些按钮能用这些多花半小时理清楚后面接口设计能少返工一星期。3.1 五个预置查询方案先看懂“全部客户”不是“所有客户”文档给出的查询方案一共五种全部客户是“客户所属组织我所在组织”我负责的客户是“客户负责人我本人”我参与的客户是“团队成员包含我且负责人不等于我”我关注的客户是“我已加关注客户”七日未跟进客户是“未跟进天数7天”。注意第一条的口径“全部客户”限定了所属组织。这意味着一个普通销售看不到全公司的客户只能看到本组织的客户跨组织的协作要靠团队成员机制来补。如果你开发时把“全部客户”理解成 SELECT * FROM customer那权限直接就穿帮了。-- 预置查询方案“全部客户”的口径示例所属组织 当前用户所在组织 -- 同时带上最近活动记录时间供“七日未跟进”类查询复用 SELECT c.id, c.customer_name, c.belong_org_id, c.owner_user_id, c.deal_status, -- 成交状态未成交 / 已成交 act.last_activity_time FROM customer c LEFT JOIN ( SELECT customer_id, MAX(activity_time) AS last_activity_time FROM customer_activity WHERE deleted 0 GROUP BY customer_id ) act ON act.customer_id c.id WHERE c.deleted 0 AND c.belong_org_id :current_user_org_id -- 关键权限过滤条件 ORDER BY c.create_time DESC; -- 列表默认创建时间倒序这个语句里有两个地方不能省。第一个是 customer_activity 子查询要用 MAX(activity_time) 聚合而不是 join 明细表以后去重否则一个客户有十条活动记录就会在列表里重复显示十行。第二个是 deleted 0 的软删除过滤要下沉到子查询里很多系统只在主表过滤活动表不过滤导致删掉的活动还在回填“最新活动记录时间”。这份 PRD 虽然没有规定 SQL 怎么写但“列表默认是创建时间倒序”“最新活动记录时间 最后活动记录保存时系统时间”两项规定了结果实现时跑不出这个结果就说明写偏了。再看“我参与的客户”它的 SQL 过滤条件是负责人不等于当前用户但团队成员表包含当前用户-- “我参与的客户”团队成员包含我但负责人不是我 SELECT c.id, c.customer_name, c.owner_user_id FROM customer c JOIN customer_team_member tm ON tm.customer_id c.id AND tm.user_id :current_user_id -- 团队成员含当前用户 WHERE c.deleted 0 AND c.owner_user_id :current_user_id; -- 但要排除我负责的这个方案的关键点是排除负责人。也就是说“我负责的客户”和“我参与的客户”两个列表要互斥不能重叠否则销售数客户的汇总口径就乱了。开发在实现时很容易只加“团队成员包含我”忘记“负责人不等于我”结果同一个人又负责又参与两个列表出现重复数据。文档里五个方案只用了“所属组织、负责人、团队成员、关注、未跟进天数”这几个条件没有引入复杂的数据权限模型这个选择很务实适合大多数中小规模 CRM。3.2 高级查询与列表自定义列把配置能力交给用户文档在高级查询部分明确写着高级查询条件是客户表字段包含自定义字段同时需要增加“团队成员、是否关注”这类补充条件。也就是说查询条件来源有两类一是客户主表字段二是补充的团队/关注类过滤项。这个设计的优点是查询能力和字段配置解耦开发新增自定义字段后高级查询自动可用不用改页面。很多系统在做高级查询时只拷贝了所有字段没有加“团队成员”结果用户想查“张三参与的客户”就只能去列表里翻。列表自定义列的要求也写得很保守显示列可自定义可自定义列为客户表字段客户名称为必选字段。默认字段按关键数据项表来。这里有两个容易被产品忽略的点客户名称必选防止用户把列表里的唯一标识列隐藏掉自定义列只限于客户表字段不能把关联对象字段随便拉进列表否则排序、导出都会变得不可控。你单独加个“最后跟进人”列就要考虑这个人的姓名是在活动表里排序时要 join 子查询数据量大时接口直接变慢。导出按钮按“将当前页面的数据导出到 EXCEL 文件”这句话实现。注意是“当前页面”的数据不是全部筛选结果更不是所有客户。很多系统导出按钮做成了“导出全部”数据量大时一张 Excel 几十万行Excel 打开直接卡死。按当前页导出用户先筛选、再翻页控制每次导出的数据量这个思路在写导出需求时可以保留。页码参数还要和查询条件一起传后端不能只传当前页的 ID 列表否则用户翻到第三页再导出导出的还是第一页的数据这种 bug 测试阶段经常发现不了。提示列表页的“搜索、高级查询、导出”三者的可见范围要统一。搜索只搜可见数据导出也只导可见数据。很多系统搜索功能单独写了一条 SQL忘了拼权限条件结果搜索时把别人的客户搜出来了比列表泄露数据还隐蔽。3.3 默认关键数据项字段属性直接决定开发的工时评估列表默认关键数据项是这份 PRD 里最有信息量的一节。字段表决定了后端表结构、对象映射、校验规则和工作量我把几个重要字段整理一下字段来源可空 / 可编辑注意点客户名称手工输入默认为空非空可编辑不超过 200 字符列表必选列搜索按此字段模糊匹配上级客户参照 CRM 客户可空可编辑不允许互为上下级防循环引用行业枚举数据字典可空可编辑只能选已启用数据业务类型枚举数据字典可空可编辑可多选多选枚举的存储和查询要单独设计工商注册系统判定非空不可编辑字段无手工录入入口需上游判定负责人参照选人非空可编辑更改负责人可批量操作所属部门参照部门非空可编辑默认为当前用户部门注意“部门”和“组织”是两个字段所属组织系统自动非空不可编辑默认当前操作员所属组织影响数据权限成交状态枚举非空可编辑默认未成交未成交 / 已成交详情页有独立入口创建人 / 创建时间系统自动不可编辑新建操作人名称和系统时间最新活动记录时间系统自动不可编辑最后活动记录保存的系统时间这张字段表最大的价值是它把“输入来源”和“可编辑性”拆成了两列。我见过不少 PRD 只写“客户名称 varchar(200)”不写谁在什么时候填结果前端做了输入框后端不知道要不要校验测试不知道要不要准备字典表。如果你要复用这份文档可以把表格直接抄进自己的需求文档再增加一列“是否展示在列表 / 详情页”就完整了。字段来源要区分“手工输入、参照、系统自动”三类。参照字段意味着要开发选择器比如负责人参照选人省市区参照行政区划系统自动字段意味着前端不可编辑、后端要写默认值逻辑比如所属组织默认当前操作员所属组织。在列表交互上文档写了一个容易被忽略的亮点当鼠标移动到某字段时可出现编辑按钮点击编辑当前字段内容失去焦点保存。这是行内编辑和“编辑”按钮打开编辑页是两个不同入口。实现时要注意行内编辑保存后不能重新排序否则用户刚改完一行列表刷新后行位置变了眼睛都跟不上。文档里“保存后更新修改的行不重新排序”这句就是为这个场景补的规则后端接口只返回更新结果不要顺手把整个列表重新查一遍。4. 客户新增、编辑、详情与合并功能点背后的字段规则和状态机客户列表页解决“查得到”新增编辑和详情页解决“录得进、看得全”。这份 PRD 在客户新增界面给了按钮清单在编辑页和详情页又分别给了关键数据项。真正开发时这些表单字段规则才是工时的大头。一个客户新增页面看上去只有十几个字段但每个字段的必填、枚举、来源、联动关系全部写清楚后端接口的设计成本其实很高。4.1 新增与编辑的字段规则非空校验、枚举校验、上下级关系校验客户新增界面示意图虽然没在这个文档里展开但按钮清单和关键数据项是完整的新增、保存、取消字段规则在第三章的字段表里基本都列了出来。落到代码层面提交时至少要过这几类校验# 客户表单字段规则的伪代码对应 PRD 关键数据项的可空/可编辑/来源定义 def validate_customer_form(form, is_editFalse): errors [] # 1. 客户名称非空最多 200 字符字符型手工输入 name (form.get(customer_name) or ).strip() if not name or len(name) 200: errors.append(客户名称不能为空且不能超过200字符) # 2. 行业从数据字典取已启用枚举不在字典里直接拒绝 industry form.get(industry) if industry and not dict_item_enabled(industry, industry): errors.append(行业取值不在数据字典启用范围内) # 3. 业务类型可多选的枚举逐个校验 business_types form.get(business_type) or [] for bt in business_types: if not dict_item_enabled(business_type, bt): errors.append(f业务类型包含未启用枚举值{bt}) # 4. 上级客户参照 CRM 客户且不允许互为上下级 parent_id form.get(superior_customer_id) if parent_id and is_customer_descendant(parent_id, form.get(id)): # is_customer_descendant判断 parent 的层级链上是否包含当前客户 errors.append(上级客户不能是当前客户的下级否则形成循环) # 5. 负责人参照选人非空 if not form.get(owner_user_id): errors.append(负责人不能为空) # 6. 成交状态枚举未成交/已成交默认未成交 deal_status form.get(deal_status, 未成交) if deal_status not in (未成交, 已成交): errors.append(成交状态只能为未成交或已成交) # 7. 工商注册字段来源为系统判定表单不接收手工值 if form.get(business_registered) is not None: errors.append(工商注册状态由系统判定不接受页面提交值) return errors这段代码对应的规则有两层含意。第 1、2、3、6 条是常规的必填和枚举校验主要是确保数据字典变更后老数据不会被非法值污染。第 4 条是层级关系的循环校验这也是文档“上下级关系不允许互为上下级”的落地方式通常要递归查上级客户链最多追溯三层就够了让用户自己去配五级客户树的情况很少。第 7 条对应“工商注册”这个布尔字段来源是系统判定前端表单没有录入框后端要忽略或拒绝任何手工赋值否则名单里出现一个用户自己勾的“已注册”客户后面判断客户身份时就失真了。还有一个容易被忽略的细节文档在“客户编辑”部分没有放开批量编辑明确“不可批量编辑”。我见过很多 CRM 后台做了“批量修改行业”“批量修改客户级别”结果改错了根本没人知道。批量操作只允许在删除和更改负责人上放开这是合理的因为删除和负责人变更都可追责。如果被迫要做批量编辑至少要把修改前后值记录成审计日志别做静默更新。这算是这个项目里一个值得坚持的取舍。4.2 详情页的成交状态、动态与相关对象让客户页面变成数据中心文档的业务定义写得很清楚这是客户数据中心可新建和查看跟客户有关的联系人、商机、动态、合同、订单、团队成员信息是客户跟进管理和维护的核心页面。详情页从上到下大概分为几个区域基本信息、成交状态操作区、动态、相关对象列表、团队成员、层级关系。这个分区顺序符合业务习惯先知道客户是谁再看现在处于什么状态然后看最近发生了什么最后看谁在管。成交状态在详情页有独立入口说明它在客户生命周期里地位很高。新增时默认未成交达成交易后由业务人员在详情页改状态。这里要顺势考虑成交状态改变时是否要生成一条动态是否要锁定某些字段文档没有明确展开但我一般会建议在状态变更时写一条“系统操作”动态记录操作人、操作时间、旧的成交状态和新的成交状态。这样事后查“这个客户什么时候打成已成交的”就不用翻审计日志。动态页面是客户跟进记录的聚合面。文档提到二期的想法是邮件、电话、短信记录自动读取到动态一期则是手工记录活动。无论哪种来源“最新活动记录时间最后活动记录保存时系统时间”这条规则都成立。开发时动态的排序、分页、权限都要提前定。一个客户跟进了几年动态数量可能上万条前端不能一次全渲染必须分页或者按时间维度懒加载。新建操作指的是在详情页直接新建任务、安排计划对应项目目标里的“计划安排的提醒”。提醒的规则要定义好提前几天提醒、是站内消息还是推送、重复性任务怎么处理。文档只写了目标没写细节这块在复用时要自己补建议在 PRD 里加一张“提醒规则”参数表别让开发猜。4.3 客户合并、团队层级与档案生成主数据的脏活要提前说明白客户合并和 CRM 客户生成档案是两个容易低估的功能。“客户-合并”在目录里占了独立的位置说明它是设计过的。合并通常发生在重复客户场景比如销售录了一个“苹果贸易”客服又录了一个“北京苹果贸易有限公司”工商注册判定后发现是同一主体需要合并。合并的关键词是“以谁为主”要以主客户为保留主体被合并客户的动态、联系人、商机、订单迁到主客户下。但合并不是“把两个表拼一起”那么简单至少有四个问题要提前定。第一被合并客户的负责人如果和主客户不同合并后负责人是谁是保留主客户负责人还是提示用户选择第二主客户没有联系电话被合并客户有是否把电话补到主客户如果两个客户同一个字段都有值谁覆盖谁第三被合并客户的反悔问题万一合错了怎么拆回去第四合并历史要留痕记录合并前两个客户 ID 和合并时间方便审计。这些规则在绘图阶段看不出来开发阶段全是问题。我一般建议 PRD 里至少要写三条主客户选择规则、字段覆盖规则、关联单据迁移规则如果企业要求高再加一条合并审计记录。团队成员的规则在文档查询方案里有佐证“我参与的客户”按团队成员表查询。团队和负责人的关系是负责人是主责任人团队成员是协作人两者要分开存不能只存一个“负责人”字段就假装支持团队协作否则“我参与的客户”这个方案就没法实现。层级关系方面文档定义了上级客户字段并明确不允许互为上下级。这一条在地域、代理、子母公司结构里很有用但实现循环校验时要注意性能客户表大的话要缓存层级路径别每次保存都从底往上递归查一遍那会把表单接口拖慢。“CRM 客户生成档案”是负责人在客户详情页触发把客户主数据推送到档案模块的操作。生成档案不是简单的复制档案要是独立对象后续档案的变更不能反写客户避免两边不一致。触发条件和权限也要限制通常只有管理员或负责人能触发。文档里这一节最薄可以把它作为二期“待细化功能”处理。这里有一条血泪经验凡是 PRD 里写“生成”“归档”这种词的功能一定要先确认是物理拷贝、逻辑关联、还是状态切换。三种实现方式的数据流向完全不同等开发做了一半再改返工量非常大。5. 落地这份 PRD 的避坑与排查五个最容易让研发和产品吵起来的点这一章是项目组里最容易吵起来的清单。这些坑不是文档写错了而是文档写了但口径没锁死或者页面交互和权限规则互相牵制。每条按现象、原因、解决三步拆你在评审前拿这个清单过一遍至少能少开三次对齐会。5.1 坑一“全部客户”变成了全公司客户现象客户列表默认打开后销售看到几千条不属于自己也不属于本组织的客户数据问就是“文档说默认查询全部客户”。原因文档里“全部客户”的定义是“客户所属组织我所在组织”但界面和开发沟通时只记住了“全部客户”四个字把默认查询方案实现成不过滤组织。解决把查询方案和权限过滤拆开看。“全部客户”是页面默认方案数据权限过滤是独立的每次查询都要先判断可见组织范围再执行具体方案。我的做法是代码评审时专门检查查询语句里有没有带上 belong_org_id 条件没带的打回重写。测试用例里也要加一条A 组织销售登录列表里不允许出现 B 组织客户。5.2 坑二“工商注册”字段没有判定规则系统判定变成没人判定现象客户新增页面没有工商注册输入框但数据表里这个字段是非空保存时后端报错“工商注册不能为空”。原因文档只写了“来源系统判定、非空、不可编辑”但没有写判定动作什么时候发生、由哪个服务触发。客户名称和统一信用代码一进来到底调工商接口还是人工在后台审核没有定义。解决在开发前补一个字段来源说明最简单的是复用企业信息接口保存客户时按统一社会信用代码查一次查到就置为 True查不到保持 False。没接口的小项目把“工商注册”字段改名为“是否已认证”由管理员在客户详情后台确认。原则只有一个——必须有一条明确的赋值路径不能等代码写完了大家互相推。这个字段如果甲方坚持要留至少要给个定时任务兜底别让用户手动去改布尔值。5.3 坑三“七日未跟进客户”到底按什么时间算现象上线第一天“七日未跟进”列表里出现了昨天刚新增的客户。销售觉得产品疯了产品觉得开发不理解需求。原因文档里的口径是“未跟进天数7天”但未跟进天数的基准没有定义清楚。如果基准是“最近一条跟进记录”那新建客户从未跟进过最近跟进时间为空算出来自然是“未跟进天数非常大”。解决把基准拆成两条。老客户MAX(activity_time) 距今超过 7 天且无新增活动记录新客户创建时间距今超过 7 天且无任何活动记录才算进入列表。一句话总结没有活动记录的客户不能直接从有活动记录的客户里套公式要单独给空值定一个规则。这个规则建议直接写进查询方案的 SQL 注释里避免上线后销售投诉“我新客户刚录入就被标记成没跟进了”。5.4 坑四列表行内编辑和批量编辑打架现象产品说支持行内编辑用户选中多行想批量改行业发现没反应反馈“编辑按钮坏了”。原因文档明确“不可批量编辑”但行内编辑容易让用户误以为所有字段都支持批量。解决交互上把批量勾选和行内编辑在视觉上分开比如只有点击“批量操作”模式时才显示勾选框默认列表的勾选框收起。后端也要挡住批量更新接口不能被前端绕过。“不可批量编辑”这句话建议复制到接口设计的注释里防止后来的人顺手放开。如果业务方坚持要部分字段的批量编辑那就在页面上明确哪些字段是灰色禁用的并且记录批量修改日志否则出了问题没人说得清是谁改的。5.5 坑五客户合并后关联单据和动态原地蒸发现象合并完客户发现被合并客户的商机、合同没了销售找过来开发说“合并就是删掉一条这两条本来就是重复的”。原因客户合并功能在设计时只考虑了主字段没有考虑关联对象的迁移。文档里有合并按钮但没有合并规则页开发只能自己理解。解决合并前先做字段级和单据级的迁移映射。主客户保留被合并客户的联系人、商机、动态、订单按主外键迁移到主客户历史动态保留原文但客户名称字段需要改到主客户被合并客户本身标记为“已合并”状态不能物理删除方便追溯。合并操作生成一条审计记录记录合并时间、操作人、合并双方 ID。这套规则不写进 PRD就别指望一次上线能平稳。如果合并的是有合同数据的客户还要确认合同审批流里绑定的客户 ID 是否要同步切换漏一处就是连锁问题。6. 用一页纸验收客户模块开发说做完了你怎么快速判断客户管理模块功能不少但验收不必等全部完成后才做。我会在开发提测后用一页纸清单快速过一遍。这一页纸不用写废话按 PRD 的功能点列出来每项跟一个验证动作。表格列出来以后开发自测也可以用同一份省得两边标准不一致。功能点验证动作通过标准客户列表默认值登录后打开客户菜单默认展示查询方案“全部客户”按创建时间倒序客户名称搜索输入客户名称关键字对全部可见数据模糊搜索不可见客户不出现高级查询设置组织、成交状态、创建时间范围结果只含满足条件且权限可见的客户新增客户提交非空校验客户名称超 200 字符保存失败合法数据保存成功编辑客户修改名称、行业、负责人保存后行更新不重新排序不可批量编辑删除客户单条 / 批量删除有删除确认界面选中行被标记或删除更改负责人批量选择人员确定后选中客户负责人全部更新可批量操作导入导出下载模板导出当前页导入模板字段与文档一致导出结果为当前页数据七日未跟进创建无活动老客户超过 7 天且无活动记录才出现在列表客户详情点击客户名称可达基本信息、动态、相关、团队成员、层级客户合并找两条重复客户合并关联单据迁移正确被合并客户标记可追溯权限A 组织销售登录列表不出现 B 组织客户配合这个表我还有一个笨办法先把 pdf 转成文本用 grep 查 PRD 里的关键词再对照用例有没有覆盖。老 PRD 是 pdf 的时候最方便一条命令就够# 用 pdftotext 提取 PDF 文本直接定位验收点 pdftotext -layout 客户关系管理CRM_客户管理_PRD_V1.0.pdf - | grep -nE 不可批量|七日未跟进|全部客户|成交状态|工商注册 | head -20这行命令的本意不是替代人工评审而是帮你在提测前先把 PRD 里所有钉死过的字面规则找出来逐条问开发“这个测过没有”。没有覆盖到的直接补用例。有些团队的 PRD 原件是 Word 或者在线文档也可以导出成 pdf 再跑一遍这样关键词定位和评审留痕都方便。从那以后我每次接客户管理这类主数据模块都会先花三十分钟把字段来源、可空性、权限边界这三个高危项过一遍再让它进评审已经帮我把上线后的客户投诉压掉了大半。希望帮到你。本文还有配套的精品资源点击获取