CRM客户管理模块PRD设计：字段级需求与实现避坑指南

简介这份PDF是面向产品经理、需求分析师与CRM系统开发团队的客户管理软件需求说明书围绕企业如何通过信息化手段优化销售、营销与服务流程、提升客户满意度展开可作为需求梳理、系统设计与项目验收的参考蓝本。资源包共1个PDF文件约3.11MB正文约54页结构完整依次覆盖项目介绍、需求来源与项目背景、项目目标与目标顾客、平台政策与竞品分析以及方案概述、名词解释、业务流程、系统用例、角色用例、功能列表与基本流程等章节并附变更记录便于追踪版本演化。文档对客户档案、交互历史、销售漏斗等核心概念及客户信息录入、联系人跟踪、销售预测、市场营销自动化、客户服务与报表分析等模块均有描述同时涉及数据集成、移动支持、安全合规与培训支持等非功能要求。目前已有316人学习适合需要撰写PRD或搭建CRM原型时对照参考。1. 客户管理模块的PRD到底该写多细接手一个CRM客户管理模块的需求文档最常见的翻车不是功能漏了而是写到开发手里全是问号客户列表默认按什么排序、上级客户能不能选自己、删除是软删还是硬删、负责人变更后团队成员跟不跟着走。这份《客户关系管理CRM-客户管理-软件需求说明书V1.0》给了一个很务实的答案——把客户当成一个数据中心来写而不是当成一张表单来写。它围绕客户主档把联系人、商机、动态、合同、订单、团队成员全部挂上去用一份54页的文档把列表、新增、编辑、详情、合并、导入导出、查重、权限逐项落到字段级。适合正在做CRM毕设或课程设计的学生直接套结构也适合要交付客户管理模块方案的从业者拿来改。下面按需求、设计、实现、避坑、验收的顺序拆开讲。2. 需求与范围界定客户主档为什么是整套CRM的地基2.1 从业务目标反推功能边界这份文档的项目目标写得很克制只有两条客户资料管理以及客户销售活动、计划安排、联系人、商机的管理。线索获取分配、统计分析、销售漏斗明确划到二期。这个取舍值得学——很多毕设方案一上来就把线索、漏斗、报表全塞进V1.0结果每个模块都只有壳子。我一般会建议按优先级P1/P2/P3切P1是客户主档的增删改查加查重和权限P2是联系人、商机、动态的关联P3才是统计和漏斗。文档里的功能总表也是这个思路客户菜单标P1其余按开发资源顺延。目标顾客写了两类内部销售人员以及入驻平台的商家。这两类角色的权限模型完全不同内部按部门和组织隔离商家只能看自己的客户。这一点在写需求时必须提前定死否则后面做数据权限会返工。2.2 客户主档的字段清单怎么定客户列表的默认关键数据项是整份文档最扎实的部分直接给出了字段、类型、取值范围、是否可空、可编辑性和来源。摘几个关键项数据项类型规则来源客户名称字符非空不超过200字符手工输入上级客户参照参照CRM客户不允许互为上下级手工输入行业枚举数据字典中已启用的行业手工输入业务类型枚举可多选手工输入工商注册布尔系统判定非空不可编辑系统自动负责人参照参照选人非空手工输入所属部门参照默认当前用户所在部门手工输入所属组织参照默认当前操作员所属组织不可编辑系统自动成交状态枚举未成交/已成交默认未成交手工输入最新活动记录时间日期时间最后活动记录保存时写入系统自动这张表的价值在于它把「谁填、能不能空、能不能改、从哪来」四件事一次说清。写毕设文档时照这个粒度列字段答辩老师问「这个字段为什么不可编辑」你能答上来因为它是系统判定而非人工录入。2.3 查询方案与高级查询的设计列表预置了五个查询方案全部客户所属组织我所在组织、我负责的客户负责人我、我参与的客户团队成员包含我且负责人不是我、我关注的客户、七日未跟进客户未跟进天数7。这五个方案基本覆盖了销售日常的查看习惯而且每个都能翻译成一条明确的过滤条件开发不用猜。高级查询则要求覆盖客户表字段含自定义字段并额外支持团队成员、是否关注等关联条件。这里有个设计点自定义字段意味着查询条件是动态的后端不能写死SQL通常的做法是把字段元数据存一张表查询时拼装条件并做白名单校验防止注入。提示查询方案不要做成前端写死的五个按钮做成配置表后续加「本月新增客户」「即将流失客户」不用改代码。3. 总体设计列表、详情、关联三层结构与数据模型3.1 页面结构怎么分层客户模块的页面结构可以拆成三层列表层负责检索和批量操作详情层负责单客户的完整视图关联层负责联系人、商机、动态、合同、订单、团队成员的挂载。文档里客户详情页明确写了「可新建和查看跟客户有关的联系人、商机、动态、合同、订单、团队成员信息」这就是关联层的职责。列表层的交互细节文档写得很细点客户名称进详情点网址跳外链默认按创建时间倒序默认加载「全部客户」方案显示列可自定义但客户名称必选客户名称搜索对全部可见数据模糊匹配鼠标悬停字段出现编辑按钮、失焦保存。这些细节看着琐碎但每一条都是开发和测试的验收点。3.2 实体关系与关键约束客户主档的实体关系大致是客户1—N联系人客户1—N商机客户1—N动态客户1—N合同客户1—N订单客户N—N团队成员带角色客户自关联形成上下级层级。约束里最容易被忽略的是「上下级不允许互为上下级」这本质是防环。实现上要么在保存时做一次祖先链遍历要么用路径字段如/1/5/12/判断新父节点是否在当前节点的子树里。-- 客户主表核心字段简化 CREATE TABLE crm_customer ( id BIGINT PRIMARY KEY, name VARCHAR(200) NOT NULL, parent_id BIGINT NULL, -- 上级客户自关联 path VARCHAR(500) NOT NULL, -- 层级路径如 /1/5/12/用于防环和子树查询 industry VARCHAR(64) NULL, employee_num VARCHAR(32) NULL, phone VARCHAR(32) NULL, province_id BIGINT NULL, city_id BIGINT NULL, district_id BIGINT NULL, address VARCHAR(255) NULL, biz_type VARCHAR(255) NULL, -- 多选逗号分隔或关联表 level VARCHAR(32) NULL, reg_status TINYINT NOT NULL DEFAULT 0, -- 工商注册系统判定 deal_status TINYINT NOT NULL DEFAULT 0, -- 0未成交 1已成交 owner_id BIGINT NOT NULL, dept_id BIGINT NOT NULL, org_id BIGINT NOT NULL, last_active_at DATETIME NULL, created_by BIGINT NOT NULL, created_at DATETIME NOT NULL, updated_by BIGINT NULL, updated_at DATETIME NULL, is_deleted TINYINT NOT NULL DEFAULT 0 );path字段是关键设计新增时取父节点path拼上自身id修改上级时先校验新父节点path是否以当前节点path为前缀是则拒绝防环一步到位。子树查询也变成path LIKE /1/5/%比递归查询省事。is_deleted做软删因为客户下面挂着合同订单硬删会留下孤儿数据。3.3 权限模型组织、部门、负责人、团队四层权限是客户模块最容易翻车的地方。文档里所属组织默认当前操作员组织且不可编辑所属部门默认当前用户部门可编辑负责人参照选人团队成员单独维护。这四层叠加起来可见性规则通常是同组织内负责人本人、团队成员、以及有部门数据权限的管理者可见。商家角色则限定org_id为自己的组织。def visible_scope(user): # 内部销售本组织 本人负责 本人参与 部门管理范围 if user.role internal: return Q(org_iduser.org_id) ( Q(owner_iduser.id) | Q(team_members__user_iduser.id) | Q(dept_id__inuser.managed_dept_ids) ) # 商家仅本组织 return Q(org_iduser.org_id)这段过滤要作为所有列表、导出、高级查询的公共入口不能每个接口各写一遍。我见过有项目列表做了权限、导出忘了做结果一次导出把全公司客户拉走了这就是血泪经验。4. 关键功能实现新增查重、合并、导入导出与动态4.1 新增与查重规则文档在设置部分专门留了「客户创建规则」和「查重设置」两节说明查重是产品化的配置项而非写死逻辑。常见做法是允许配置查重字段组合比如「客户名称电话」或「客户名称省市区」命中时给出三种策略禁止保存、提示但允许继续、自动合并到已有客户。def check_duplicate(payload, rule): # rule.fields 形如 [name, phone] cond Q(is_deleted0) for f in rule.fields: cond Q(**{f: payload.get(f)}) exists Customer.objects.filter(cond).first() if not exists: return None if rule.strategy block: raise BizError(客户已存在禁止重复创建) if rule.strategy warn: return {level: warn, customer_id: exists.id} return {level: merge, customer_id: exists.id}查重放在保存前而不是数据库唯一索引是因为规则可配置、且允许「提示但继续」。如果直接上唯一索引业务上想放行都放行不了。查重字段要做空值处理电话为空的记录不参与电话维度比对否则两个都没填电话的客户会被误判重复。4.2 客户合并的处理顺序合并是文档里单独列出的功能也是数据一致性要求最高的操作。合并的逻辑顺序建议固定为先迁关联联系人、商机、动态、合同、订单、团队成员去重后挂到主客户再合并字段空值用被合并方补冲突以主客户为准最后软删被合并客户并记录合并日志。团队成员去重按user_id重复的保留角色高的那个。合同订单迁移前要校验状态已完成的订单迁过去不影响进行中的要提示确认。注意合并不可逆操作前必须二次确认并展示将被迁移的关联数据条数这是给用户的后悔药。4.3 导入导出的工程细节导入按模板批量导入导出把当前页面数据写Excel。这两个功能看着简单坑最多。导入要做三件事模板校验列头必须匹配、逐行校验必填、枚举值、参照是否存在、错误行回写第几行第几列什么错。不要一行错就整批失败收集完错误一次性返回。导出要复用列表的查询条件和权限过滤字段顺序跟列表显示列一致大数据量走异步任务生成文件再下载。// 导入结果回写结构示例 { total: 500, success: 487, failed: 13, errors: [ { row: 12, column: 客户名称, message: 不能为空 }, { row: 45, column: 行业, message: 枚举值不存在新能源2 } ] }4.4 动态与最新活动时间客户详情里的动态页记录与客户的接触行为电话、上门、邮件等。每保存一条动态要同步更新客户的last_active_at因为「七日未跟进客户」查询方案依赖这个字段。更新用数据库时间而不是应用服务器时间避免多节点时钟不一致。动态本身建议只增不改需要更正就再发一条说明保证回溯可信。5. 避坑与排查客户模块最容易翻车的五个点5.1 删除后关联数据变孤儿现象是客户删了商机列表还能查到挂在这个客户下的记录点进去报错。原因是硬删或软删时没处理关联。解决是统一软删删除时级联标记关联数据或在查询时统一过滤is_deleted并在删除确认弹窗里列出关联数据条数让用户知情。5.2 更改负责人后团队成员没跟着走现象是负责人换了原负责人还在团队成员里新负责人看不到客户。原因是负责人和团队成员是两套数据。解决是更改负责人时给新负责人自动加一条团队成员记录角色为负责人原负责人是否移除按配置决定通常保留为普通成员以便交接。5.3 高级查询自定义字段报错现象是用户选了一个自定义字段做条件接口500。原因是后端把字段名直接拼进SQL。解决是维护字段元数据白名单只允许白名单内的字段参与查询类型不匹配时做转换而不是直接拼。5.4 列表编辑失焦保存覆盖他人修改现象是两个人同时编辑同一客户的不同字段后保存的把先保存的覆盖了。原因是整行更新。解决是字段级更新只提交变更的字段并带版本号或更新时间做乐观锁冲突时提示刷新。5.5 导出数据超出权限范围现象是普通销售导出了全组织客户。原因是导出接口没复用列表的权限过滤。解决是把权限过滤抽成公共方法列表、导出、高级查询、统计全部走同一个入口代码评审时重点看这个入口有没有被绕过。6. 验收与答辩用字段级清单把需求文档讲成可交付方案验收这份客户管理方案我习惯用一张「字段级验收清单」逐项过而不是笼统地说功能做完了。清单分四列功能点、验收操作、预期结果、对应文档章节。比如客户列表这一项验收操作是「用销售账号登录不选任何方案直接进列表」预期结果是「默认加载全部客户、按创建时间倒序、客户名称列存在且不可取消」。再比如查重验收操作是「用已存在的客户名称电话新增」预期结果是「按配置策略拦截或提示」。这张表既是测试用例也是答辩时的讲解提纲——老师问哪个功能你直接翻到对应行说清规则来源和边界条件。答辩时最容易被追问的是权限和合并。权限要能画出「组织—部门—负责人—团队」四层可见性关系并说明导出为什么不会越权合并要能说清迁移顺序和不可逆的确认机制。建议提前准备两个演示账号一个内部销售一个商家现场切换展示数据隔离比讲十页PPT管用。验收项操作预期列表默认排序进入客户列表创建时间倒序查询方案切换五个预置方案结果符合方案定义上级客户防环把A设为B的上级再把B设为A的上级第二次保存被拒绝查重策略按配置字段重复新增按block/warn/merge表现合并合并两个有关联数据的客户关联迁移、被合并方软删、有日志导入错误回写导入含错误行的文件返回行号列号及原因导出权限销售账号导出仅含可见数据从那以后我每次写客户类模块的PRD都强制先出这张字段级验收清单再动笔写正文因为写清单的过程就是把模糊需求逼成明确规则的过程很多坑在写文档阶段就暴露了。希望帮到你。本文还有配套的精品资源点击获取