CRM需求分析设计文档怎么写？从业务域到权限矩阵的实战指南

简介：面向企业CRM系统建设与产品设计人员的需求分析设计文档，系统梳理客户关系管理的核心业务场景与流程，适合需求分析师、产品经理、项目经理及开发人员参考。内容为单个doc文件，整体约1.66MB，包含用例描述、数据概念结构图、系统业务流程图及界面原型等，从项目背景、用户组织结构、业务对象定义到功能需求、性能指标均有完整阐述。文档以企业实际客户管理痛点切入，明确提升销售流程自动化、整合客户信息、提供数据分析支持等目标，并覆盖运行环境、软硬件要求、条件与限制等实施要点，同时提供详细的用例场景、实体关系图及流程活动图，便于团队统一需求口径并指导后续开发。上线以来已有188人学习，适合作为CRM系统从需求调研、功能设计到项目落地的实用蓝本。

1. 拿到这个标题，先把它当项目总开关：CRM需求分析设计文档到底要压住什么

“crm客户关系管理需求分析设计文档”这个标题，搁在我过去带项目的习惯里，就是一架项目总开关：业务靠它确认“我想要的有没有被听懂”，开发靠它估工期和数据表，测试靠它写用例和验收口径。评审会上一旦签字，模块边界、字段含义、谁有权限，全都按这份文档执行。这篇笔记要解决的问题很具体：拿到这个标题后，从哪一页开始写，怎么写才能让业务说“对，这就是我要的”，让开发说“能估工期”，让测试说“验收标准够了”。适合三类人：刚接手CRM产品的中后台产品、被派来做需求分析的业务分析师、想自己搭轻量CRM的技术负责人。反直觉的一点是：文档的重心不在CRM功能清单，而在“口径”——同一个“客户”，销售说是成交客户，运营说是注册客户，财务说是回款客户。文档有一半篇幅，其实是在跟口径打架。

2. 先厘清业务边界：CRM该拆成哪几个域，需求才不会漏

不谈系统，先谈业务主线。CRM的“客户关系管理”这一串字，在大多数企业里并不等于“管客户”，而等于“从线索到回款”的一整条链路。我见过的方案，无论规模大小，几乎都逃不开这几个域：线索、客户、联系人、商机、报价、合同、回款、售后、报表。差别只在哪些域放进本版本、哪些域留着后续迭代。这个“域划分”，就是需求文档第一章要定的东西。

2.1 从线索到回款：先画一张CRM业务主线表

常见做法是先画一张泳道图，但文档阶段我更依赖一张对象表，因为后面所有评审都对着这张表说话。主线永远是这一条：线索进来，转成客户，挂上联系人，建商机，报价，签合同，走回款，进售后。每一段对应一个或几个业务对象，每个业务对象又对应一套状态和权限。我一般会用下面这张表当需求文档第一章的主表：

这张表的价值不在罗列模块，而在“裁剪”。比如做标准订阅制产品的小团队，报价、合同、回款可能归财务系统管，CRM只留线索、客户、商机、跟进四件套；做项目制销售的公司，则可能要加投标、立项两个域。文档里每个域都要写一行“纳入或不纳入的理由”，否则评审时业务会问“为什么别人家有的我们没有”。

裁剪比追加难。后期加一个域，不是加一个菜单，而是加一条数据链路：线索要能转过来，商机要挂到客户上，回款要对上合同，每一步都要动数据模型。所以我在评审时最怕听到“这个先不做，以后再挂”，一旦数据模型没预留关联字段，后挂的成本比新建一个系统还高。翻车经验里至少有三次是因为这里没较真。

2.2 用“角色×对象×动作”盘需求，比抄竞品清单靠谱

很多人拿到CRM需求，第一反应是打开别人家的Demo抄菜单。抄来的东西叫功能列表，不是需求列表，因为它漏掉了两件事：谁在用、用了之后数据流到哪。我习惯用“角色×对象×动作”的矩阵来盘需求，先列角色，再列对象，最后列动作，三个交叉就是一个需求条目。

盘完矩阵，每个“角色×对象×动作”三元组就是一个需求条目，编上号，排队进后面的用例清单。这样做的理由是：抄竞品只能告诉你别人有什么，矩阵能告诉你这件事在你的公司里谁有权限、谁没权限、卡在哪个环节。比如“销售经理能不能看全部客户”根本不是功能问题，是数据权限问题，矩阵里一眼就能看出来。

我一般会把矩阵做成三列，最后一列标注“本期做不做”。盘点次序也固定：先角色后对象再动作，而不是先功能后角色。功能优先的盘法容易把审批、导入导出这类横切动作漏掉，等到数据清洗阶段才想起来，整个设计都要返工。

2.3 需求范围要写“不做什么”：边界清单

范围文档最容易被忽视的是边界。需求评审会上，业务问得最多的不是“有什么”，而是“为什么没有”。如果没有一张“本版本不做”的清单，开发会默认所有字段都要设计，业务会默认所有想象都能实现。

这里有个血泪经验：不要把“不做的事”写进功能清单里充当“预留”。一旦写了，开发认为这是需求，业务认为这是承诺，评审会当场吵起来。我自己的习惯是单独开一节“范围之外”，每条都写原因和替代方案，并且明确“本版本不做=不做设计，不做排期”。后续版本如果真要加，走变更流程，而不是在评审时靠记忆补。

3. 把需求写成人话：用例清单、业务规则与验收口径

域定完，进入用例层。需求文档的核心不是描述功能，而是描述行为。行为的载体就是用例。这里有个很容易走偏的点：不少人把CRM需求文档写成了系统操作说明书，逐菜单截图，结果业务说看不懂，开发说没信息量。用例的好处是两头都能接住：业务读主流程，开发读异常路径，测试读验收口径。

3.1 先给所有需求编优先级：P0/P1/P2 的判定标准

CRM的需求永远做不完，所以优先级要先定。我常用的是P0/P1/P2三档，对应莫斯科法则里的Must/Should/Could，但判定标准会比理论更实一点。

注意，P0不能按菜单数量来定，要按业务断点来定。比如一家不做合同管理的小团队，回款登记在财务Excel里，那么合同和回款就不能算P0；而“重复客户合并”看起来只有一个按钮，但它关系到销售会不会互相抢单，必须P0。我在文档里会给每个P0写一句话理由，理由跟着业务主线走，而不是跟着竞品菜单走。

优先级定完，还要定一条主线版本范围。我的做法是：在用例清单前放一张需求总表，每行一个需求条目，包含编号、模块、优先级、状态；评审会上只讨论P0和P1，P2由产品自行判断是否纳入。这样能有效避免评审会开了三个小时，最后吵的都是“导出要不要做”这类边角。

3.2 用标准用例模板写“跟进记录”，别让业务又说你没懂

跟进记录是CRM里最容易吵起来的对象，因为它介于“事实记录”和“任务计划”之间。有的团队把跟进写成流水账，有的团队要求自动生成下一次跟进提醒。混在一起是常见的“翻车”点。我的建议是在需求里拆成两个对象：跟进记录和待办任务。下面这条用例写的是前者。

为什么说这条用例能挡住评审争议？因为主流程人人都能走，异常路径才是需求的分水岭。“跟进记录能否脱离客户存在”这是数据模型问题；“同一天能不能记多条”这是业务规则问题；“保存后列表怎么刷新”这是验收口径问题。这三个问题在用例里写死，开发不用猜，测试不用反复问。

我再补一句：如果需求里需要提醒销售“该跟进谁了”，那建议单独建一个“待办任务”对象，字段至少包括任务类型、对象类型、对象ID、截止时间、完成状态。不要把提醒逻辑塞进跟进记录里，否则开发既要维护记录又要维护标记位，字段设计会很别扭。

3.3 字段字典表：客户、联系人、商机各字段从哪里来

用例管行为，字段字典管数据。字段字典是把人话翻译成数据的地方，评审会上关于“字段要不要”“必填选什么”的争论，应该在这一节结束。下面给出三个核心对象的字段字典示例，这三张表我建议放在需求文档的正文里，而不是附件里。

口径统一是这份文档最值钱的地方。“预计金额含不含税”写进字段字典后，报表和财务对账才不用翻聊天记录。评审会上业务最容易吵的就是“预计签单日”：销售说这是客户口头承诺的日期，财务说按合同生效日。凡是你提前写了口径的字段，评审就是走过场；没写的，就是开战。

4. 从需求到设计：数据模型、状态机与权限矩阵怎么落地

当用例和字段口径评审通过，设计部分要回答三个问题：表怎么建、状态怎么流转、谁能看谁的数据。这三个问题写在同一个章节，开发才不会来回打补丁。常见做法是：数据模型管结构，状态机管行为，权限矩阵管边界，三者独立成节，但相互引用。

4.1 对象关系先写清楚：谁挂谁、一对多还是一对一

需求文档的数据模型部分不需要画出标准ER图，工具不同反而增加沟通成本。我用一张对象关系表来表达，每行一条关系，列清楚基数和级联规则。

在设计里最容易翻车的是删除规则。CRM里几乎不做物理删除，我一般会统一写成软删除：所有对象带deleted_flag字段，界面上叫“失效”或“归档”，开发查询时默认过滤。这个规则写进需求文档的好处是，业务不会在回收站里找删掉的客户，开发也不用担心外键约束断掉。

还有一个选型点：报价单和合同要不要分开建模。常见做法是，标准销售产品里报价单只是PDF附件，不单独建表；项目型销售里报价单要建模，且一个商机可以对应多版报价。这个决定影响字段字典和状态机，必须在设计章节明确写出来，否则开发定义表结构时会卡住。

4.2 状态机先写清楚：商机阶段和合同审批都需要“回退”路径

状态机是CRM里最容易被低估的设计。很多需求文档只画了一条线，从新建到赢单，箭头一路朝前，完全不考虑误操作。评审会上业务一问“点错了怎么办”，全场沉默。在这里踩过的坑，几乎都是因为状态机没有画回退路径。

我把合同状态也写进同一节：草稿，提交审批，审批中，生效，作废。草稿和审批中允许撤销，生效后不允许删除，只能作废。这是两条最关键的规则，开发拿过去就能直接设计下拉框的枚举值。

给开发的建议也在这里写清楚：状态值存配置表，不写死进代码逻辑。这样后续业务要加一个“暂停跟进”状态，不用发版。需求文档里只需要约定“状态是枚举值，来源为配置表”，真正的枚举清单放到设计文档里维护。这个建议不是必须的，但能在项目后期省掉很多麻烦。

4.3 权限矩阵：功能权限之外，数据范围才是大头

权限设计分两块：功能权限和数据范围。功能权限解决“能不能点这个按钮”，数据范围解决“能看到谁的数据”。很多项目只做了第一块，上线后销售经理看不到团队数据，才想起来数据隔离没设计。

数据范围一般分四档：本人、本人及下级、本部门、全部。这个定义会随着组织架构树变化，所以文档里还要写一句“负责人字段是该条数据的Owner，Owner变更即权限变更”。权限配置可以用下面这段JSON作为对开发的表达方式，它不算正式配置，但比纯文字描述更不容易歧义：

{ "object": "opportunity", "defaultRule": "owner", "rules": [ { "role": "sales", "scope": "owner_only", "canEdit": true, "canDelete": false }, { "role": "sales_manager", "scope": "owner_and_subordinates", "canEdit": true, "canDelete": true }, { "role": "finance", "scope": "read_only_by_related_payment", "canEdit": false } ] }

这段JSON的语义是：商机对象默认按Owner隔离；销售只能看自己的，不能删；销售经理可以看自己和下属的，可以删；财务只能看与回款关联的商机，不能编辑。参数里scope是数据范围，canEdit和canDelete是功能权限。字段级权限这里没写，如果需要控制“财务可见金额但不可见联系方式”，要单独加一列字段权限，普通功能权限矩阵表达不了。

4.4 用一条SQL把核心指标口径钉死：以“销售漏斗”为例

需求文档里“销售漏斗”四个字高频出现，口径却经常打架：按商机数还是按金额？按创建时间还是按阶段变更时间？与其写在自然语言里被人反复追问，不如直接在文档的报告章节放一条SQL，把口径钉死。这里给出一个示例：

SELECT stage, COUNT(DISTINCT opportunity_id) AS opp_count, SUM(amount) AS total_amount FROM crm.opportunity WHERE expected_sign_date BETWEEN :start_date AND :end_date AND stage IN ('跟进中', '方案', '报价', '赢单') AND deleted_flag = 0 GROUP BY stage ORDER BY CASE stage WHEN '跟进中' THEN 1 WHEN '方案' THEN 2 WHEN '报价' THEN 3 WHEN '赢单' THEN 4 END;

这段SQL的逻辑说明：stage字段表示商机当前阶段；opp_count是不同商机数量；total_amount是商机金额合计；expected_sign_date是预计签单日，用来圈定统计周期；deleted_flag=0表示过滤掉已删除数据。ORDER BY那段是为了固定展示顺序，免得前端排序和漏斗图对不上。

在实际项目里，有的团队口径是“本月新建商机”，有的是“本月预计签单”，还有的是“本月进入该阶段的商机”。这三种口径结果差异很大，必须在文档里选一种并写明。我一般在文档里写两句话：“销售漏斗统计当前处于各阶段的商机数量和金额；统计周期按预计签单日归属。”一旦这句话定下来，后面所有报表都按这个口径走，不用每次开会再对一遍。

5. 埋雷与排查：CRM需求文档里最容易被评审揪出来的8个常见坑

这一章写我踩过的和帮别人排查过的坑。每一条都是评审会上真实出现过的场景，按“现象、原因、解决”三行拆开，方便你对号入座。

5.1 坑1：线索、客户、联系人三个对象混成一张表单

现象：需求文档里线索和客户字段几乎一模一样，开发建模时不知道哪个是主、哪个是副本，线索转化后字段要不要迁移也说不清楚。

原因：需求阶段把“潜在对象”和“成交对象”当成同一个东西，省掉了转化逻辑。尤其是小型团队，总觉得“客户不就是线索加个状态位吗”，结果后面做报表时全乱了。

解决：在文档里明确三个对象的差异。线索是“有成交可能的未知对象”，客户是“已建立联系的基本盘”，联系人挂在客户下。转化规则写一句：线索转客户后，线索联系人复制为第一联系人，原线索状态变为已转化且不允许再编辑。开发拿到这句就能建表，业务也不会再混着用。

5.2 坑2：重复客户排重规则没写手机为空场景

现象：测试导入1000条客户数据，发现同一家企业被建了5条；个人客户手机号为空时，排重功能彻底失效。

原因：唯一性校验只写了“手机号唯一”，没考虑企业客户没有手机号，也没考虑个人联系人可以有多个手机号。排重键定义得太单一。

解决：分两类排重键：企业客户按统一信用代码，个人客户按手机号加姓名；手机号为空时允许保存，但列表页给出重复提醒。合并规则也必须写：合并时保留主客户，商机和合同全部迁移到主客户下，被合并客户标记失效。排重触发时机分两个：手工新建时实时提醒，批量导入时先预检再入库。

5.3 坑3：状态机只画正向流程，漏掉“回退”和“撤销”

现象：销售误把商机标成赢单，系统不允许改回，最后只能找管理员改数据库。这属于口头需求没写全。

原因：状态机图只画了创建到关闭的单向线，没设计退回条件和权限。大家都默认“赢单了就不可能反悔”，但现实是错点、客户变卦、合同重谈都是常态。

解决：每个状态加两列：回退动作和回退权限。赢单可回退到报价，输单可回退到原阶段，但都必须有“撤销赢单”权限且记录操作日志。评审时直接拿这个场景问业务：误操作找谁？当场定下来，开发就不用回头补。

5.4 坑4：权限矩阵只画按钮，不画数据范围

现象：销售经理进了系统，只能看到自己的客户，看不到团队成员数据，业务反馈“系统坏了”。

原因：权限只定义了“能点哪些按钮”，没定义“能看到谁的数据”。开发和测试都按按钮级去实现，数据隔离自然就是默认各自独立。

解决：把权限矩阵拆成两列，一列功能权限，一列数据范围。数据范围分四档：本人、本人及下级、本部门、全部。并补充一句“负责人字段是Owner，Owner变更即数据范围变更”。这条写清楚后，开发只需要在查询条件里拼Scope条件，测试也敢写验证用例。

5.5 坑5：把“本期不做”写在需求列表里

现象：开发和业务对“有没有”产生了分歧，文档里明明有某个字段，业务坚持说“我以为这版本有”，开发说“这行字在范围之外”。

原因：范围章节把不做的条目列在“暂不实现”里，但后续版本维护时又把这一行复制到了功能清单，边界越描越糊。

解决：做一个独立的“本版本不做”清单，每条附原因和替代方案；凡是出现在功能清单里的条目，默认本期实现；凡是出现在“不做”清单里的条目，默认本期不设计。变更必须走变更记录，评审会上口头说改不算。

5.6 坑6：状态值没有定义默认值

现象：商机新建时阶段为空，测试和前端都不知道默认显示什么，最后只能等开发拍脑袋。

原因：字段字典只写了类型和必填，没写默认值。这是个很不起眼但影响面很大的遗漏。

解决：字段字典加一列“默认值”。商机阶段默认“跟进中”，客户状态默认“潜在”，跟进类型默认“电话”，下次跟进时间默认空。这一列全表扫一遍，能干掉后续一大批前端联调的琐碎bug。

5.7 坑7：字段字典里没写“是否可编辑”

现象：商机赢单后，销售仍然可以用详情页直接改金额，财务对账发现数字对不上，追查数据变更记录又查不到。

原因：字段字典只回答了“这字段存什么”，没回答“什么状态下这个字段能不能改”。所以开发默认所有字段都可编辑。

解决：在设计章节补一条级联规则：赢单后商机金额、客户、阶段字段全部只读，仅管理员可改。同理，合同生效后金额只读，回款已登记后合同作废需走审批。这类规则放在对象关系表和状态机表旁边，开发建表时就能一起考虑。

5.8 坑8：没有定义导出权限

现象：销售花了一分钟导出了全公司客户列表，数据安全评审才发现导出功能没人管。

原因：权限矩阵里漏了“导出”这一列，因为导出不是对象操作，是横切动作。对话框不长，十个角色九个会漏。

解决：导出必须单独授权，并且对导出字段做裁剪。销售只能导出本人客户的基础字段，不允许导出手机号全量；管理员导出要记录操作日志。导入也是同样的逻辑，导入模板不能包含敏感字段。这一条写进权限矩阵，数据安全这一关基本就过了。

6. 一份评审自检清单：用最小代价验证文档能不能落地

文档写完不是终点，评审过才算。我每次评审前会做三件事：过一遍自检清单，做一次端到端走查，把变更口径写到文档里。这三件事加起来半天左右，但能拦住会上80%的岔子。

6.1 用一张表做交付自检

6.2 端到端走查法：拿一条真实业务场景从头走一遍

找三个人，产品、开发、测试，用文档按一条场景走：新线索进来，转客户，建联系人，建商机，推进阶段，赢单，生成合同草稿，登记回款。每走一步，都在文档里找依据，对象关系表有没有、字段字典有没有、状态机有没有、权限矩阵有没有。找不到依据的地方，就是文档缺口，评审会之前补掉，比在会上被问住强十倍。这个方法逼着文档从“模块齐全”变成“链路自洽”，我把它当作标准动作执行。

6.3 变更怎么记：让评审结论成为文档的一部分

评审会开的结论如果不落进文档，等于白开。我的习惯是评审记录里每一条变更都映射到具体章节：改了范围、改字段、改状态、改权限、改口径。散会后当天更新文档，并把变更记录附在文档末尾，下一轮评审直接看变更。我自己的收尾习惯，是在评审前一天当一次刁钻用户，专挑管理员的权限、回退、口径这些边角去问，因为真正让项目翻车的永远是边角，不是主干。希望帮到你。

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