尧图网站建设 
简介这份CRM客户关系管理需求分析设计文档面向企业信息化项目中的需求分析人员、产品经理与开发团队用于指导企业版CRM系统的设计与实施。文档围绕客户管理场景系统梳理了项目背景、用户组织结构与相关业务并给出业务对象说明及术语定义帮助团队统一理解系统边界。包内共1个doc文件约1.66MB内容涵盖功能需求划分、用例描述、数据概念结构图实体—关系图、系统业务流程图以及界面原型预览同时涉及运行环境、条件与限制等非功能需求。读者可据此掌握从需求调研到功能建模的完整思路理解销售流程自动化、客户信息整合与数据分析支持等目标的落地方式并借助用例与数据流图快速对齐开发实现。目前已有187人学习适合作为CRM项目需求文档的参考模板与学习范例。1. 从一份没人看的 CRM 需求分析设计文档说起很多团队做 CRM 客户关系管理项目第一周就拉个 Word 模板把「客户管理、商机管理、合同管理、报表统计」四大模块填进去评审会开完文档就进了共享盘再也没人打开。等到开发做到第三周销售跑过来说「我要在手机上直接拨号跟进」财务说「回款计划得跟合同分期挂钩」这时候才发现需求分析阶段漏掉的不是功能点而是角色和场景。CRM 需求分析设计文档真正要解决的不是把功能列全而是把「谁在什么场景下对哪条数据做什么动作」这条链路钉死让后面写库表、画接口、做权限的人有据可依。这篇笔记面向正在做 CRM 系统改造或从零搭建的研发、产品与实施同学我会按「先立住需求分析的骨架再落到设计文档的字段与接口最后讲怎么验证和避坑」的顺序把一份能直接进开发的需求分析设计文档拆开讲清楚。免费 CRM 与私人网站的区别在哪本质也在这份文档里——前者是标准化流程的裁剪后者是围绕自有业务长出来的数据模型需求分析的深度决定了你最终走哪条路。2. CRM 需求分析到底要分析什么角色、场景与数据流2.1 先分清三类需求别把功能清单当需求分析软件需求分析的基本概念里业务需求、用户需求、系统需求是三层但落到 CRM 上很多人直接跳到第三层。我一般会先画一张角色-场景矩阵把销售、销售主管、市场、客服、财务、系统管理员六个角色列在左列把线索获取、跟进、报价、签约、回款、续约、投诉七个场景列在顶行交叉格子里写「这个角色在这个场景下要看到什么数据、能改什么字段、触发什么通知」。这张表填不满说明需求分析还没做完别急着写设计文档。业务需求回答「为什么要做 CRM」比如线索转化率低、销售离职带走客户、回款逾期没人提醒。用户需求回答「销售每天怎么用」比如早上打开手机先看今天要跟进的五条线索点进去能直接拨号并自动记录通话时长。系统需求才是「线索表要有来源渠道字段、通话记录要关联线索 ID」。三层混在一起写评审时业务方看不懂开发也抓不住重点。常见做法是需求分析文档里用三个独立章节分别写每层末尾附一张追溯表标明这条需求来自哪个部门、对应哪个业务目标。2.2 用状态机把客户生命周期钉死避免后期无限加字段CRM 最容易被改烂的地方是客户状态。一开始只有「潜在、跟进中、已成交」上线三个月变成「潜在、初步接触、方案报价、商务谈判、已成交、已流失、公海」每加一个状态就要改一次代码和报表。根因是需求分析阶段没把状态流转规则写清楚。我一般会要求产品在需求分析文档里画一张客户状态机明确每个状态的进入条件、退出条件、可执行动作、超时规则。比如「跟进中」进入条件是销售认领线索并完成首次有效沟通退出条件是 30 天无跟进记录自动回公海可执行动作是写跟进、改商机阶段、转客户。这张状态机图不用 mermaid用表格写就行当前状态、触发事件、目标状态、执行角色、附加动作。开发拿到这张表库表里 status 字段的枚举值和流转校验逻辑直接照着写测试也能按状态迁移设计用例。需求分析仿真实验里常考的也是这类状态迁移覆盖头歌需求分析仿真实验的题型基本围绕状态图和用例图展开说明这是需求分析的核心技能不是可选项。2.3 数据流要写到字段级否则设计文档就是空中楼阁需求分析文档里写「线索转化为客户时同步信息」这句话开发没法落地。必须写到线索表的哪些字段映射到客户表的哪些字段映射规则是什么冲突时以谁为准。比如线索表的「公司名称」映射到客户表的「客户全称」线索表的「联系人手机」映射到客户联系人的「手机」如果客户表已存在同名客户是合并还是新建合并时保留哪个销售负责人。这些规则不写开发只能猜猜错就是上线后数据对不上。我习惯在需求分析文档里附一张字段映射表列包括源表、源字段、目标表、目标字段、转换规则、必填、默认值。转换规则里写清楚去空格、大小写、手机号格式校验、日期格式统一。这张表同时是设计文档里 ETL 脚本和接口字段定义的输入。字段级数据流还有一个好处当业务方后期说「我要在客户列表看到线索来源」你能快速定位到来源字段在线索表、转化时没同步到客户表改一行映射即可而不是全链路排查。3. 把需求分析翻译成设计文档库表、接口与权限3.1 库表设计从需求分析的实体关系图直接推导需求分析做完角色场景和数据流实体关系基本就出来了客户、联系人、线索、商机、合同、回款计划、跟进记录、用户、部门、角色。设计文档的库表章节不要重新发明直接按实体关系图建表。我一般会先写一张核心表清单标明表名、中文名、预估数据量、是否分表。CRM 里客户表和跟进记录表增长最快客户表百万级、跟进记录千万级很常见需求分析阶段就要问清楚日均跟进量决定跟进记录表是否按月分表或按客户 ID 哈希分片。字段设计上每个字段要有字段名、类型、长度、是否必填、默认值、索引、注释。注释里写业务含义比如source_channel注释「线索来源渠道枚举值见字典表 dict_source_channel」。枚举值不要散落在代码里设计文档里维护一张字典表所有下拉选项从字典表读。这样后期加渠道不用改代码运营在后台配就行。苍穹外卖数据库设计文档里也是这个思路字典表和业务表分离CRM 完全适用。-- CRM 核心表客户表与跟进记录表节选 CREATE TABLE crm_customer ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主键, customer_name VARCHAR(128) NOT NULL COMMENT 客户全称, short_name VARCHAR(64) DEFAULT NULL COMMENT 客户简称, source_channel VARCHAR(32) NOT NULL COMMENT 来源渠道关联 dict_source_channel, owner_user_id BIGINT NOT NULL COMMENT 负责人用户ID, dept_id BIGINT NOT NULL COMMENT 所属部门ID, status TINYINT NOT NULL DEFAULT 1 COMMENT 状态1跟进中 2已成交 3已流失, last_follow_time DATETIME DEFAULT NULL COMMENT 最后跟进时间, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_owner_status (owner_user_id, status), KEY idx_last_follow (last_follow_time) ) COMMENT客户表; CREATE TABLE crm_follow_record ( id BIGINT NOT NULL AUTO_INCREMENT, customer_id BIGINT NOT NULL COMMENT 客户ID, user_id BIGINT NOT NULL COMMENT 跟进人, follow_type TINYINT NOT NULL COMMENT 1电话 2拜访 3微信 4邮件, content TEXT NOT NULL COMMENT 跟进内容, next_follow_time DATETIME DEFAULT NULL COMMENT 下次跟进时间, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_customer_time (customer_id, create_time), KEY idx_next_follow (next_follow_time) ) COMMENT跟进记录表;上面两张表的关键点客户表的owner_user_id和dept_id是权限过滤的核心字段所有列表查询都要带上last_follow_time冗余在客户表避免每次查跟进记录表取最大值这是用空间换查询性能的常见做法。跟进记录表的next_follow_time建索引销售首页「今日待跟进」直接按这个字段查。参数上source_channel长度 32 够用content用 TEXT 不设长度上限但接口层要限制 2000 字防止恶意提交。分表策略如果日均跟进超过 50 万条建议按customer_id % 16分 16 张表设计文档里要写明分表键和路由规则。3.2 接口设计要覆盖需求分析里的每个用户动作需求分析里销售「点进去能直接拨号并自动记录通话时长」翻译成接口就是获取客户详情接口返回联系人手机号拨号由客户端调起系统能力通话结束后客户端调「新增跟进记录」接口带上通话时长和录音地址。设计文档里每个接口要写路径、方法、请求参数、响应字段、错误码、幂等要求、权限点。我一般按角色动作分组写接口而不是按资源分组。比如「销售跟进」分组下有今日待跟进列表、客户详情、新增跟进、修改下次跟进时间、转客户。「主管看板」分组下有团队跟进统计、商机漏斗、回款逾期列表。分组和需求分析的角色场景矩阵对应评审时业务方能直接找到自己关心的接口。权限点命名用crm:follow:add、crm:customer:transfer这种三段式设计文档里维护权限点清单开发照着配注解。// 新增跟进记录接口Spring Boot 示例节选 PostMapping(/api/crm/follow/add) RequirePermission(crm:follow:add) public ResultLong addFollow(RequestBody Valid FollowAddReq req) { // 1. 校验客户归属当前用户必须是客户负责人或同部门主管 Customer customer customerMapper.selectById(req.getCustomerId()); if (customer null) { return Result.fail(客户不存在); } if (!permissionService.canAccessCustomer(currentUserId(), customer)) { return Result.fail(无权跟进该客户); } // 2. 幂等同一客户同一分钟内的重复提交直接返回已有记录ID FollowRecord exist followMapper.selectRecent(req.getCustomerId(), currentUserId(), 60); if (exist ! null) { return Result.success(exist.getId()); } // 3. 写入跟进记录并更新客户最后跟进时间 FollowRecord record new FollowRecord(); record.setCustomerId(req.getCustomerId()); record.setUserId(currentUserId()); record.setFollowType(req.getFollowType()); record.setContent(req.getContent()); record.setNextFollowTime(req.getNextFollowTime()); followMapper.insert(record); customerMapper.updateLastFollowTime(req.getCustomerId(), new Date()); return Result.success(record.getId()); }这段代码里三个参数值得注意RequirePermission注解对应设计文档里的权限点清单幂等判断用「同一客户同一用户 60 秒内」作为窗口防止销售手抖连点更新last_follow_time用单独 SQL 而不是全量 update避免并发覆盖其他字段。错误码在设计文档里统一编号比如CRM_CUSTOMER_NOT_FOUND40001、CRM_NO_PERMISSION40301前端按码做提示不要靠解析 message。3.3 权限模型决定设计文档的查询复杂度CRM 的权限比一般后台复杂因为数据是按人、按部门隔离的。需求分析阶段必须问清楚销售只能看自己的客户主管能看本部门及下级的客户总监能看全部跨部门协作时能不能临时授权。这四种规则对应设计文档里权限过滤的四种 SQL 拼接方式。我一般用「数据范围」字段存在角色表上1 本人、2 本部门、3 本部门及下级、4 全部、5 自定义。查询时根据当前用户角色的数据范围动态拼owner_user_id ?或dept_id in (...)。自定义范围用一张crm_role_dept关联表存角色可见部门查询时先查关联表拿到部门 ID 列表再拼 IN。设计文档里要写明数据范围变更后是否需要刷新缓存缓存 key 怎么设计缓存过期时间多长。常见坑是权限改了但缓存没失效销售还能看到已转走的客户。我一般把权限缓存过期设 5 分钟并在角色变更接口里主动删缓存。查询复杂度上带数据范围的列表查询一定要在owner_user_id和dept_id上建索引否则数据量上来后主管看板会拖垮数据库。4. 需求分析设计文档的避坑与排查清单4.1 需求评审通过但开发反复返工场景没写到操作级现象需求评审会上业务方都说没问题开发做到一半销售跑来说「我要批量转移客户」开发说需求里没写产品说这是常识。原因需求分析只写到「客户转移」这个功能名没写是单条转移还是批量、转移后跟进记录跟不跟、原负责人还能不能看。解决需求分析文档里每个功能点必须附操作级描述包括入口位置、操作对象数量、前置条件、后置影响。批量转移要写明单次上限比如 200 条、异步还是同步、失败怎么提示。我一般要求产品在文档里贴原型截图或手绘草图没有图的功能点评审不通过。4.2 上线后报表数据对不上状态字段没有单一事实来源现象销售看自己的成交客户数是 12主管看团队汇总也是 12但财务看合同数是 10差 2 个。原因客户状态和合同状态是两套字段销售把客户标成「已成交」但合同还没录入或者合同录了但客户状态没改。解决需求分析阶段定义单一事实来源成交以合同为准客户状态由合同状态触发更新不允许手工改。设计文档里写清楚触发逻辑合同审批通过时更新客户状态为已成交合同作废时回退客户状态。报表统一从合同表统计客户表状态只做展示。这个规则不写进需求分析后期数据永远对不上。4.3 接口响应越来越慢列表查询没做字段裁剪和分页上限现象客户列表接口从 200ms 涨到 3s数据量才 5 万条。原因接口返回了客户全字段加关联的联系人、商机、跟进记录前端只用了名称和状态。解决设计文档里每个列表接口明确返回字段清单禁止SELECT *关联数据按需加载。分页参数设上限比如pageSize最大 100超过报错。我一般会在设计文档里给列表接口定一个响应时间指标P99 小于 500ms超过就要加缓存或改查询。排查时先看慢 SQL 日志再看是不是回表太多最后看索引有没有被数据范围查询破坏。4.4 权限改了不生效缓存与数据范围更新不同步现象销售转岗到另一个部门主管权限也给了但他还是看不到新部门客户重启服务才好。原因用户的数据范围缓存在登录时写入转岗后没刷新。解决设计文档里写明权限缓存的失效策略角色变更、部门变更、用户转岗三个接口都要主动删缓存。缓存 key 用crm:perm:{userId}过期时间 5 分钟兜底。排查时先查缓存里该用户的 dataScope 值再查数据库角色表对比是否一致。这个坑在 CRM 系统改造项目里特别常见因为老系统往往没有缓存失效机制改造时要补上。4.5 需求分析文档没人维护变更没有追溯记录现象上线半年后想加一个「客户标签」功能翻需求文档发现还是初版中间加的公海规则、跟进提醒都没记录。原因需求变更走的是聊天记录和邮件没回写文档。解决需求分析文档用版本号管理每次变更在文档末尾追加变更记录日期、变更人、变更内容、影响范围。设计文档同步更新库表和接口。我一般把需求文档和设计文档放同一个 Git 仓库变更走 MR评审通过才合并。这样任何时候都能查到某个字段是哪次需求加的、为什么加。没有追溯记录后期维护就是黑匣子谁都不敢改。5. 用 AI 辅助需求分析从需求分析书到可执行设计文档的验证技巧现在很多团队在试「如何通过 AI 把系统需求分析书实现成系统」我的经验是 AI 能加速但不能替代判断。具体做法把需求分析文档按角色场景拆成结构化 JSON每个场景包含角色、触发条件、操作步骤、数据字段、权限要求然后让 AI 生成库表 DDL 和接口定义草稿人工再逐条核对。核对时重点看三处状态流转是否闭环、权限过滤是否覆盖所有查询、字段映射是否有遗漏。AI 生成的 DDL 经常忘记加索引和注释接口定义经常漏错误码这两块必须人工补。验证设计文档是否可执行我常用一个「三问法」拿任意一个用户故事问库表能不能支持、接口能不能满足、权限能不能控制。三个都答得上这条需求才算落地。比如「销售离职后客户自动回公海」库表要有owner_user_id和last_follow_time接口要有定时任务扫描超时客户并更新负责人权限要允许主管操作公海。三问有一问答不上就回到需求分析补。这个习惯帮我省了很多后悔药也让我在评审时能快速判断一份设计文档是能进开发还是只能进档案柜。需求分析仿真实验里常做的用例覆盖其实和这个三问法是一回事每个用例至少覆盖一条正常流和两条异常流。异常流里最容易被忽略的是并发和超时比如两个销售同时认领同一条线索设计文档里要写清楚用乐观锁还是分布式锁锁的粒度是线索 ID 还是客户 ID。我一般用数据库唯一索引兜底crm_lead_claim表对lead_id建唯一索引插入失败就提示已被认领简单可靠。最后说一个我自己的习惯每份需求分析设计文档定稿前我会假装自己是三个月后接手这个项目的开发只看文档能不能把库表建出来、接口写出来、权限配出来。如果中间卡壳说明文档还有洞。这个习惯不高级但能挡住大部分返工。希望帮到你。本文还有配套的精品资源点击获取 CRM需求分析设计文档实战：从角色场景到库表接口的完整拆解
简介这份CRM客户关系管理需求分析设计文档面向企业信息化项目中的需求分析人员、产品经理与开发团队用于指导企业版CRM系统的设计与实施。文档围绕客户管理场景系统梳理了项目背景、用户组织结构与相关业务并给出业务对象说明及术语定义帮助团队统一理解系统边界。包内共1个doc文件约1.66MB内容涵盖功能需求划分、用例描述、数据概念结构图实体—关系图、系统业务流程图以及界面原型预览同时涉及运行环境、条件与限制等非功能需求。读者可据此掌握从需求调研到功能建模的完整思路理解销售流程自动化、客户信息整合与数据分析支持等目标的落地方式并借助用例与数据流图快速对齐开发实现。目前已有187人学习适合作为CRM项目需求文档的参考模板与学习范例。1. 从一份没人看的 CRM 需求分析设计文档说起很多团队做 CRM 客户关系管理项目第一周就拉个 Word 模板把「客户管理、商机管理、合同管理、报表统计」四大模块填进去评审会开完文档就进了共享盘再也没人打开。等到开发做到第三周销售跑过来说「我要在手机上直接拨号跟进」财务说「回款计划得跟合同分期挂钩」这时候才发现需求分析阶段漏掉的不是功能点而是角色和场景。CRM 需求分析设计文档真正要解决的不是把功能列全而是把「谁在什么场景下对哪条数据做什么动作」这条链路钉死让后面写库表、画接口、做权限的人有据可依。这篇笔记面向正在做 CRM 系统改造或从零搭建的研发、产品与实施同学我会按「先立住需求分析的骨架再落到设计文档的字段与接口最后讲怎么验证和避坑」的顺序把一份能直接进开发的需求分析设计文档拆开讲清楚。免费 CRM 与私人网站的区别在哪本质也在这份文档里——前者是标准化流程的裁剪后者是围绕自有业务长出来的数据模型需求分析的深度决定了你最终走哪条路。2. CRM 需求分析到底要分析什么角色、场景与数据流2.1 先分清三类需求别把功能清单当需求分析软件需求分析的基本概念里业务需求、用户需求、系统需求是三层但落到 CRM 上很多人直接跳到第三层。我一般会先画一张角色-场景矩阵把销售、销售主管、市场、客服、财务、系统管理员六个角色列在左列把线索获取、跟进、报价、签约、回款、续约、投诉七个场景列在顶行交叉格子里写「这个角色在这个场景下要看到什么数据、能改什么字段、触发什么通知」。这张表填不满说明需求分析还没做完别急着写设计文档。业务需求回答「为什么要做 CRM」比如线索转化率低、销售离职带走客户、回款逾期没人提醒。用户需求回答「销售每天怎么用」比如早上打开手机先看今天要跟进的五条线索点进去能直接拨号并自动记录通话时长。系统需求才是「线索表要有来源渠道字段、通话记录要关联线索 ID」。三层混在一起写评审时业务方看不懂开发也抓不住重点。常见做法是需求分析文档里用三个独立章节分别写每层末尾附一张追溯表标明这条需求来自哪个部门、对应哪个业务目标。2.2 用状态机把客户生命周期钉死避免后期无限加字段CRM 最容易被改烂的地方是客户状态。一开始只有「潜在、跟进中、已成交」上线三个月变成「潜在、初步接触、方案报价、商务谈判、已成交、已流失、公海」每加一个状态就要改一次代码和报表。根因是需求分析阶段没把状态流转规则写清楚。我一般会要求产品在需求分析文档里画一张客户状态机明确每个状态的进入条件、退出条件、可执行动作、超时规则。比如「跟进中」进入条件是销售认领线索并完成首次有效沟通退出条件是 30 天无跟进记录自动回公海可执行动作是写跟进、改商机阶段、转客户。这张状态机图不用 mermaid用表格写就行当前状态、触发事件、目标状态、执行角色、附加动作。开发拿到这张表库表里 status 字段的枚举值和流转校验逻辑直接照着写测试也能按状态迁移设计用例。需求分析仿真实验里常考的也是这类状态迁移覆盖头歌需求分析仿真实验的题型基本围绕状态图和用例图展开说明这是需求分析的核心技能不是可选项。2.3 数据流要写到字段级否则设计文档就是空中楼阁需求分析文档里写「线索转化为客户时同步信息」这句话开发没法落地。必须写到线索表的哪些字段映射到客户表的哪些字段映射规则是什么冲突时以谁为准。比如线索表的「公司名称」映射到客户表的「客户全称」线索表的「联系人手机」映射到客户联系人的「手机」如果客户表已存在同名客户是合并还是新建合并时保留哪个销售负责人。这些规则不写开发只能猜猜错就是上线后数据对不上。我习惯在需求分析文档里附一张字段映射表列包括源表、源字段、目标表、目标字段、转换规则、必填、默认值。转换规则里写清楚去空格、大小写、手机号格式校验、日期格式统一。这张表同时是设计文档里 ETL 脚本和接口字段定义的输入。字段级数据流还有一个好处当业务方后期说「我要在客户列表看到线索来源」你能快速定位到来源字段在线索表、转化时没同步到客户表改一行映射即可而不是全链路排查。3. 把需求分析翻译成设计文档库表、接口与权限3.1 库表设计从需求分析的实体关系图直接推导需求分析做完角色场景和数据流实体关系基本就出来了客户、联系人、线索、商机、合同、回款计划、跟进记录、用户、部门、角色。设计文档的库表章节不要重新发明直接按实体关系图建表。我一般会先写一张核心表清单标明表名、中文名、预估数据量、是否分表。CRM 里客户表和跟进记录表增长最快客户表百万级、跟进记录千万级很常见需求分析阶段就要问清楚日均跟进量决定跟进记录表是否按月分表或按客户 ID 哈希分片。字段设计上每个字段要有字段名、类型、长度、是否必填、默认值、索引、注释。注释里写业务含义比如source_channel注释「线索来源渠道枚举值见字典表 dict_source_channel」。枚举值不要散落在代码里设计文档里维护一张字典表所有下拉选项从字典表读。这样后期加渠道不用改代码运营在后台配就行。苍穹外卖数据库设计文档里也是这个思路字典表和业务表分离CRM 完全适用。-- CRM 核心表客户表与跟进记录表节选 CREATE TABLE crm_customer ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主键, customer_name VARCHAR(128) NOT NULL COMMENT 客户全称, short_name VARCHAR(64) DEFAULT NULL COMMENT 客户简称, source_channel VARCHAR(32) NOT NULL COMMENT 来源渠道关联 dict_source_channel, owner_user_id BIGINT NOT NULL COMMENT 负责人用户ID, dept_id BIGINT NOT NULL COMMENT 所属部门ID, status TINYINT NOT NULL DEFAULT 1 COMMENT 状态1跟进中 2已成交 3已流失, last_follow_time DATETIME DEFAULT NULL COMMENT 最后跟进时间, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_owner_status (owner_user_id, status), KEY idx_last_follow (last_follow_time) ) COMMENT客户表; CREATE TABLE crm_follow_record ( id BIGINT NOT NULL AUTO_INCREMENT, customer_id BIGINT NOT NULL COMMENT 客户ID, user_id BIGINT NOT NULL COMMENT 跟进人, follow_type TINYINT NOT NULL COMMENT 1电话 2拜访 3微信 4邮件, content TEXT NOT NULL COMMENT 跟进内容, next_follow_time DATETIME DEFAULT NULL COMMENT 下次跟进时间, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_customer_time (customer_id, create_time), KEY idx_next_follow (next_follow_time) ) COMMENT跟进记录表;上面两张表的关键点客户表的owner_user_id和dept_id是权限过滤的核心字段所有列表查询都要带上last_follow_time冗余在客户表避免每次查跟进记录表取最大值这是用空间换查询性能的常见做法。跟进记录表的next_follow_time建索引销售首页「今日待跟进」直接按这个字段查。参数上source_channel长度 32 够用content用 TEXT 不设长度上限但接口层要限制 2000 字防止恶意提交。分表策略如果日均跟进超过 50 万条建议按customer_id % 16分 16 张表设计文档里要写明分表键和路由规则。3.2 接口设计要覆盖需求分析里的每个用户动作需求分析里销售「点进去能直接拨号并自动记录通话时长」翻译成接口就是获取客户详情接口返回联系人手机号拨号由客户端调起系统能力通话结束后客户端调「新增跟进记录」接口带上通话时长和录音地址。设计文档里每个接口要写路径、方法、请求参数、响应字段、错误码、幂等要求、权限点。我一般按角色动作分组写接口而不是按资源分组。比如「销售跟进」分组下有今日待跟进列表、客户详情、新增跟进、修改下次跟进时间、转客户。「主管看板」分组下有团队跟进统计、商机漏斗、回款逾期列表。分组和需求分析的角色场景矩阵对应评审时业务方能直接找到自己关心的接口。权限点命名用crm:follow:add、crm:customer:transfer这种三段式设计文档里维护权限点清单开发照着配注解。// 新增跟进记录接口Spring Boot 示例节选 PostMapping(/api/crm/follow/add) RequirePermission(crm:follow:add) public ResultLong addFollow(RequestBody Valid FollowAddReq req) { // 1. 校验客户归属当前用户必须是客户负责人或同部门主管 Customer customer customerMapper.selectById(req.getCustomerId()); if (customer null) { return Result.fail(客户不存在); } if (!permissionService.canAccessCustomer(currentUserId(), customer)) { return Result.fail(无权跟进该客户); } // 2. 幂等同一客户同一分钟内的重复提交直接返回已有记录ID FollowRecord exist followMapper.selectRecent(req.getCustomerId(), currentUserId(), 60); if (exist ! null) { return Result.success(exist.getId()); } // 3. 写入跟进记录并更新客户最后跟进时间 FollowRecord record new FollowRecord(); record.setCustomerId(req.getCustomerId()); record.setUserId(currentUserId()); record.setFollowType(req.getFollowType()); record.setContent(req.getContent()); record.setNextFollowTime(req.getNextFollowTime()); followMapper.insert(record); customerMapper.updateLastFollowTime(req.getCustomerId(), new Date()); return Result.success(record.getId()); }这段代码里三个参数值得注意RequirePermission注解对应设计文档里的权限点清单幂等判断用「同一客户同一用户 60 秒内」作为窗口防止销售手抖连点更新last_follow_time用单独 SQL 而不是全量 update避免并发覆盖其他字段。错误码在设计文档里统一编号比如CRM_CUSTOMER_NOT_FOUND40001、CRM_NO_PERMISSION40301前端按码做提示不要靠解析 message。3.3 权限模型决定设计文档的查询复杂度CRM 的权限比一般后台复杂因为数据是按人、按部门隔离的。需求分析阶段必须问清楚销售只能看自己的客户主管能看本部门及下级的客户总监能看全部跨部门协作时能不能临时授权。这四种规则对应设计文档里权限过滤的四种 SQL 拼接方式。我一般用「数据范围」字段存在角色表上1 本人、2 本部门、3 本部门及下级、4 全部、5 自定义。查询时根据当前用户角色的数据范围动态拼owner_user_id ?或dept_id in (...)。自定义范围用一张crm_role_dept关联表存角色可见部门查询时先查关联表拿到部门 ID 列表再拼 IN。设计文档里要写明数据范围变更后是否需要刷新缓存缓存 key 怎么设计缓存过期时间多长。常见坑是权限改了但缓存没失效销售还能看到已转走的客户。我一般把权限缓存过期设 5 分钟并在角色变更接口里主动删缓存。查询复杂度上带数据范围的列表查询一定要在owner_user_id和dept_id上建索引否则数据量上来后主管看板会拖垮数据库。4. 需求分析设计文档的避坑与排查清单4.1 需求评审通过但开发反复返工场景没写到操作级现象需求评审会上业务方都说没问题开发做到一半销售跑来说「我要批量转移客户」开发说需求里没写产品说这是常识。原因需求分析只写到「客户转移」这个功能名没写是单条转移还是批量、转移后跟进记录跟不跟、原负责人还能不能看。解决需求分析文档里每个功能点必须附操作级描述包括入口位置、操作对象数量、前置条件、后置影响。批量转移要写明单次上限比如 200 条、异步还是同步、失败怎么提示。我一般要求产品在文档里贴原型截图或手绘草图没有图的功能点评审不通过。4.2 上线后报表数据对不上状态字段没有单一事实来源现象销售看自己的成交客户数是 12主管看团队汇总也是 12但财务看合同数是 10差 2 个。原因客户状态和合同状态是两套字段销售把客户标成「已成交」但合同还没录入或者合同录了但客户状态没改。解决需求分析阶段定义单一事实来源成交以合同为准客户状态由合同状态触发更新不允许手工改。设计文档里写清楚触发逻辑合同审批通过时更新客户状态为已成交合同作废时回退客户状态。报表统一从合同表统计客户表状态只做展示。这个规则不写进需求分析后期数据永远对不上。4.3 接口响应越来越慢列表查询没做字段裁剪和分页上限现象客户列表接口从 200ms 涨到 3s数据量才 5 万条。原因接口返回了客户全字段加关联的联系人、商机、跟进记录前端只用了名称和状态。解决设计文档里每个列表接口明确返回字段清单禁止SELECT *关联数据按需加载。分页参数设上限比如pageSize最大 100超过报错。我一般会在设计文档里给列表接口定一个响应时间指标P99 小于 500ms超过就要加缓存或改查询。排查时先看慢 SQL 日志再看是不是回表太多最后看索引有没有被数据范围查询破坏。4.4 权限改了不生效缓存与数据范围更新不同步现象销售转岗到另一个部门主管权限也给了但他还是看不到新部门客户重启服务才好。原因用户的数据范围缓存在登录时写入转岗后没刷新。解决设计文档里写明权限缓存的失效策略角色变更、部门变更、用户转岗三个接口都要主动删缓存。缓存 key 用crm:perm:{userId}过期时间 5 分钟兜底。排查时先查缓存里该用户的 dataScope 值再查数据库角色表对比是否一致。这个坑在 CRM 系统改造项目里特别常见因为老系统往往没有缓存失效机制改造时要补上。4.5 需求分析文档没人维护变更没有追溯记录现象上线半年后想加一个「客户标签」功能翻需求文档发现还是初版中间加的公海规则、跟进提醒都没记录。原因需求变更走的是聊天记录和邮件没回写文档。解决需求分析文档用版本号管理每次变更在文档末尾追加变更记录日期、变更人、变更内容、影响范围。设计文档同步更新库表和接口。我一般把需求文档和设计文档放同一个 Git 仓库变更走 MR评审通过才合并。这样任何时候都能查到某个字段是哪次需求加的、为什么加。没有追溯记录后期维护就是黑匣子谁都不敢改。5. 用 AI 辅助需求分析从需求分析书到可执行设计文档的验证技巧现在很多团队在试「如何通过 AI 把系统需求分析书实现成系统」我的经验是 AI 能加速但不能替代判断。具体做法把需求分析文档按角色场景拆成结构化 JSON每个场景包含角色、触发条件、操作步骤、数据字段、权限要求然后让 AI 生成库表 DDL 和接口定义草稿人工再逐条核对。核对时重点看三处状态流转是否闭环、权限过滤是否覆盖所有查询、字段映射是否有遗漏。AI 生成的 DDL 经常忘记加索引和注释接口定义经常漏错误码这两块必须人工补。验证设计文档是否可执行我常用一个「三问法」拿任意一个用户故事问库表能不能支持、接口能不能满足、权限能不能控制。三个都答得上这条需求才算落地。比如「销售离职后客户自动回公海」库表要有owner_user_id和last_follow_time接口要有定时任务扫描超时客户并更新负责人权限要允许主管操作公海。三问有一问答不上就回到需求分析补。这个习惯帮我省了很多后悔药也让我在评审时能快速判断一份设计文档是能进开发还是只能进档案柜。需求分析仿真实验里常做的用例覆盖其实和这个三问法是一回事每个用例至少覆盖一条正常流和两条异常流。异常流里最容易被忽略的是并发和超时比如两个销售同时认领同一条线索设计文档里要写清楚用乐观锁还是分布式锁锁的粒度是线索 ID 还是客户 ID。我一般用数据库唯一索引兜底crm_lead_claim表对lead_id建唯一索引插入失败就提示已被认领简单可靠。最后说一个我自己的习惯每份需求分析设计文档定稿前我会假装自己是三个月后接手这个项目的开发只看文档能不能把库表建出来、接口写出来、权限配出来。如果中间卡壳说明文档还有洞。这个习惯不高级但能挡住大部分返工。希望帮到你。本文还有配套的精品资源点击获取