企业官网建设流程全解析

简介：这是一份由蜂网供应链管理（上海）有限公司于2017年8月发布的《客户关系管理CRM-客户管理-软件需求说明书 V1.0》PDF文档，编写人周旭丽。内容面向CRM产品经理、需求分析师及系统开发测试人员，用于梳理客户信息管理、联系人跟踪、销售预测、市场营销自动化等核心需求，为系统设计提供需求基线。文档共54页，完整涵盖项目背景、目标顾客、平台政策、竞品分析、名词解释（客户档案、交互历史、销售漏斗）、业务流程、系统用例及功能列表等模块，同时给出客户管理各环节的数据集成、移动支持、安全性和用户体验要求。资源为1个PDF文件，压缩包大小3.11MB，目前已有312人学习下载。对准备开展CRM客户管理模块设计、需求评审或后续开发验收的团队，是一份可直接对照参考的需求说明模板。

1. 客户关系管理CRM的客户管理PRD：先搞懂这份文档要解决什么问题

很多团队做客户关系管理CRM，第一版PRD最容易写成“增删改查说明书”。我见过不少项目，客户管理页面画了一大堆，客户从哪来、被谁跟进、烂在谁手里、怎么回收，全都没定义。这份“客户关系管理CRM-客户管理-PRD-V1.0-20170825”其实有一个很关键的动作：把客户管理当成一个生命周期系统来设计，而不是一张静态数据表。它要解决的是三件事：客户资源怎么进系统、怎么被高效跟进、怎么防止流失和撞单。版本号和日期意味着这是一条需求基线，后续开发、测试、迭代都拿它当参照。适合谁看？产品经理照着搭需求框架，研发理解字段和状态背后的业务规则，创业团队拿它当第一版CRM的参考。下文就按“怎么拆、怎么设计、怎么避坑、怎么验收”的顺序把这条基线讲透。

2. 客户管理PRD怎么拆：从业务目标到功能清单的映射

开始动手写文档之前，先要回答一个问题：客户管理模块的业务目标是什么。常见答案只有四句话——客户信息进得来、查得到、跟得上、分得清。后面所有功能拆解都围着这四条转，跟这四条无关的页面先砍掉。

2.1 CRM客户管理模块为什么是地基：它承载了什么

客户管理在CRM里的位置很特殊：它是主数据。一张客户档案下面挂着多个联系人、一串跟进记录、若干商机、还有成交后的合同和回款。销售打开系统看到的是“某个客户的全貌”，研发眼里是一张customer表加上几张子表，PRD要做的第一件事就是把这张主表和子表的关系说清楚。

常见的错误是PRD里只写“客户列表、新增客户、编辑客户、删除客户”，把客户管理写成一个孤立模块。实际上跟进记录、商机、公海池都依赖客户ID做关联，字段设计时漏掉一个关联键，后面接商机模块时就要返工。

现在主流CRM产品都是Web端永久在线，浏览器打开就能用，不需要装客户端。这对销售意味着拜访现场用手机补录一条客户很快，对企业意味着客户数据的录入成本被压得很低——数据质量压力反而更大。录得快就容易录得脏，所以去重规则设计得比录入体验更重要，这一点很多团队是上线后才意识到。

2.2 用业务流程倒推功能清单：三步拆出PRD需求

我一般不会直接对着竞品抄页面，而是先画一遍客户从进来到离开的主流程，再倒推功能清单。这套操作分三步，每一步都有产出物，评审时拿产出物对线比翻页面高效得多。

第一步，画主流程。客户创建（手动录入、Excel批量导入、移动端扫码采集）→ 客户分配（自动分配或手动认领）→ 跟进记录（电话、拜访、微信）→ 状态变更（潜在、意向、成交、流失）→ 公海回收。画完主流程，主功能基本就齐了。

第二步，列角色和每个角色的操作。通常至少有三个角色：销售、销售主管、管理员。把触发条件和结果一起写进表里，比单纯列功能点更能暴露逻辑漏洞：

第三步，补异常分支。重复客户怎么合并、离职客户怎么交接、回收前要不要提醒销售、客户被误删能不能恢复。这些分支不写进PRD，开发就会自己拍脑袋。

三步跑完，功能清单基本不用发愁缺项。而且每一条功能都能回溯到业务流程，评审时讲得出“为什么做”，不是“别人家有所以我们要有”。

2.3 客户数据字典怎么写：字段定义到可评审

功能清单定了之后，最见功力的地方是数据字典。客户对象的核心字段我用JSON来定义，开发直接拿这个对接，评审也直观：

{ "customer_id": "CUS202708250001", "name": "深圳市某某科技有限公司", "short_name": "某某科技", "level": "A", "source": "scan_visit_card", "owner_id": "U10086", "status": "potential", "phone": "13800138000", "wechat": "zhangsan_dev", "province": "广东", "industry": "软件服务", "next_follow_time": "2025-09-01 10:00:00", "created_by": "U10086", "created_at": "2025-08-25 14:30:00" }

这段JSON里的字段按五组管理：基础信息（name、level、industry、province）、联系方式（phone、wechat）、归属信息（owner_id）、业务信息（source、status、next_follow_time）、系统字段（customer_id、created_by、created_at）。其中customer_id是系统生成唯一标识，owner_id为空表示客户在公海池，source标记客户来源，直接支撑运营统计哪个渠道带来的客户质量高。

字段定义时最容易踩的坑是把“手机号必填”和“手机号唯一”绑在一起。必填是录入要求，唯一是数据约束，这是两个决策。很多团队为了省事把手机号设成必填且唯一，结果一个集团客户有多个事业部、多个对接人时，后面的人永远录不进去。正确做法是：联系人层面一个手机号只能属于一个联系人，客户层面允许一个客户挂多个手机号，跨客户去重单独走规则。这个区分想清楚了，数据字典才经得起推敲。

3. 客户全生命周期设计：从线索录入到回收的流程与状态机

客户管理不是一张静态表，它是一条流水线：客户进来、被跟进、被转化或流失、被回收再分配。PRD里要把这条流水线的每一个节点写清楚，否则销售和开发的认知对不齐，做出来的东西多半是“能录能查”但“跟不住”。

3.1 客户创建入口与去重规则：手机号还是公司名

客户从哪来，决定了录入体验怎么做。常见入口有四个：

手动录入，销售电话沟通中随手建，字段要精简到两分钟内能填完，PRD里核心字段控制在六个以内，其余靠后续跟进逐步补全。Excel批量导入，用于老客户迁移和市场名单导入，导入时必须支持先去重预览、再确认执行，不能一上来就灌数据。移动端扫码采集，这个入口现在很常见——销售在展会现场扫客户名片，系统自动识别公司、姓名、职位、电话，形成一条草稿客户记录，销售确认后再转入正式库。还有Web端表单，官网留资、活动报名的数据自动入库。

去重规则按优先级组合执行：手机号优先，微信次之，公司名加联系人兜底。手机号是强规则，同一个手机号不能出现在两条有效客户记录里；公司名匹配要宽容一些，“深圳市某某科技”和“深圳某某科技”大概率是同一家，需要做归一化处理。去重时机分三个点：创建时同步查重、导入时批量预检、发现疑似重复时进入待合并列表人工确认。

提示：去重规则的宽容度要可配置，不要写死在代码里。团队初期客户少可以严格匹配，客户量上来之后误杀率会显著上升，到时候改规则比改代码快得多。

3.2 跟进记录与状态机：状态是枚举不是备注

客户状态是CRM客户管理里最容易做歪的部分。很多PRD把状态设计成自由填写的文本字段，销售想填什么填什么，结果报表口径一团乱麻。状态必须是枚举，由系统严格控制流转路径。

这六个状态加一个公海，基本覆盖了客户生命周期的主要分支。为什么要有invalid这个状态？因为很多销售遇到打不通的客户，不知道该放哪个状态，只好随手填一个“已联系”，三个月后公海回收也扫不到他头上。有了invalid，死客户有了明确出口，公海计算和报表统计才干净。

跟进记录的结构也要在PRD里定死：跟进时间、跟进方式（电话、拜访、微信、邮件）、跟进摘要、下次跟进时间。上次跟进时间决定是否触发回收规则，下次跟进时间是过程管理的抓手。主管盯销售，不用问“最近在忙什么”，看系统里明天的跟进计划就够了。

3.3 公海回收规则：参数怎么设才不会误伤

公海池的定义一句话说清：没有归属人，或超时未跟进的客户，回到公共池子里让其他人认领。回收规则是客户管理PRD里最能体现业务策略的部分，参数不能拍脑袋定死，要找运营要建议值，再根据实际数据调整。

回收规则设计有一个容易被忽略的细节：冷却期。没有冷却期的公海池形同虚设，销售可以把客户在手里放到最后一天，等回收进公海再秒抢回来，等于没回收。加了24小时冷却期，至少给其他销售留了一晚上的窗口。这个规则不是罚销售，而是防止客户资源烂在个人手里——客户属于企业，不属于销售个人，这句话在PRD原则里要写明。

参数设置还讲究节奏：团队初期先放宽，未跟进天数可以放到14天，等销售养成每天跟进的习惯后，再逐步收紧到7天。刚上线就定严规则，销售还没适应系统，客户就被回收光了，会引发很大的反弹情绪。

4. 权限与协作：客户数据安全的分级设计

客户数据是公司资产，权限设计一旦崩了，销售离职带走客户、主管看不见团队进展、市场人员能导出全量客户电话，每一个都够让管理层头疼。权限章节在PRD里往往是最后一个写的，但恰恰是它决定系统能不能真正上线运转。

4.1 数据权限三种做法：全员可见、部门隔离、仅本人+上级

数据权限说的是“你能看见哪些客户”。按组织架构分，常见做法有三种：

全员可见适合十人以内的小团队，销售互相能看到客户，撞单靠自觉。优点是信息透明，缺点是客单价高的行业容易恶性抢单，两个销售同时跟一个客户，最后比谁手快。部门隔离按组织架构树过滤，销售只能看本部门或本区域的客户，适合有区域分工、产品线分工的团队。仅本人加上级最稳，销售只能看自己名下客户，主管看全组，客户数据完全隔离，但缺点是主管脱离系统就很难掌握全局，客户情况成了黑匣子。

我的建议是新团队从“仅本人+上级”起步。数据越隔离，销售录入越认真，后续放开也容易；反过来一上来就全员可见，等出现抢单再收紧，销售抵触情绪会非常大。

4.2 操作权限与字段级隐私：导出审批与手机号脱敏

数据权限管“看”，操作权限管“改和删”。客户管理模块的操作权限至少要有四把锁：谁能创建、谁能编辑、谁能删除、谁能导出。删除一律走软删除，进回收站保留三十天，防止手滑误删后没有后悔药。导出是最危险的动作，必须单独设权限，销售导出自己名下客户可以，管理员导出全量客户要走审批流，导出记录留痕。

字段级隐私是另一层：手机号是最高敏感字段，对财务、市场人员脱敏显示，销售本人和直属主管明文可见。脱敏必须放在后端做，不能只在前端把数字打上星号以为就安全了——接口返回的是明文，调接口照样拿得到。

注意：手机号脱敏要连带导出文件一起生效，导出Excel里同样打码。很多系统页面脱敏做了，导出漏了，一导出全是明文手机号，设计等于白做。

4.3 共享、转移与离职交接：归属变更的边界

客户归属不是一成不变的，PRD里要把三个动作写清楚。共享：A销售想拉B销售一起跟一个客户，共享只读，不改变归属，共享范围要定义成“整个客户档案”还是“仅联系人”，避免把不该暴露的信息带出去。转移：客户从A名下转到B名下，转移后历史跟进记录保留在客户档案里，B接着写新的跟进，不能因为换人就丢了历史上下文。

离职交接是最容易被忽略的场景。销售离职时系统要把名下的客户批量变更归属到主管或接手人，同时清掉他创建的待办任务和下次跟进计划。离职交接一旦做得不彻底，离职员工的客户池会变成一批状态未知的孤儿数据，后续运营完全不知道从哪下手。这个场景在开发排期里经常被砍掉，但它属于上线前必须有的能力，哪怕第一版做得粗糙，也要先把批量变更跑通。

5. 客户管理PRD的常见坑：5条血泪排查记录

客户管理模块看起来简单，实际落地翻车点很集中。下面五条是我反复见到的坑，每条按“现象、原因、解决”记录，评审时照着逐条过一遍能省不少返工成本。

5.1 客户认领与去重：手机号唯一设死的翻车现场

现象：一个集团客户有多个事业部，每个事业部用不同手机号找过来，系统只认第一个录入的人，后面的销售录什么都被“手机号已存在”挡住，客户在群里喊被锁死了。原因：PRD里把手机号设成必填且唯一，把“一个客户”和“一个手机号”画了等号。解决：手机号唯一性只在联系人维度约束，客户维度用“手机号加公司名”组合规则去重，命中疑似重复时进入待合并列表人工确认，不直接拦截。

5.2 状态枚举与回收规则：销售“跟丢了”没有出口

现象：销售遇到一个客户连续打了五天电话没人接，不知道该选哪个状态，于是备注里写“跟丢了”，三个月后公海回收也没把他算进去。原因：状态机里没有“无效”出口，回收规则只按“未跟进天数”计算，不排除无效客户。解决：状态机补上invalid和lost两个终态，并写明无效客户不参与回收、流失客户进入公海后必须等冷却期结束才能再次领取，防止销售把跟丢的客户秒抢回去。

5.3 权限、导出与交接：数据安全的三个漏勺

现象一：离职销售导出一份客户Excel带走，管理员一个月后才在导出记录里发现，客户信息已经泄露出去了。原因是导出权限开给了所有销售，导出不需要审批。解决：导出申请走审批流，管理员审批时能看到导出范围和行数，导出文件自动打上导出人水印。

现象二：客户交接之后，新接手销售打开客户档案，历史跟进记录全没了，不知道客户之前聊到哪版方案。原因是跟进记录按“创建人”过滤，没有挂在客户ID下。解决：跟进记录归属永远跟客户走，不跟人走，交接只改owner_id，历史记录自然完整保留。

现象三：手机号在页面上显示脱敏了，但接口返回值是明文，前端抓包就能看到完整号码。原因是脱敏只做了前端展示，后端接口没处理。解决：后端统一脱敏，前端只负责渲染后端返回的结果，这个规则要在PRD的接口设计说明里明确写出来。

6. 从PRD到上线：评审清单、验收指标与第一版落地节奏

PRD写得再细，评审不过关等于白写。我习惯在评审前准备一份清单：客户状态有没有不可达的死角，每个状态能不能按规则进入又按规则退出；回收规则的每一项参数，运营能不能在后台配置而不改代码；导出有没有审批流，接口层是否做了脱敏；每个角色在界面看到的客户范围，是否和组织架构树的过滤逻辑一致。评审时把清单上的问题逐条过，比自由讨论高效很多。

第一版强烈建议收窄范围，只做客户管理、跟进记录、公海回收这三块，商机、报价、订单全部放到第二版。客户管理是地基，先把数据和归属跑干净，再在上面盖楼。验收指标可以用一段SQL直接统计，上线后每周跑一次：

SELECT COUNT(DISTINCT customer_id) AS total_customers, AVG(DATEDIFF(NOW(), last_follow_at)) AS avg_no_follow_days, SUM(CASE WHEN owner_id IS NULL THEN 1 ELSE 0 END) AS in_public_pool FROM customer WHERE created_at BETWEEN '2025-08-01' AND '2025-08-31';

这段SQL统计三个指标：客户总量、平均未跟进天数、公海池客户数。前两个判断业务是否健康运转，第三个衡量回收规则有没有真正生效。平均未跟进天数超过七天，说明销售跟进习惯还没养成，回收规则再严也没用。

我做这个方向有个习惯：PRD评审前先自己把每一个状态的流转路径走一遍，尤其是异常分支。前几年写权限设计总觉得不着急，留到最后再补，结果每次返工返得最狠的都是权限。后来我把权限和数据字典提到最前面做评审，开发一次通过率反而高了很多。这份PRD的价值不在文档本身，而在于让整个团队对客户管理的边界达成共识——先想清楚状态和权限，再谈页面和功能，希望帮到你。

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