★ FEATURED ARTICLE 简介面向企业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 需求范围要写“不做什么”边界清单范围文档最容易被忽视的是边界。需求评审会上业务问得最多的不是“有什么”而是“为什么没有”。如果没有一张“本版本不做”的清单开发会默认所有字段都要设计业务会默认所有想象都能实现。不做什么原因替代方案发票与税务管理与财务系统强耦合本期不接合同生效后由财务在线下导入回款市场活动ROI活动数据在营销工具里CRM只记来源CRM保留“来源渠道”字段多级审批流当前组织只有两级审批合同审批只做提交人审批人两级自定义字段配置为避免开发量失控首版固定字段预留5个扩展文本字段这里有个血泪经验不要把“不做的事”写进功能清单里充当“预留”。一旦写了开发认为这是需求业务认为这是承诺评审会当场吵起来。我自己的习惯是单独开一节“范围之外”每条都写原因和替代方案并且明确“本版本不做不做设计不做排期”。后续版本如果真要加走变更流程而不是在评审时靠记忆补。3. 把需求写成人话用例清单、业务规则与验收口径域定完进入用例层。需求文档的核心不是描述功能而是描述行为。行为的载体就是用例。这里有个很容易走偏的点不少人把CRM需求文档写成了系统操作说明书逐菜单截图结果业务说看不懂开发说没信息量。用例的好处是两头都能接住业务读主流程开发读异常路径测试读验收口径。3.1 先给所有需求编优先级P0/P1/P2 的判定标准CRM的需求永远做不完所以优先级要先定。我常用的是P0/P1/P2三档对应莫斯科法则里的Must/Should/Could但判定标准会比理论更实一点。优先级判定标准典型例子P0没有它业务主线跑不通新建客户、写跟进、建商机、赢单P1没有它日常运转效率明显下降线索分配、商机漏斗、重复客户提醒P2有它更好没有也能先上线批量编辑、自定义字段、自动报表注意P0不能按菜单数量来定要按业务断点来定。比如一家不做合同管理的小团队回款登记在财务Excel里那么合同和回款就不能算P0而“重复客户合并”看起来只有一个按钮但它关系到销售会不会互相抢单必须P0。我在文档里会给每个P0写一句话理由理由跟着业务主线走而不是跟着竞品菜单走。优先级定完还要定一条主线版本范围。我的做法是在用例清单前放一张需求总表每行一个需求条目包含编号、模块、优先级、状态评审会上只讨论P0和P1P2由产品自行判断是否纳入。这样能有效避免评审会开了三个小时最后吵的都是“导出要不要做”这类边角。3.2 用标准用例模板写“跟进记录”别让业务又说你没懂跟进记录是CRM里最容易吵起来的对象因为它介于“事实记录”和“任务计划”之间。有的团队把跟进写成流水账有的团队要求自动生成下一次跟进提醒。混在一起是常见的“翻车”点。我的建议是在需求里拆成两个对象跟进记录和待办任务。下面这条用例写的是前者。用例字段内容用例编号CRM-FU-001角色销售前置条件销售已登录目标客户已存在主流程1. 进入客户详情页点击“新增跟进”2. 选择跟进类型电话/拜访/线上沟通3. 填写跟进纪要4. 保存成功异常路径1当天已有多条跟进记录系统不限制按时间倒序展示异常路径2从客户详情页进入时客户自动带出不允许选择其他客户验收口径跟进记录保存后客户列表页展示最后跟进时间同一天多次跟进可见为什么说这条用例能挡住评审争议因为主流程人人都能走异常路径才是需求的分水岭。“跟进记录能否脱离客户存在”这是数据模型问题“同一天能不能记多条”这是业务规则问题“保存后列表怎么刷新”这是验收口径问题。这三个问题在用例里写死开发不用猜测试不用反复问。我再补一句如果需求里需要提醒销售“该跟进谁了”那建议单独建一个“待办任务”对象字段至少包括任务类型、对象类型、对象ID、截止时间、完成状态。不要把提醒逻辑塞进跟进记录里否则开发既要维护记录又要维护标记位字段设计会很别扭。3.3 字段字典表客户、联系人、商机各字段从哪里来用例管行为字段字典管数据。字段字典是把人话翻译成数据的地方评审会上关于“字段要不要”“必填选什么”的争论应该在这一节结束。下面给出三个核心对象的字段字典示例这三张表我建议放在需求文档的正文里而不是附件里。字段名类型必填口径说明客户名称string是企业客户填全称个人客户填姓名客户编号string系统生成不允许编辑手机号string个人客户必填个人客户排重键统一信用代码string企业客户必填企业客户排重键所属人string是默认当前用户可转会来源渠道string否枚举取自线索来源客户状态enum是潜在/有效/无效默认潜在字段名类型必填口径说明姓名string是手机号string是至少填一个联系方式邮箱string否是否决策人bool是默认否所属客户外键是删除客户时联系人保留字段名类型必填口径说明商机名称string是关联客户外键是商机不能脱离客户预计金额decimal是含税口径预计签单日date否按合同签订日期算不是回款日阶段enum是跟进中/方案/报价/赢单/输单赢率percent是阶段自动带出可手动调整口径统一是这份文档最值钱的地方。“预计金额含不含税”写进字段字典后报表和财务对账才不用翻聊天记录。评审会上业务最容易吵的就是“预计签单日”销售说这是客户口头承诺的日期财务说按合同生效日。凡是你提前写了口径的字段评审就是走过场没写的就是开战。4. 从需求到设计数据模型、状态机与权限矩阵怎么落地当用例和字段口径评审通过设计部分要回答三个问题表怎么建、状态怎么流转、谁能看谁的数据。这三个问题写在同一个章节开发才不会来回打补丁。常见做法是数据模型管结构状态机管行为权限矩阵管边界三者独立成节但相互引用。4.1 对象关系先写清楚谁挂谁、一对多还是一对一需求文档的数据模型部分不需要画出标准ER图工具不同反而增加沟通成本。我用一张对象关系表来表达每行一条关系列清楚基数和级联规则。源对象关联对象基数级联规则客户联系人1:N删除客户时联系人标记为失效不物理删除客户商机1:N商机始终挂在客户下线索客户1:1线索转化后原线索标记已转化不允许再编辑商机合同1:1赢单后生成合同草稿合同未生效前商机可改合同回款记录1:N一份合同登记多笔回款在设计里最容易翻车的是删除规则。CRM里几乎不做物理删除我一般会统一写成软删除所有对象带deleted_flag字段界面上叫“失效”或“归档”开发查询时默认过滤。这个规则写进需求文档的好处是业务不会在回收站里找删掉的客户开发也不用担心外键约束断掉。还有一个选型点报价单和合同要不要分开建模。常见做法是标准销售产品里报价单只是PDF附件不单独建表项目型销售里报价单要建模且一个商机可以对应多版报价。这个决定影响字段字典和状态机必须在设计章节明确写出来否则开发定义表结构时会卡住。4.2 状态机先写清楚商机阶段和合同审批都需要“回退”路径状态机是CRM里最容易被低估的设计。很多需求文档只画了一条线从新建到赢单箭头一路朝前完全不考虑误操作。评审会上业务一问“点错了怎么办”全场沉默。在这里踩过的坑几乎都是因为状态机没有画回退路径。状态触发动作前置条件后置动作跟进中新建商机客户已存在记录创建人方案/报价推进阶段商机未输单记录阶段变更时间赢单点击赢单填写合同金额、签单日自动生成合同草稿输单点击输单填写输单原因商机进入关闭列表回退撤销赢单/输单有回退权限记录日志回到步骤对应阶段我把合同状态也写进同一节草稿提交审批审批中生效作废。草稿和审批中允许撤销生效后不允许删除只能作废。这是两条最关键的规则开发拿过去就能直接设计下拉框的枚举值。给开发的建议也在这里写清楚状态值存配置表不写死进代码逻辑。这样后续业务要加一个“暂停跟进”状态不用发版。需求文档里只需要约定“状态是枚举值来源为配置表”真正的枚举清单放到设计文档里维护。这个建议不是必须的但能在项目后期省掉很多麻烦。4.3 权限矩阵功能权限之外数据范围才是大头权限设计分两块功能权限和数据范围。功能权限解决“能不能点这个按钮”数据范围解决“能看到谁的数据”。很多项目只做了第一块上线后销售经理看不到团队数据才想起来数据隔离没设计。角色查看新增编辑删除导出审批销售本人数据是本人数据本人线索/跟进否否销售经理本团队数据是本团队数据本团队商机本团队降价审批商务全部合同合同草稿合同草稿否合同提交审批财务回款关联数据回款记录回款记录否回款明细否管理员全部是是全部全部否数据范围一般分四档本人、本人及下级、本部门、全部。这个定义会随着组织架构树变化所以文档里还要写一句“负责人字段是该条数据的OwnerOwner变更即权限变更”。权限配置可以用下面这段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_flag0表示过滤掉已删除数据。ORDER BY那段是为了固定展示顺序免得前端排序和漏斗图对不上。在实际项目里有的团队口径是“本月新建商机”有的是“本月预计签单”还有的是“本月进入该阶段的商机”。这三种口径结果差异很大必须在文档里选一种并写明。我一般在文档里写两句话“销售漏斗统计当前处于各阶段的商机数量和金额统计周期按预计签单日归属。”一旦这句话定下来后面所有报表都按这个口径走不用每次开会再对一遍。5. 埋雷与排查CRM需求文档里最容易被评审揪出来的8个常见坑这一章写我踩过的和帮别人排查过的坑。每一条都是评审会上真实出现过的场景按“现象、原因、解决”三行拆开方便你对号入座。5.1 坑1线索、客户、联系人三个对象混成一张表单现象需求文档里线索和客户字段几乎一模一样开发建模时不知道哪个是主、哪个是副本线索转化后字段要不要迁移也说不清楚。原因需求阶段把“潜在对象”和“成交对象”当成同一个东西省掉了转化逻辑。尤其是小型团队总觉得“客户不就是线索加个状态位吗”结果后面做报表时全乱了。解决在文档里明确三个对象的差异。线索是“有成交可能的未知对象”客户是“已建立联系的基本盘”联系人挂在客户下。转化规则写一句线索转客户后线索联系人复制为第一联系人原线索状态变为已转化且不允许再编辑。开发拿到这句就能建表业务也不会再混着用。5.2 坑2重复客户排重规则没写手机为空场景现象测试导入1000条客户数据发现同一家企业被建了5条个人客户手机号为空时排重功能彻底失效。原因唯一性校验只写了“手机号唯一”没考虑企业客户没有手机号也没考虑个人联系人可以有多个手机号。排重键定义得太单一。解决分两类排重键企业客户按统一信用代码个人客户按手机号加姓名手机号为空时允许保存但列表页给出重复提醒。合并规则也必须写合并时保留主客户商机和合同全部迁移到主客户下被合并客户标记失效。排重触发时机分两个手工新建时实时提醒批量导入时先预检再入库。5.3 坑3状态机只画正向流程漏掉“回退”和“撤销”现象销售误把商机标成赢单系统不允许改回最后只能找管理员改数据库。这属于口头需求没写全。原因状态机图只画了创建到关闭的单向线没设计退回条件和权限。大家都默认“赢单了就不可能反悔”但现实是错点、客户变卦、合同重谈都是常态。解决每个状态加两列回退动作和回退权限。赢单可回退到报价输单可回退到原阶段但都必须有“撤销赢单”权限且记录操作日志。评审时直接拿这个场景问业务误操作找谁当场定下来开发就不用回头补。5.4 坑4权限矩阵只画按钮不画数据范围现象销售经理进了系统只能看到自己的客户看不到团队成员数据业务反馈“系统坏了”。原因权限只定义了“能点哪些按钮”没定义“能看到谁的数据”。开发和测试都按按钮级去实现数据隔离自然就是默认各自独立。解决把权限矩阵拆成两列一列功能权限一列数据范围。数据范围分四档本人、本人及下级、本部门、全部。并补充一句“负责人字段是OwnerOwner变更即数据范围变更”。这条写清楚后开发只需要在查询条件里拼Scope条件测试也敢写验证用例。5.5 坑5把“本期不做”写在需求列表里现象开发和业务对“有没有”产生了分歧文档里明明有某个字段业务坚持说“我以为这版本有”开发说“这行字在范围之外”。原因范围章节把不做的条目列在“暂不实现”里但后续版本维护时又把这一行复制到了功能清单边界越描越糊。解决做一个独立的“本版本不做”清单每条附原因和替代方案凡是出现在功能清单里的条目默认本期实现凡是出现在“不做”清单里的条目默认本期不设计。变更必须走变更记录评审会上口头说改不算。5.6 坑6状态值没有定义默认值现象商机新建时阶段为空测试和前端都不知道默认显示什么最后只能等开发拍脑袋。原因字段字典只写了类型和必填没写默认值。这是个很不起眼但影响面很大的遗漏。解决字段字典加一列“默认值”。商机阶段默认“跟进中”客户状态默认“潜在”跟进类型默认“电话”下次跟进时间默认空。这一列全表扫一遍能干掉后续一大批前端联调的琐碎bug。5.7 坑7字段字典里没写“是否可编辑”现象商机赢单后销售仍然可以用详情页直接改金额财务对账发现数字对不上追查数据变更记录又查不到。原因字段字典只回答了“这字段存什么”没回答“什么状态下这个字段能不能改”。所以开发默认所有字段都可编辑。解决在设计章节补一条级联规则赢单后商机金额、客户、阶段字段全部只读仅管理员可改。同理合同生效后金额只读回款已登记后合同作废需走审批。这类规则放在对象关系表和状态机表旁边开发建表时就能一起考虑。5.8 坑8没有定义导出权限现象销售花了一分钟导出了全公司客户列表数据安全评审才发现导出功能没人管。原因权限矩阵里漏了“导出”这一列因为导出不是对象操作是横切动作。对话框不长十个角色九个会漏。解决导出必须单独授权并且对导出字段做裁剪。销售只能导出本人客户的基础字段不允许导出手机号全量管理员导出要记录操作日志。导入也是同样的逻辑导入模板不能包含敏感字段。这一条写进权限矩阵数据安全这一关基本就过了。6. 一份评审自检清单用最小代价验证文档能不能落地文档写完不是终点评审过才算。我每次评审前会做三件事过一遍自检清单做一次端到端走查把变更口径写到文档里。这三件事加起来半天左右但能拦住会上80%的岔子。6.1 用一张表做交付自检检查项通过标准域边界每个业务域都写了纳入或裁剪的理由用例清单每个“角色×对象×动作”都有编号和优先级字段字典客户、联系人、商机有类型、必填、默认值、口径状态机每个对象有状态表且有回退路径权限矩阵功能权限和数据范围分开导出单独授权数据口径漏斗、回款等指标有SQL或公式不做清单与功能清单互斥每条有原因和替代方案6.2 端到端走查法拿一条真实业务场景从头走一遍找三个人产品、开发、测试用文档按一条场景走新线索进来转客户建联系人建商机推进阶段赢单生成合同草稿登记回款。每走一步都在文档里找依据对象关系表有没有、字段字典有没有、状态机有没有、权限矩阵有没有。找不到依据的地方就是文档缺口评审会之前补掉比在会上被问住强十倍。这个方法逼着文档从“模块齐全”变成“链路自洽”我把它当作标准动作执行。6.3 变更怎么记让评审结论成为文档的一部分评审会开的结论如果不落进文档等于白开。我的习惯是评审记录里每一条变更都映射到具体章节改了范围、改字段、改状态、改权限、改口径。散会后当天更新文档并把变更记录附在文档末尾下一轮评审直接看变更。我自己的收尾习惯是在评审前一天当一次刁钻用户专挑管理员的权限、回退、口径这些边角去问因为真正让项目翻车的永远是边角不是主干。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
