简介：这份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 客户主档的字段清单怎么定

客户列表的默认关键数据项是整份文档最扎实的部分，直接给出了字段、类型、取值范围、是否可空、可编辑性和来源。摘几个关键项：

这张表的价值在于它把「谁填、能不能空、能不能改、从哪来」四件事一次说清。写毕设文档时照这个粒度列字段，答辩老师问「这个字段为什么不可编辑」你能答上来，因为它是系统判定而非人工录入。

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_id=user.org_id) & ( Q(owner_id=user.id) | Q(team_members__user_id=user.id) | Q(dept_id__in=user.managed_dept_ids) ) # 商家：仅本组织 return Q(org_id=user.org_id)

这段过滤要作为所有列表、导出、高级查询的公共入口，不能每个接口各写一遍。我见过有项目列表做了权限、导出忘了做，结果一次导出把全公司客户拉走了，这就是血泪经验。

4. 关键功能实现：新增查重、合并、导入导出与动态

4.1 新增与查重规则

文档在设置部分专门留了「客户创建规则」和「查重设置」两节，说明查重是产品化的配置项而非写死逻辑。常见做法是允许配置查重字段组合，比如「客户名称+电话」或「客户名称+省市区」，命中时给出三种策略：禁止保存、提示但允许继续、自动合并到已有客户。

def check_duplicate(payload, rule): # rule.fields 形如 ['name', 'phone'] cond = Q(is_deleted=0) 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管用。

从那以后我每次写客户类模块的PRD，都强制先出这张字段级验收清单再动笔写正文，因为写清单的过程就是把模糊需求逼成明确规则的过程，很多坑在写文档阶段就暴露了。希望帮到你。

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