企业官网建设流程全解析

简介：面向产品经理、需求分析师及CRM系统开发测试人员的《客户关系管理CRM-客户管理-PRD》需求文档，由蜂网供应链管理（上海）有限公司于2017年发布，全文54页，系统定义了客户管理模块的需求蓝图。文档从项目背景、平台政策、竞品分析出发，依次给出方案概述、名词解释、业务流程、系统用例与功能列表，覆盖客户信息录入与管理、联系人跟踪、销售漏斗、销售预测、营销自动化及客户服务等核心功能，并对数据集成、移动端支持、系统稳定性、安全性等非功能需求提出明确要求。适合作为企业构建或优化CRM客户管理模块的需求参考，也可用于学习PRD文档的规范写法。资源为单个PDF文件，大小3.11MB，内容为正式发布版软件需求说明书，已有314人学习下载。对要落地CRM项目或编写同类需求文档的读者而言，这份材料提供了完整结构、术语定义及功能拆分思路，可直接借鉴其章节组织与需求描述粒度。

1. 客户管理PRD拆解：CRM项目从何入手

做 CRM 项目最怕的不是技术选型，而是产品经理丢过来一份 54 页的软件需求说明书，让你在两周内把客户管理模块的列表、详情、团队成员、导入导出、查重全做出来。这份《客户关系管理CRM-客户管理-PRD-V1.0-20170825.pdf》就是典型的企业内部 PRD 实物，它把客户从「新建」到「成交状态」再到「团队成员协同」的完整链路写清楚了，甚至细到「鼠标移到某字段上出现编辑按钮，失去焦点保存」这种交互级别。对正在做企业内部系统、尤其是供应链或 To B 业务平台的产品、前端、后端开发者来说，它是一份可以直接照抄字段设计、查询方案和权限边界的参考底稿。文章后面我会按功能模块拆开讲，并标记几个真正容易翻车的细节。

2. 客户管理模块的底层模型：从业务背景到实体字段设计

2.1 项目背景：为什么 CRM 一期只做客户资料和活动管理

这份 PRD 的项目背景写得直白：企业面对的不只是产品质量竞争，还要搞清楚客户要什么、购买动机在哪，才能巩固老客户、开发新客户。它把 CRM 定义成「以客户为中心，对客户信息、营销、销售、服务数据分析，找到价值客户，制定中长期营销方案」的工具。这个定位直接决定了需求范围。

一期目标两个：一是客户资料管理，给销售、服务、营销人员一个快速的查询入口；二是对客户销售活动、计划安排、联系人、商机的管理，记录销售过程中的行为、计划，实现计划提醒。二期才做通讯信息自动读取、线索获取分配、统计分析和销售漏斗。这个分期方式值得参考，它避免了「一上来就要做 BI 报表和销售漏斗」这种典型超范围问题，先把数据录进去、把客户档案建起来，后面分析才有基础。

另外文档里有一句容易被忽略的话：目标顾客是销售人员和入驻商家。也就是说这个 CRM 不是纯内部系统，商家也有使用入口，所以客户创建规则、查重设置、团队成员权限都要考虑外部账号的数据隔离。这一点在后面的权限和查询方案里会反复出现，也是我建议你在做类似系统时最先确认的边界。

2.2 客户关键数据项：字段类型、来源与可编辑规则

客户列表的默认关键数据项是这份 PRD 最有复用价值的部分。它把每个字段的类型、含义、来源、是否可空、可编辑性都列出来了。我把核心字段整理成表格，方便对照着建数据库表或设计表单。

这里面有几个字段值得单独说。

「工商注册」被设计成布尔值，而且是系统判定、不可编辑。常见做法是接入工商数据源，根据客户名称或统一社会信用代码自动校验企业是否注册。如果你没有工商接口，这个字段建议做成「待人工确认」的三态，而不是纯布尔，否则会有大量假数据。

「所属组织」默认当前操作员所属组织且不可编辑，这意味着新建客户时，组织归属是强制按登录人走的，不能手选。如果你在一个多法人或多组织的集团体系里，这个规则能避免销售把客户挂到错误组织下，但也意味着组织调整只能走后台管理员，操作入口必须在权限设计里单独预留，否则销售跨组织转客户会非常痛苦。

「上级客户」不允许互为上下级，这个要在保存时做双向校验。很多人只校验了当前客户的上级不为空就通过，结果 A 的上级是 B，B 的上级又改成 A，形成循环引用，列表页展开层级时直接死循环或报栈溢出。后面避坑章我会细说。

「业务类型」是多选枚举，而「行业」是单选枚举。这两个字段在设计数据字典时要区分好，行业树可以两级，业务类型做成多选标签即可，别把多选项塞进单选控件里。

2.3 角色用例与数据权限：谁看得到谁的客户

PRD 里角色用例部分没有给出完整表格，但从查询方案能反推数据权限模型：

• 全部客户：客户所属组织 = 我所在组织
• 我负责的客户：客户负责人 = 我本人
• 我参与的客户：团队成员包含我且负责人不等于我
• 我关注的客户：我已加关注客户
• 七日未跟进客户：未跟进天数 > 7 天

这五个预置查询方案实际定义了五类数据可见性。组织维度的「全部客户」意味着同级部门之间可以互相看到客户列表，这在销售团队内部是常见设计——不是私有客户池，而是「组织内可见、负责人负责跟进」。但如果你的业务要求销售数据完全隔离，「全部客户」这条就要改成「可见我创建 + 我负责 + 我参与的客户」，否则销售会投诉客户被抢。

「七日未跟进客户」的实现依赖「最新活动记录时间」字段。这个字段由系统在活动记录保存时自动写入，不开放手工编辑。这里有个隐藏要求：客户跟进活动（电话、上门、邮件）必须统一走动态模块记录，如果销售习惯线下跟进、不上系统，这个查询方案就是空跑。我在实际项目中见过不止一次这种情况，所以如果要在你的系统里复刻这个查询，最好在客户详情页把「写动态」做成强提醒，甚至强制要求录入跟进结果才能关闭待办。

3. 客户列表的交互规则：查询方案、高级查询与批量操作

3.1 列表默认排序与预置查询方案的映射

列表页交互说明里有一条非常具体：点击客户名称进入详情页；点击网址链接到对应网站；列表默认按创建时间倒序；列表数据默认为查询方案的「全部客户」；显示列可自定义，且客户名称为必选字段。

按创建时间倒序是个容易忽略的坑。如果客户量大，创建时间相同的情况很常见，尤其是批量导入时，一批客户可能共享同一个导入时间戳。如果只有创建时间一个排序字段，分页会出现数据重复或丢失。我一般会设计成「创建时间倒序 + id 倒序」的复合排序，保证排序稳定性。

查询方案「全部客户」的映射是客户所属组织 = 我所在组织，而不是「所有客户」。这意味着一个销售登录后看到的客户列表是组织级的，不是全公司级的。如果产品经理跟你说「列表默认全部客户」，你要先确认这个「全部」到底是全公司、全组织、还是当前操作员可见范围内全部。一字之差，SQL 就差一个组织条件。

网址字段点击跳转实现不难，但要校验协议头。如果客户只填了「www.example.com」而没加「http://」，前端直接 window.open 会被浏览器拦截或报错。常见做法是在保存时自动补全协议前缀，或者在渲染时拼接。

3.2 高级查询：查询条件边界与团队成员筛选

高级查询部分，PRD 只给了一半信息：查询条件为客户端字段（包含自定义字段），同时需要增加团队成员、是否关注。这里的「是否关注」是一个典型的 1 对多关联条件——客户是列表主表，团队成员是子表，关注关系又是另一张表。高级查询的筛选逻辑要决定用 EXISTS 还是 JOIN，否则会出现重复行。

我的常见做法：

-- 按团队成员筛选时用 EXISTS，避免客户行重复 SELECT c.* FROM crm_customer c WHERE c.org_id = :currentOrgId AND EXISTS ( SELECT 1 FROM crm_customer_team_member m WHERE m.customer_id = c.id AND m.user_id = :userId ) AND c.followed_by_current_user = 1

逻辑说明：用 EXISTS 而不是 JOIN，是为了防止一个客户有多个团队成员命中时，列表返回重复行。高级查询的筛选条件如果都走 WHERE 里的 EXISTS 子查询，性能在几万客户量级下还能接受，但如果你要支持「团队成员中包含多人」，比如同时筛选张三和李四都在团队里，EXISTS 就要写两个子查询并做 AND 关联。

参数说明：:currentOrgId是当前操作员所属组织，:userId是当前登录人。followed_by_current_user是关注关系的冗余字段，也可以在客户表之外建单独的关注表，取决于你在客户高并发查询时要不要避免关联。另一个可选的方案是把关注关系放在 Redis 或一张极简的关注表里，理由是客户列表高频查询时，每行去 JOIN 一次关注关系成本不低。

「是否关注」这个条件还有个交互细节：列表页应该有快速切换的入口，而不是让用户每次都进高级查询。PRD 的预置查询方案里有「我关注的客户」，所以这个条件已经通过查询方案覆盖了，高级查询里再放一次属于冗余但无害，注意做好两个筛选条件的叠加逻辑即可。

3.3 列表按钮与批量操作的权限边界

列表按钮清单包含：新增、编辑、删除、更改负责人、导入、高级查询、导出、搜索。关键约束是：

• 编辑不可批量，保存后更新修改的行且不重新排序
• 删除支持批量，需要有删除确认界面
• 更改负责人可批量，参照选人，确定后修改选中客户的负责人
• 导入按模板批量导入
• 导出把当前页面的数据导出到 EXCEL

有一个交互细节写得很清楚：当鼠标移动到某字段时，可出现编辑按钮，点击编辑当前字段内容，失去焦点保存。这是行内编辑的实现。做这种交互时，我建议你对「可行内编辑的字段」做一个白名单，比如客户名称、电话、地址可以，但创建时间、最后修改时间、所属组织绝不能放进去，否则会出现用户改了字段但系统审计时间戳没更新的数据不一致问题。

「删除支持批量」在 CRM 里其实是个双刃剑。客户在未来可能关联了大量动态、商机、合同、订单，物理删除会导致关联数据全部悬挂。有些系统做得激进，直接把客户放在回收站里，关联数据保留但不可见，等真正确认删除后给客户下关联的所有业务单据打标记。你如果照着这份 PRD 实现，至少要加一个软删除标记，并在删除确认界面写上「将同时置空相关业务单据的客户引用」之类的提示。PRD 里没提这个，所以我必须说：做的时候自己补上。

导出到 Excel 的数据范围是「当前页面数据」，也就是只导出当前查询方案下的当前页。这里有两个大多数人会忽略的细节：一是要有最大导出行数限制，比如一次导出最多 5 万行，超出后提醒用户缩小查询范围；二是导出的列要跟随用户自定义的显示列，不能前端自定义了显示列，导出的 Excel 却是全字段，这个不一致会让销售直接暴走。

4. 客户详情页与团队协同：动态、相关、团队成员与层级关系

4.1 详情页四块分区与按钮优先级

客户详情页是客户跟进管理的核心页面。PRD 给出的描述是：客户数据中心，可新建和查看跟客户有关的联系人、商机、动态、合同、订单、团队成员信息。

详情页的按钮清单和成交状态是关联设计的。详情页里包含：新建操作（新建联系人、商机、动态等）、编辑、更多操作（合并、发起讨论、更改负责人等）。页面分区上，从界面示意图可以推断出四块：顶部客户基本信息、中间动态区、右侧相关对象列表、底部或侧栏团队成员。

在移动端或窄屏下，这四块要重新排布。我的做法是：基本信息折叠到顶部卡片，动态作为主时间线，相关对象切换成 tab，团队成员放底部。这样既保留桌面端的信息密度，又不至于在小屏上挤成一团。

4.2 成交状态与工商注册：系统自动状态判断的逻辑

成交状态的枚举是「未成交、已成交」，默认未成交。PRD 里写了「工商注册：系统判定，非空，不可编辑」，但没给出判定的触发时机。

从软件需求说明书的常规写法推断，合理触发时机是：新建客户保存时先判定一次；随后如果客户名称被编辑，再次触发判定；如果接入了工商数据源，则根据名称命中返回结果。这块我建议做成异步：客户列表加载时先显示前一次判定的缓存值，后台任务扫描名称变更的客户，调用工商接口回填结果并更新时间。你不能在客户保存的同步链路里挂工商接口调用，否则接口超时就直接导致保存失败。

成交状态的变更更适合做成显式操作，而不是自动。常见做法是详情页顶部放一个「标记成交」按钮，点击后要求填写成交时间、成交金额、成交来源，生成一条动态。这个操作要写进活动记录，并且按状态转换图约束：已成交的客户不能直接改回未成交，除非有审批流或管理员权限。PRD 3.1.3.3.1 提到了状态转换图但没有展开内容，所以这里要靠经验补充。

4.3 客户合并、导入导出与查重设置的触发机制

客户合并是一个被严重低估的功能点。销售 A 建了一个「北京华信科技有限公司」，销售 B 建了一个「华信科技」，两个客户其实是一家。合并的目标是：选择主客户，把其他客户的联系人、商机、动态、合同全部迁到主客户下，并从列表中移除被合并客户。

合并的坑在于关联数据迁移。如果动态里有「客户名称」的冗余字段，合并时要批量 UPDATE 到主客户名称；如果商机、合同有客户外键，则要改外键指向。更麻烦的是团队成员：被合并客户如果有自己独立的团队成员，合并后团队是否合并？要不要提醒团队成员？我建议合并前做一个影响预览，列出将被迁移的关联对象数量，让操作人二次确认，同时把合并动作本身生成一条动态记录到主客户下，保证审计可追溯。

导入功能依赖模板。PRD 提到「按照导入模板批量导入客户数据」，但没有给出模板字段清单。按关键数据项推导，模板至少应包含：客户名称（必填）、上级客户、行业、公司人数、电话、省市区、地址、业务类型、客户级别、负责人、所属部门。导入的必填校验要全部在服务端做，不能信任前端校验，否则大批量导入时，一行格式错误就可能导致整个事务回滚。

我建议导入用两步校验加预览：

# 第一步：前端读取 Excel 并做基础格式转换 # 第二步：后端逐行校验并返回错误明细 curl -X POST /api/crm/customer/import/preview \ -H "Content-Type: multipart/form-data" \ -F "file=@customers.xlsx" \ -F "action=validate" # 校验通过后再次提交执行导入 curl -X POST /api/crm/customer/import/execute \ -H "Content-Type: multipart/form-data" \ -F "file=@customers.xlsx" \ -F "action=commit"

逻辑说明：把导入拆成 validate 和 commit 两步，第一步只返回每行错误原因，比如第 3 行客户名称为空、第 7 行电话格式错误、第 12 行负责人不存在。用户可以根据错误明细修正 Excel 后重传，避免导入到一半失败又回滚的体验。

参数说明：action=validate是预校验，不写库；action=commit是真正导入。导入模板中「负责人」字段如果填写了姓名，后端要解析成用户 ID，而且只有当该用户在当前组织内时才能映射成功，否则会报「负责人不在当前组织」。这个校验非常容易被忽略，也是导入功能翻车率最高的原因之一。

查重设置在 PRD 3.1.4.2 有标题但内容是空的。实际做的时候，查重字段通常是客户名称，算法用全名称精确匹配 + 别名模糊匹配。更稳的做法是：在客户名称字段上建唯一索引的变体——一个「客户名称归一化」字段，去除空格、全半角统一、大写转小写，保存时对归一化字段做唯一约束。这样能拦住「华信科技」和「华信科技（北京）」这类近似重复，但也要允许用户强制保存（走审批或标注为非同客户），完全拦住会造成录入障碍。

5. 客户管理PRD避坑指南：四处在开发前必须确认的设计盲区

5.1 批量删除的关联数据处理策略缺失

现象：PRD 只给了「删除当前选中行，需要有删除确认界面，支持批量操作」，但没有任何关于客户删除后联系人、商机、动态、合同、订单如何处理的描述。如果开发照做，就会出现客户删了、商机列表里还挂着已删除客户的外键、详情页打开报空指针的问题。

原因：PRD 的「删除」停留在列表行的操作层面，没有定义删除对关联数据的级联影响，也没有约束删除前置条件，比如有未结商机的客户是否允许删除。

解决：实现时要加三层防线。第一，客户表加is_deleted软删除标记，列表查询统一过滤。第二，删除前置校验：如果该客户下有未关闭的商机或有效合同，弹窗提示并阻断操作。第三，走回收站或删除记录表，保存操作人、操作时间、被删除客户的完整快照，便于误操作恢复。从那次之后，我每次看到 PRD 里出现删除操作时，都会强制追问一句：删除后关联数据怎么办。

5.2 上级客户循环引用的校验时机

现象：客户 A 的上级客户设为 B，之后又打开 B，把 B 的上级客户改成 A。列表页的客户层级关系展开时死循环，或者详情页展示上级链时栈溢出。

原因：仅校验了「上级客户不能是自己」，没有校验间接循环。数据字典里明确写了「上下级关系，不允许互为上下级」，但「互为上下级」包括多级循环。

解决：保存时做递归校验，检查当前客户的整条上级链上是否出现当前客户 ID。代码可以参考：

async function validateParentChain(customerId, newParentId) { let cursor = newParentId; const visited = new Set([customerId]); while (cursor) { if (visited.has(cursor)) { throw new Error('存在循环上级关系，保存失败'); } visited.add(cursor); // 逐级向上取上级客户 cursor = await getParentId(cursor); } }

逻辑说明：从新的上级客户开始逐级向上走，如果中途回到当前客户 ID，就是循环引用。这个校验可能涉及多次查询上级客户，建议最多限制 10 级，超出就报「层级过深」。否则遇到一个超长上级链，递归查询就会拖垮接口。

参数说明：customerId是当前要保存的客户 ID，newParentId是即将设置的上级客户 ID。visited集合存放已访问节点，防止环形链路无限循环。实际生产里我会把整条上级链一次性查出放在内存里遍历，而不是写循环 SQL，理由是层级链查询在数据量大时延迟不可控。

5.3 工商注册布尔值在无数据源时的失真

现象：工商注册字段设计为布尔、非空、系统判定，但如果项目没有接入工商数据源，这个字段就会变成永远为 false，所有客户都显示「未注册」，等于这个字段失去意义。

原因：PRD 假设了有工商数据源，但没有明确标注数据源缺失时的退路方案，而布尔值也没有「未知」状态。

解决：在需求评审时就要确认数据源。没有数据源时把字段改成「注册状态」枚举：已注册、未注册、待核实，默认待核实，允许人工修改。如果未来接入数据源，再按来源回填。这类问题在内部系统的 PRD 里很常见，因为产品经理会假设「系统判定」天然可用，而技术侧必须把「判定」拆成「数据源 + 规则引擎 + 缓存策略」才接得住。

5.4 七日未跟进客户查询方案的时间口径

现象：预置查询「七日未跟进客户」的定义是未跟进天数 > 7 天，但 PRD 没有说明「未跟进天数」从哪一天开始算、是否按自然日还是工作日、是否排除节假日。

原因：时间口径没有定义清楚。如果按「最新活动记录时间」距今超过 7 个自然日，那周五录入的活动，到下周五就超时，中间跨个周末可能只隔了 3 个工作日。销售团队会认为不公，统计同学会认为口径不对。

解决：先把口径和业务确认清楚。我的建议是优先按自然日计算并与业务说明保持一致，理由是这个逻辑最简单、最容易和销售对齐。如果业务强调工作日，则在客户表增加一个冗余字段next_follow_up_date，由动态录入时按工作日规则计算，查询直接用next_follow_up_date < now()，避免查询时再做复杂计算。还有一个细节：时间单位用「天级别」还是「小时级别」，也会直接决定你的索引设计。按天缓存冗余字段，比每次查询算一个时间区间要快得多，尤其在客户表数据量超过 10 万行的场景下，这个字段就是查询性能的分水岭。

6. 把这份 PRD 变成可执行的验收清单：从需求到用例的一个习惯

6.1 关键数据项转需求追踪矩阵

读 PRD 不是看一遍就过。我的习惯是拿到客户关键数据项表格后，先转成一份需求追踪矩阵，每行对应一个字段，列包含：字段名、类型、来源、必填、可编辑、UI 位置、校验规则、对应接口、测试用例编号。这一步能把你和产品经理之间「我以为」的偏差提前暴露出来。

比如「所属组织」在 PRD 里是不可编辑、系统自动，但接口层面呢？如果前端把所属组织也传上来，后端是忽略还是拒绝？如果忽略，那一个能伪造请求的调用方就可以把客户挂到别的组织下，这属于越权漏洞。正确做法是后端从登录态取组织，不信任前端传值。这类细节，只有落在验收清单里才可能被测试覆盖到。

6.2 查询方案映射到接口参数

五个预置查询方案，在接口层要能用一个枚举或查询类型参数表示：

{ "queryType": "MY_FOLLOW_UP_DUE", "pageNum": 1, "pageSize": 20, "orderBy": "createTime", "orderDir": "desc" }

逻辑说明：queryType是枚举值，服务端根据枚举把查询条件拼进 WHERE。这种做法比前端传一堆「负责人 = 我」这种松散的过滤条件更安全，因为服务端可以完全控制每一个枚举对应的查询条件，避免用户在请求里注入额外条件拿别人的数据。MY_FOLLOW_UP_DUE对应「七日未跟进客户」，服务端在代码里写死时间边界和最新活动记录时间的比较逻辑。

参数说明：pageNum和pageSize是分页参数，orderBy和orderDir控制排序。这里有一个经验值：客户列表分页建议限制最大 pageSize 为 200，超过直接返回参数错误。目的是防止有人一次拉全表数据，把后端接口打爆。导出功能单独走异步任务，不占列表接口的线程池。

6.3 Reviewer 自己走一遍闭环，再让开发动手

在把文档给开发之前，我会按客户生命周期走一遍用例：新建客户 → 列表搜索 → 进入详情 → 新增联系人 → 录入跟进动态 → 标记成交 → 查看团队成员 → 合并重复客户 → 导出数据。这九步只要有一处走不通，就说明 PRD 的状态转换图、业务流程描述或者权限规则存在缺口。

比如新增客户时，如果「工商注册」是必填且系统判定，那测试环境没接数据源，测试用例就只能永远填 false，回归测试根本无法覆盖「已注册」分支。这种问题，在写用例时就会发现，而不是等开发做完后才返工。

从那以后，我每次拿到类似的 PRD 都会强制走一遍这条闭环，并把缺口在评审会上当场提出，拿到的反馈再补回到验收清单里。这份客户管理 PRD 虽然年代的痕迹明显，字段设计和交互描述却依然能打，是内部系统开发很可靠的参考底稿，希望帮到你。

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