简介这份CRM客户关系管理需求分析设计文档面向企业信息化项目团队、产品经理与需求分析人员针对企业版CRM系统从立项到落地的完整需求梳理场景。文档围绕项目背景、用户组织结构、业务对象与术语定义、任务目标、运行环境及条件限制展开并深入功能需求、用例描述、数据概念结构图、系统业务流程图与界面原型帮助读者理解销售流程自动化、客户信息整合与数据分析支持等核心诉求。资源包为1个doc文件约1.66MB内容结构完整、章节编号清晰可直接作为需求规格说明书模板或课程设计参考。已有187人学习下载适合需要撰写CRM需求文档、梳理业务流程或准备系统设计答辩的读者对照使用能快速掌握从业务调研到功能建模的完整思路。1. 从一张没人看的 PRD 说起CRM 需求分析到底要交付什么很多团队做 CRM 项目第一周就拉群、画原型、排期第三周开发开始写代码上线后销售骂、客服骂、财务也骂。翻车现场几乎一模一样需求分析文档里写的是“支持客户全生命周期管理”开发理解成“建一张客户表加几个状态字段”销售想要的是“我能在手机上两秒查到昨天跟过的客户上次聊到哪”。同一句话三种理解最后交付一个谁都不用的系统。CRM 客户关系管理需求分析设计文档本质不是一份“写给领导看的材料”而是一份让业务、产品、开发、测试四方对同一件事达成共识的契约。它要回答四个问题客户数据从哪来、业务流程怎么走、权限边界在哪、系统之间怎么对接。适合正在做 CRM 选型、自研 CRM、或者接手别人 CRM 改造的从业者。这篇不聊虚的从需求怎么挖、文档怎么写、表怎么设计一路讲到上线后怎么验证中间会穿插我踩过的坑和能直接抄的模板结构。2. 需求分析阶段把“我想要”翻译成“系统能做”2.1 三类需求来源与访谈提纲CRM 的需求从来不是坐在工位上想出来的。我一般把来源分成三类一线使用者销售、客服、市场、管理层销售总监、运营负责人、外围系统ERP、财务、呼叫中心。三类人说的“需求”完全不是一个东西。销售说“我要快速录客户”翻译过来是移动端表单字段不超过 8 个、支持语音转文字、拍照识别名片。销售总监说“我要看团队漏斗”翻译过来是按阶段聚合的商机金额、支持按人/按周下钻、数据延迟不超过 5 分钟。财务说“我要对账”翻译过来是合同金额、回款计划、开票记录三张表能关联查询。访谈提纲我固定用下面这 10 个问题基本能覆盖 80% 的 CRM 场景1. 你每天打开系统第一件事是看什么 2. 最近一次因为系统不好用而发火是什么场景 3. 客户信息你目前记在哪Excel、微信、还是脑子里 4. 一个商机从线索到成交中间必须经过哪几个节点 5. 哪些数据你希望下属填哪些你希望系统自动带出来 6. 有没有两个部门抢同一个客户的情况现在怎么解决 7. 你希望收到什么提醒什么时候收到 8. 报表你目前手工做要多久希望系统出什么格式 9. 客户数据谁能看全、谁只能看自己离职了怎么交接 10. 如果只能上一个功能你选哪个这 10 个问题问完需求清单基本能收敛到 30 条以内。注意第 10 个问题它是用来排优先级的不是用来砍需求的。2.2 需求规格说明书的最小结构很多团队写需求文档喜欢套模板几十页下来开发根本不看。我的做法是主文档控制在 15 页以内复杂流程用附件补充。最小结构如下章节内容篇幅建议1. 项目背景与目标为什么做、不做会怎样、成功指标1 页2. 角色与权限矩阵谁用什么功能、数据可见范围1 页表格3. 核心业务流程线索→商机→合同→回款泳道图或步骤表3 页4. 功能需求清单按模块列每条带优先级和验收标准5 页5. 数据需求核心实体、字段、来源、校验规则2 页6. 接口需求与 ERP、呼叫中心、短信平台的对接2 页7. 非功能需求性能、并发、安全、备份1 页其中第 4 部分“功能需求清单”是开发最常翻的每条需求我要求写成这个格式需求编号CRM-LEAD-001 需求名称线索自动分配 优先级P0 描述新线索进入后按区域和销售负载自动分配给对应销售 分配结果 30 秒内推送到销售企业微信。 验收标准 - 新建线索后 30 秒内销售收到通知 - 分配规则可在后台配置无需改代码 - 分配失败时有兜底池不丢线索验收标准这一栏是关键。没有它测试不知道测什么开发也不知道做到什么程度算完。2.3 用仿真实验验证需求覆盖度“需求分析仿真实验”这个热词背后其实是一个很实用的做法在写代码之前用表格或轻量工具模拟一遍业务流程看需求有没有漏。我常用的是一个 Excel 仿真表列头如下步骤 | 操作角色 | 输入数据 | 系统动作 | 输出结果 | 异常分支 | 对应需求编号比如“销售录入回款”这一步步骤录入回款 操作角色销售 输入数据合同编号、回款金额、回款日期、银行流水号 系统动作校验合同是否存在、校验金额是否超合同总额、更新回款计划状态 输出结果回款记录生成、合同状态更新为“部分回款”或“已回款” 异常分支合同不存在→提示并阻止金额超额→提示并阻止重复流水号→提示并阻止 对应需求编号CRM-PAY-001、CRM-PAY-002把主流程和异常分支都走一遍你会发现很多“没想到”的情况。这一步花两个小时能省后面两周的返工。3. 设计文档阶段从实体关系图到接口契约3.1 核心实体与表结构设计CRM 的数据库设计说复杂也复杂说简单也简单。核心实体就那么几个客户、联系人、线索、商机、合同、回款、跟进记录、用户、角色、权限。难点不在表多少而在关系怎么定。我一般先画一张实体关系草图确定一对多、多对多关系再落表。下面是一个最小可用的客户与商机表设计-- 客户表 CREATE TABLE crm_customer ( id BIGINT PRIMARY KEY AUTO_INCREMENT, customer_name VARCHAR(128) NOT NULL COMMENT 客户名称, industry VARCHAR(64) COMMENT 所属行业, level TINYINT DEFAULT 3 COMMENT 客户等级 1-5, owner_id BIGINT NOT NULL COMMENT 归属销售ID, status TINYINT DEFAULT 1 COMMENT 1潜在 2跟进中 3已成交 4流失, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_owner (owner_id), INDEX idx_status (status) ) COMMENT 客户主表; -- 商机表 CREATE TABLE crm_opportunity ( id BIGINT PRIMARY KEY AUTO_INCREMENT, customer_id BIGINT NOT NULL COMMENT 关联客户, opportunity_name VARCHAR(128) NOT NULL, amount DECIMAL(14,2) DEFAULT 0 COMMENT 预计金额, stage TINYINT DEFAULT 1 COMMENT 1初步接触 2需求确认 3方案报价 4谈判 5赢单 6输单, expect_close_date DATE COMMENT 预计成交日期, owner_id BIGINT NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_customer (customer_id), INDEX idx_stage (stage), INDEX idx_owner_stage (owner_id, stage) ) COMMENT 商机表;几个参数说明level用 TINYINT 而不是 ENUM方便后续扩展等级stage用数字编码前端做映射避免改数据库owner_id上必须建索引因为销售最常用的查询就是“我的客户/我的商机”updated_at用 ON UPDATE 自动维护省得应用层漏写。3.2 权限模型RBAC 还是数据行级权限CRM 的权限比一般系统复杂因为它有两层功能权限能不能看某个菜单和数据权限能看哪些客户。功能权限用 RBAC 就够了数据权限才是坑。常见做法是“角色 数据范围”组合。数据范围我一般定义五种范围编码含义适用角色ALL全部数据总经理、系统管理员DEPT_AND_CHILD本部门及下级销售总监DEPT本部门销售经理SELF仅本人销售、客服CUSTOM自定义特殊场景实现上在用户表加data_scope字段查询时拼接 SQL 条件。注意不要用字符串拼接用 MyBatis 的动态 SQL 或 JPA 的 Specification// 伪代码根据数据范围拼接查询条件 public SpecificationCustomer buildDataScope(Long userId) { User user userMapper.selectById(userId); return (root, query, cb) - { switch (user.getDataScope()) { case ALL: return cb.conjunction(); case SELF: return cb.equal(root.get(ownerId), userId); case DEPT: return cb.equal(root.get(deptId), user.getDeptId()); case DEPT_AND_CHILD: ListLong deptIds deptMapper.selectChildDeptIds(user.getDeptId()); return root.get(deptId).in(deptIds); default: return cb.disjunction(); } }; }这段逻辑的关键是数据范围判断必须在服务端做不能靠前端隐藏按钮。我见过一个项目前端把“查看全部客户”的按钮藏了但接口没校验销售直接调接口拿到了全公司客户数据这就是血泪教训。3.3 接口契约与 ERP、呼叫中心怎么对接CRM 很少是孤岛通常要和 ERP 同步客户和合同和呼叫中心同步通话记录和短信平台同步通知。接口设计文档我要求写清楚四件事触发时机、数据方向、字段映射、失败处理。以“CRM 合同同步到 ERP”为例接口名称合同同步 触发时机CRM 合同状态变为“已审批” 数据方向CRM → ERP 传输方式HTTP POST JSON 字段映射 CRM.contract_no → ERP.contract_code CRM.customer_name → ERP.customer_name CRM.amount → ERP.total_amount CRM.sign_date → ERP.sign_date 失败处理 - 同步失败写入重试队列最多重试 3 次 - 3 次失败后告警给管理员支持手工重推 - 同步日志保留 90 天这里有个容易忽略的点字段映射要写清楚类型和长度。比如 CRM 的customer_name是 VARCHAR(128)ERP 那边如果是 VARCHAR(64)同步就会截断。这种问题上线后才发现修起来很麻烦。4. 避坑与排查CRM 项目最容易翻车的五个地方4.1 需求蔓延说好的只做客户管理最后做了个 ERP现象项目启动时范围是“客户商机合同”做到一半业务说“顺便把库存也管了吧”再后来“把财务也接进来吧”。结果工期翻倍核心功能反而没做好。原因需求分析阶段没有明确“不做什么”也没有变更控制流程。业务方觉得“加个功能而已”开发觉得“反正来都来了”。解决在需求文档第一页写清楚“本期范围”和“明确不做”任何新增需求走变更流程评估工期和影响后再决定。我一般会加一句“本期不包含库存管理、财务管理、生产管理如有需要另行立项。”4.2 数据迁移旧系统的客户数据一导入就乱现象旧 CRM 或 Excel 里的客户数据导入后出现大量重复客户、归属销售错乱、手机号格式不统一。原因旧数据没有唯一标识客户名称写法不一致“北京某某科技有限公司” vs “北京某某科技”销售归属靠人工填手机号有带区号的有不带的。解决迁移前先做数据清洗。客户名称做标准化去掉“有限公司”等后缀再比对手机号统一格式归属销售用旧系统的工号映射。导入时先导 100 条测试验证通过再全量。下面是一个清洗脚本的片段import re def normalize_customer_name(name): 标准化客户名称去空格、去后缀、转小写 if not name: return name name.strip().replace( , ) for suffix in [有限公司, 有限责任公司, 股份有限公司, 公司]: if name.endswith(suffix): name name[:-len(suffix)] return name.lower() def normalize_phone(phone): 标准化手机号去掉 86、区号、空格、横线 if not phone: return phone re.sub(r[\s\-], , str(phone)) phone re.sub(r^86, , phone) phone re.sub(r^0, , phone) return phone参数说明normalize_customer_name里的后缀列表要根据实际数据调整不要一刀切normalize_phone先去掉86再去掉前导0顺序不能反。4.3 权限漏洞销售能看到全公司客户现象销售 A 登录后通过修改 URL 参数或直接调接口能看到销售 B 的客户。原因前端做了权限控制后端接口没做数据范围校验。或者后端做了但某个查询接口漏了。解决所有涉及客户数据的查询接口必须强制拼接数据范围条件。测试时用不同角色的账号交叉验证重点测“通过 ID 直接查询”的接口。我一般会写一个自动化测试用例用销售账号去查不属于他的客户 ID断言返回空或 403。4.4 性能问题客户列表加载要 10 秒现象客户表数据到 10 万条以后列表页打开越来越慢销售抱怨“还不如用 Excel”。原因查询没有走索引或者用了SELECT *把大字段也查出来了或者分页用的是LIMIT offset, size在深分页时性能急剧下降。解决首先确认查询条件字段都有索引其次列表查询只查必要字段备注、附件等大字段单独查深分页改用“上一页最后一条 ID”的方式-- 不推荐深分页 SELECT * FROM crm_customer ORDER BY id LIMIT 100000, 20; -- 推荐基于游标 SELECT * FROM crm_customer WHERE id 100000 ORDER BY id LIMIT 20;注意游标分页要求排序字段唯一且有序一般用主键 ID。4.5 上线后没人用功能都有但销售就是不录现象系统上线一个月后台一看客户数据还是那几条销售还是用 Excel。原因录入太麻烦、移动端不好用、录了没好处。解决第一移动端表单字段砍到最少能自动带出的不要手填第二把“录客户”和“发提成”挂钩不录不算业绩第三找两个销售做种子用户让他们提意见改到他们愿意用为止。技术手段解决不了管理问题但技术可以让管理要求更容易执行。5. 上线前的验证清单与一个提效技巧5.1 需求覆盖度自查表开发完成不等于需求完成。上线前我一般用下面这张表做一轮自查每项都要有明确结论检查项检查方法通过标准功能需求覆盖逐条对照需求清单P0 需求 100% 实现P1 不低于 90%权限正确性用不同角色账号交叉测试无越权访问数据范围符合矩阵数据迁移完整性对比旧系统和新系统记录数差异率低于 0.1%且差异有说明接口连通性触发同步检查两端数据字段映射正确失败有重试和告警性能达标模拟 50 并发查询客户列表95% 请求响应时间低于 2 秒异常处理断网、重复提交、非法参数有友好提示不产生脏数据这张表看起来简单但每一条都能拦住一批问题。尤其是“异常处理”这一项很多团队不测上线后一断网就白屏。5.2 用 AI 辅助生成需求文档初稿“如何通过 AI 把系统需求分析书实现成系统”这个热词我的实际经验是AI 可以帮你写初稿但不能替你访谈。我的做法是把访谈记录和业务规则整理成结构化文本然后让 AI 生成需求文档初稿再人工逐条核对。提示词我一般这样写你是一名资深 CRM 产品经理。请根据以下访谈记录生成一份 CRM 需求规格说明书初稿。 要求 1. 按“角色与权限、核心流程、功能清单、数据需求、接口需求”五个部分组织。 2. 功能清单每条包含需求编号、名称、优先级、描述、验收标准。 3. 验收标准要可测试避免“友好”“快速”等模糊词。 4. 对访谈中未明确的信息标注“待确认”不要自行假设。 访谈记录如下 [粘贴访谈记录]生成后重点核对三件事验收标准是否可测试、权限矩阵是否完整、异常分支是否覆盖。AI 生成的初稿能省 60% 的排版时间但业务逻辑必须自己过一遍。5.3 一个习惯需求文档写完先让开发挑刺我做了这么多年 CRM最大的教训是需求文档写完不要直接发给业务确认先拉开发过一遍。开发会问出很多业务没想到的问题比如“客户合并时商机怎么处理”“销售离职后客户怎么交接”“同一个手机号能不能建两个客户”。这些问题在文档阶段解决成本是一句话在上线后解决成本是一次数据修复加一次客诉。所以我的习惯是需求文档初稿 → 开发评审 → 修改 → 业务确认 → 终稿。多花半天省后面两周。希望帮到你。本文还有配套的精品资源点击获取