简介本资源是一份完整的CRM客户管理模块软件需求说明书PRD面向企业数字化转型中的产品经理、系统分析师及IT实施人员聚焦客户档案管理、交互历史追踪、销售漏斗分析等核心业务场景助力团队精准定义CRM系统功能边界与验收标准。文档由蜂网供应链管理上海有限公司于2017年8月正式发布编写人为周旭丽内容覆盖项目背景、竞品分析、名词解释、业务用例、功能列表及技术合规要求等54页完整结构具备强落地性与行业参考价值。资源为单文件PDF格式共1个文件大小3.11MB轻量易读适合作为需求分析范本、课程教学案例或CRM系统二次开发依据。目前已有312人学习下载读者可直接获取标准化PRD撰写框架、客户管理全链路业务流程图、角色权限用例说明及变更控制记录模板对提升需求文档专业度与跨部门协同效率具有实操指导意义。1. 这不是一份普通PRD它是一份能直接驱动CRM开发落地的客户管理功能蓝图你手头这份《客户关系管理CRM_客户管理_软件需求说明书_V1.0》表面看是2017年蜂网供应链内部发布的PDF文档但实际价值远超“历史资料”——它是一份完整闭环、颗粒度极细、可直接映射到数据库字段与前端交互逻辑的客户模块PRD。我去年帮某高校实验室重构一套教学用CRM系统时就拿它当骨架复刻54页里光是“客户列表界面”就拆出17个子场景从默认排序规则、字段必选约束到鼠标悬停编辑触发逻辑连“点击网址跳转是否新窗口”这种细节都白纸黑字写进交互说明。它不讲抽象理念只解决具体问题比如“如何防止上下级客户互为父子”“查重时用手机号还是统一社会信用代码”“负责人变更后原负责人是否还能查看历史动态”。适合三类人正在从零搭建CRM的中小团队产品经理、需要快速理解客户模块设计边界的后端工程师、以及想拿真实工业级PRD练手的应届生。它不教你什么是CRM它告诉你——一个能上线、能过UAT、能被销售天天骂但又离不开的客户管理模块到底长什么样。2. 从PRD到可运行系统客户管理模块的三层落地路径2.1 为什么这份PRD能跳过“需求翻译失真”陷阱多数PRD失败不是因为写得不够全而是业务语言和工程语言之间存在断层。这份文档的杀手锏在于它把每个字段都绑定了四重约束——类型字符/枚举/参照、取值范围如“客户级别从数据字典中选择已启用”、空值规则“非空可编辑”、来源“手工输入/系统自动”。以“工商注册”字段为例类型是布尔值来源标注“系统判定”合法性说明“非空不可编辑”。这意味着开发时必须写一个校验逻辑比如调用天眼查API或匹配企业信用代码正则且该字段在UI上必须禁用输入框。这种写法直接堵死了“开发凭经验填默认值”“测试漏掉空值场景”的漏洞。我见过太多项目卡在“客户级别下拉框为啥没数据”——而这里明确写了“从数据字典中选择已启用”倒逼你在建表时必须设计dict_typecustomer_level AND statusenabled的查询条件。它用最笨的办法把模糊地带全部钉死。2.2 客户列表页54页文档里最值得抄作业的交互范本客户列表页是CRM的门面也是用户使用频率最高的页面。这份PRD用整整3页P10-P12定义了它的行为边界我们直接拆解成可执行代码# 模拟客户列表默认查询逻辑对应P11列表默认创建时间倒叙 def get_default_customer_list(org_id: str) - List[Dict]: 返回当前组织下所有客户按创建时间倒序排列 注意此处org_id需从当前登录用户上下文获取而非前端传参防越权 return db.query(SELECT * FROM customer WHERE org_id %s ORDER BY created_at DESC, org_id) # 模拟鼠标悬停编辑字段逻辑对应P10第7条 def handle_field_edit(customer_id: str, field_name: str, new_value: str): 字段级编辑仅允许编辑特定字段且需校验合法性 例如编辑电话字段时需通过手机号正则校验 if field_name phone: if not re.match(r^1[3-9]\d{9}$, new_value): raise ValueError(电话格式不正确) elif field_name customer_name: if len(new_value) 200: raise ValueError(客户名称不能超过200字符) # 更新单个字段不触发整行重排对应P10第7条不重新排序 db.execute(fUPDATE customer SET {field_name} %s WHERE id %s, new_value, customer_id)提示这段代码的关键不在语法而在注释里强调的约束点。比如org_id必须从用户会话中提取这是PRD里没明说但隐含在“所属组织我所在组织”中的安全要求再比如“不重新排序”意味着前端不能用v-for重渲染整个列表而要用$set更新单个对象属性——否则用户正在看第10页编辑完第1行后页面会自动跳回第1页这就是血泪经验。2.3 高级查询方案预置规则背后的业务意图解码PRD在P13列出了5个预置查询方案表面是筛选条件实则是销售管理动作的数字化映射查询方案对应业务动作技术实现要点PRD原文依据全部客户组织级数据总览WHERE org_id current_user.org_idP13第1条我负责的客户个人业绩归因WHERE owner_id current_user.idP13第2条我参与的客户跨角色协作追踪WHERE id IN (SELECT customer_id FROM team_member WHERE user_id current_user.id) AND owner_id ! current_user.idP13第3条七日未跟进客户销售过程预警WHERE last_activity_time NOW() - INTERVAL 7 daysP13第5条注意第3条“我参与的客户”PRD特别强调“团队成员包含我且负责人不等于我的客户”。这说明系统支持多人协作跟进同一客户但要区分主责人和协作者。技术上必须建一张team_member关联表且owner_id和team_member.user_id不能指向同一人——否则会出现逻辑悖论。很多团队在做类似功能时只建了customer.owner_id结果销售总监给自己加了个“协作者”身份系统就崩了。这份PRD用一句“且负责人不等于我”提前踩住了这个坑。2.4 客户层级关系从树形结构到防环检测的硬核实现P44的“客户层级关系”示意图看似简单但背后藏着数据库设计的生死线。PRD要求“不允许互为上下级”即A是B的上级B就不能是A的上级。这本质是有向无环图DAG的环路检测问题。常见错误做法是只在新增时校验父节点结果A→B→C→A形成环却没被发现。正确解法是用路径压缩算法-- PostgreSQL示例插入前检查是否成环 WITH RECURSIVE hierarchy AS ( SELECT id, parent_id, ARRAY[id] AS path FROM customer WHERE id :new_parent_id -- 新客户的父节点ID UNION ALL SELECT c.id, c.parent_id, h.path || c.id FROM customer c INNER JOIN hierarchy h ON c.id h.parent_id WHERE NOT c.id ANY(h.path) -- 防止环路 ) SELECT COUNT(*) 0 AS has_cycle FROM hierarchy WHERE :new_customer_id ANY(path);注意这个SQL必须在事务内执行且parent_id字段需建索引。PRD没提性能但生产环境里如果每次保存都跑一次递归查询10万客户时响应会卡顿。我一般会加一层缓存用Redis存储每个客户的祖先ID集合如ancestors:123 [456,789]新增时只查缓存单次DB查询把O(n)降到O(1)。3. 避坑指南这份PRD里埋着的5个隐形雷区3.1 现象高级查询条件里“团队成员”字段无法筛选原因PRD在P13只写了“高级查询条件客户表字段包含自定义字段”但没说明“团队成员”是多对多关系其数据不在customer表里而在team_member关联表中。开发按字面意思只查customer表字段自然查不到。解决必须在高级查询引擎中增加关联表支持。例如用Elasticsearch时需将team_member.user_id作为nested类型嵌入客户文档用SQL时需动态拼接LEFT JOIN team_member ON customer.id team_member.customer_id。3.2 现象客户导出Excel时“最新活动记录时间”字段为空原因PRD在P12定义该字段为“最后活动记录保存时系统时间”但没说明“活动记录”属于独立模块如activity表且一个客户可能有0条活动记录。开发直接写SELECT ... FROM customer LEFT JOIN activity ON ...当activity为空时last_activity_time自然为NULL。解决必须用子查询或窗口函数获取每个客户的最新活动时间。例如SELECT c.*, (SELECT MAX(a.created_at) FROM activity a WHERE a.customer_id c.id) AS last_activity_time FROM customer c;3.3 现象“更改负责人”批量操作后原负责人收不到通知原因PRD在P11按钮说明里只写了“更改负责人参照选人”但没提通知机制。开发以为只是改个字段忽略了销售流程中负责人变更需同步触发消息提醒邮件/站内信。解决在负责人更新事务中强制加入通知逻辑。例如用Celery异步发送app.task def send_owner_change_notice(old_owner_id, new_owner_id, customer_id): # 发送通知给old_owner_id告知已移交 # 发送通知给new_owner_id告知已接手 # 记录操作日志3.4 现象客户导入模板里“行业”字段下拉选项和系统不一致原因PRD在P11写“行业从数据字典中选择已启用的行业数据”但没提供字典导出接口。测试人员按自己理解建了10个行业而生产环境字典有50个且部分已禁用。解决必须在导入模板生成环节动态拉取当前环境启用的行业列表并生成带校验的Excel用Excel数据验证功能限制下拉值。同时导入接口需做二次校验def validate_import_data(rows: List[Dict]): valid_industries set(db.query(SELECT code FROM dict WHERE typeindustry AND statusenabled)) for row in rows: if row[industry] not in valid_industries: raise ValidationError(f行业{row[industry]}不在有效字典中)3.5 现象客户合并后“工商注册”字段状态错乱原因PRD在P12定义“工商注册”为布尔值且“非空不可编辑”但合并操作涉及两个客户的数据整合。开发按简单覆盖逻辑如用新客户值覆盖旧客户导致A客户工商注册为True、B为False时合并后状态丢失。解决合并策略必须按字段类型定制。对布尔字段采用“OR”逻辑只要任一客户为True即为True对字符串字段用非空优先取第一个非空值对时间字段取最大值。PRD虽未明说但这是客户数据治理的基本原则。4. 权限与状态机PRD里最易被忽略的两套底层引擎4.1 “负责人”字段的权限穿透设计PRD在P11多次出现“负责人”字段列表页、编辑页、详情页但没单独写权限章节。实际上它通过字段级控制实现了精细权限列表页“负责人”列可显示但仅当用户有view_all_customers权限才显示全部否则只显示“我负责的客户”P13第2条编辑页只有当前负责人或管理员才能修改“负责人”字段P11“负责人参照选人非空可编辑”隐含此意详情页P29“客户详情-成交状态”旁注明“仅负责人可见”说明字段级权限已细化到按钮这种设计避免了传统RBAC的粗放式授权。实现时需在ORM层注入权限钩子# SQLAlchemy示例动态过滤客户列表 def get_customers_by_permission(user: User, query_params: dict): base_query Customer.query if not user.has_permission(view_all_customers): # 普通销售只能看自己负责的客户 base_query base_query.filter(Customer.owner_id user.id) if query_params.get(my_participated): # “我参与的客户”需额外JOIN base_query base_query.join(TeamMember).filter( TeamMember.user_id user.id, TeamMember.customer_id Customer.id, Customer.owner_id ! user.id ) return base_query.all()4.2 成交状态的状态转换图从静态枚举到动态流程PRD在P29定义“成交状态”为枚举值未成交/已成交但在P49的“状态转换图”中它其实是销售漏斗的具象化。关键点在于“未成交”可转为“已成交”但“已成交”不可逆防误操作转换需触发关联动作如转为“已成交”时自动生成合同编号、冻结客户信息编辑权限PRD虽未画出完整状态图但P50“审批流”提到“成交需主管审批”说明状态变更需走工作流我们用有限状态机FSM实现from transitions import Machine class CustomerStateMachine: states [unqualified, contacted, negotiating, won, lost] transitions [ {trigger: qualify, source: unqualified, dest: contacted}, {trigger: negotiate, source: contacted, dest: negotiating}, {trigger: win, source: negotiating, dest: won, conditions: is_approved}, {trigger: lose, source: negotiating, dest: lost}, ] def __init__(self, customer): self.customer customer self.machine Machine(modelself, statesself.states, transitionsself.transitions, initialcustomer.status) def is_approved(self): # 调用审批服务检查当前客户成交申请是否通过 return approval_service.check(customer_idself.customer.id, actionwin)注意PRD里“成交状态”只写了两个值但状态机必须预留扩展位。比如未来加“已签约”“已回款”状态只需增补transitions不用改数据库。这才是工业级PRD的隐藏价值——它用最简枚举描述核心状态但为演进留足空间。4.3 查重设置的双重校验前端防抖 后端原子锁PRD在P51要求“查重设置”但没说明查重时机。实际落地时必须分两层前端在客户名称输入框加防抖debounce 300ms实时调用/api/customers/check-duplicate?namexxx返回重复客户列表供用户确认后端保存时用数据库唯一约束应用层锁防并发插入。例如PostgreSQL-- 建唯一索引按业务规则组合 CREATE UNIQUE INDEX idx_customer_duplicate ON customer (org_id, UPPER(TRIM(phone)), UPPER(TRIM(email))); -- 插入时捕获唯一约束异常 INSERT INTO customer (...) VALUES (...) ON CONFLICT ON CONSTRAINT idx_customer_duplicate DO NOTHING;很多团队只做前端校验结果高并发时插入两条相同客户。PRD的“查重设置”四个字背后是前后端协同的完整链路。5. 从PRD到交付物如何用这份文档反向驱动开发验收5.1 功能点映射表把54页文档变成可执行的ChecklistPRD的P8功能列表只写了“客户菜单P1”太粗。我们按P9-P47的详细描述拆成开发验收的原子项。以下为“客户新增”功能的验收清单节选序号PRD位置验收项测试用例通过标准1P18图新增界面必填字段标红输入空客户名称点击保存提示“客户名称不能为空”焦点停留在该字段2P11第5条列表字段可自定义在列表页点击“列设置”取消勾选“电话”表格中不再显示电话列且导出Excel也不含该列3P23客户名称长度限制输入201个字符的客户名称前端实时截断为200字符或提交时返回400错误4P11第6条客户名称模糊搜索列表有客户“A公司”“B公司”搜索“A”只显示“A公司”且名称高亮显示“A”5P26图客户详情页显示“最新活动记录时间”为客户创建一条活动记录后进入详情页该字段显示活动创建时间且随新活动自动更新这张表直接交给测试同学比写100页测试用例更高效。PRD里每张界面示意图、每条按钮说明都是现成的验收依据。5.2 数据字典自动生成从PRD表格到数据库SchemaPRD的P11-P12“客户列表-默认关键数据项”表格本质就是数据字典原型。我们可以用Python脚本自动解析PDF用pdfplumber库提取字段名、类型、约束生成建表SQL# 伪代码从PRD表格生成SQL def generate_ddl_from_prd_table(prd_table: List[Dict]) - str: ddl CREATE TABLE customer (\n for field in prd_table: col_type { 字符: VARCHAR(200), 枚举: VARCHAR(50), # 枚举值在字典表中维护 参照: BIGINT REFERENCES dict(id), # 如行业、客户级别 日期时间: TIMESTAMP WITH TIME ZONE, 布尔: BOOLEAN DEFAULT FALSE }[field[类型]] ddl f {field[数据项名称]} {col_type} if field[是否可空] 非空: ddl NOT NULL if field[来源] 系统自动: ddl DEFAULT NOW() ddl ,\n ddl PRIMARY KEY (id)\n); return ddl # 输出结果示例节选 # CREATE TABLE customer ( # customer_name VARCHAR(200) NOT NULL, # industry VARCHAR(50), # phone VARCHAR(20), # created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW(), # ... # );这样生成的SQL字段名、长度、空值约束全部对齐PRD杜绝“开发自己定长度”的混乱。我一般会把脚本和PRD PDF放在同一个Git仓库每次PRD更新就重跑脚本保证代码和文档永远一致。5.3 边界案例测试集PRD里藏着的5个魔鬼细节PRD的严谨性体现在对边界场景的穷举。我们从中提炼出必须覆盖的测试集上下级客户互为父子P11尝试将客户A设为B的上级再将B设为A的上级 → 必须拦截并报错负责人变更时的动态可见性P29A将客户移交给B后A再发一条动态 → B能看到A不能看到除非是公开动态合并客户时的联系人去重P30客户A有联系人a1.com客户B也有a1.com → 合并后只保留一个联系人导入模板空值处理P46Excel中“电话”列为空但PRD要求“可空” → 导入后数据库该字段为NULL非空字符串高级查询的跨表关联P13查“团队成员包含张三的客户”但张三已离职statusinactive→ 不应返回任何客户这些案例在PRD里都是零散的一句话但组合起来就是一套完整的质量防线。从那以后我每次启动新CRM项目第一件事就是把PRD里所有带“不允许”“必须”“默认”“仅”的句子摘出来做成测试用例库。希望帮到你。本文还有配套的精品资源点击获取