一份PRD引发的血案
2023年秋天，某造车新势力售后产品经理小李花了2周写了一份**「智能预约系统」PRD文档**，交给IT开发。
3个月后，系统上线，结果是场灾难：
门店经理爆发：
「这不是我要的！我说的是客户预约时自动推荐服务项目，你们做成了强制选择，客户根本不用！」
IT开发回击：
「你的PRD写的是‘系统应向客户展示可选服务项目’，我们就这么实现的啊！」
问题在哪？
小李回家翻出那份PRD，发现关键部分写的是：
「需求描述：系统应向客户展示可选服务项目，供客户选择。」
他想表达的：智能推荐，但客户可以不选
开发理解的：展示所有选项，客户必须选
这次事故导致：
- 150万预算打水漂
- 系统推倒重来（3个月 + 100万）
- 小李被降职
这个惨痛的故事告诉我们：
PRD（Product Requirements Document，产品需求文档）不是写给自己看的，是写给开发、测试、运营等所有相关人看的。一个字的模糊，可能导致百万损失。
什么是PRD？为什么售后运营要会写？
PRD的定义与作用
PRD (Product Requirements Document) = 产品需求文档
它是连接业务需求和技术实现的桥梁：
| 角色 | 看PRD的目的 | 最关注的部分 |
|---|---|---|
| 业务方 | 确认需求被准确理解 | 功能描述、场景还原 |
| 开发 | 知道要做什么功能 | 功能逻辑、交互设计、异常处理 |
| 测试 | 知道要测什么 | 验收标准、测试用例 |
| 运营 | 准备培训材料 | 使用流程、业务规则 |
| 项目经理 | 评估工作量与排期 | 功能清单、优先级、依赖关系 |
售后运营为什么要会写PRD？
误区：「PRD是产品经理的事，运营只要提需求就行。」
现实：
- 中小公司没有专职产品经理，运营就是产品经理
- 与IT沟通效率提升10倍：一份PRD胜过10次会议
- 避免“你说的不是我理解的”：白纸黑字，无法疗论
- 提升专业形象：会写PRD的运营 = 懂业务懂产品的高手
真实数据：
某车企售后运营团队引入PRD机制后：
- 项目返工率：从35% → 8%（↓杣77%）
- 开发周期：平均95天 → 62天（↓杣35%）
- 项目上线成功率：68% → 94%（↓38%）
PRD的核心结构：8大必备要素
一份合格的PRD必须包含这8个部分：
1. 文档基本信息
必须包含：
- 文档标题
- 版本号（如 V1.0、V1.2）
- 创建人 & 创建日期
- 最后更新人 & 更新日期
- 当前状态（草稿 / 评审中 / 已确认 / 开发中 / 已上线）
- 审核人清单
示例：
文档标题：门店智能预约系统 PRD
版本号：V2.1
创建人：王艳（售后运营专家）
创建日期：2024-03-15
更新人：李明（IT产品经理）
更新日期：2024-04-08
当前状态：已确认，待开发
审核人：王总（售后总监）✓、张总（IT总监）✓、赵经理（区域经理）✓
💡 为什么重要？
- 版本号避免混乱：开发拿的是老版本，做出来自然不对
- 审核人明确责任：出问题知道找谁
2. 项目背景与目标
必须回答的问题：
（1）为什么要做这个项目？（Why）
❌ 错误写法：
「为了提升门店运营效率。」（太空洞）
✅ 正确写法：
「业务现状：目前门店预约主要依赖电话，高峰期（12:00-14:00）电话占线率达85%，导致30%的客户放弃预约。
业务影响：
- 客户满意度：NPS 72分，低于目标的80分
- 门店工位利用率：65%，存在35%空置
- 年机会成本损失：约1200万元
竞品动态：蔡来、小鹏已上线智能预约，我们处于落后。」
（2）要达成什么目标？（What）
原则：SMART原则
- S (Specific): 具体的
- M (Measurable): 可衡量的
- A (Achievable): 可达成的
- R (Relevant): 相关的
- T (Time-bound): 有时间限制的
❌ 错误写法：
「提升客户满意度」（无法衡量）
✅ 正确写法：
业务目标：
- 预约成功率：从70% → 90%（Q2结束前达成）
- 工位利用率：从65% → 82%
- NPS得分：从72 → 80
- 服务顾问电话接待时间减少50%
技术目标：
- 系统响应时间 ≤ 2秒
- 并发支持 ≥ 500人/分钟
- 系统可用性 ≥ 99.9%
（3）不做会怎样？（Impact）
这个部分很多人忽略，但非常重要：
如果不做这个项目：
- 继续流失每年约2000个客户（每月流失约170人）
- 年度机会成本损失累计超过1200万元
- 竞品优势进一步拉大，品牌形象受损
- 门店人员长期疑于低效重复劳动，离职率可能上升
💡 为什么重要？
- 让决策者看到紧迫性，更容易批准预算
- 让开发团队理解你的项目为什么重要，提高配合度
3. 目标用户与使用场景
必须明确：
（1）谁会用这个系统？
用户画像法：
| 用户角色 | 使用目的 | 使用频率 | 技能水平 |
|---|---|---|---|
| C端客户 | 预约门店服务 | 每年平址2-3次 | 基础（含中老年人） |
| 服务顾问 | 处理客户预约、调配资源 | 每天数十次 | 中等（熟练后） |
| 店长 | 查看预约数据、调整排班 | 每天1-3次 | 中等 |
| 区域经理 | 查看区域预约数据、分析趋势 | 每周数次 | 中等 |
（2）他们在什么场景下使用？
场景描述法：
场景1：客户首次预约
角色：王先生，32岁，互联网从业者，车主
时间：周六晚上21:00，在家看电视
触发：车辆仪表盘提示下次保养还剩500公里
动机：想趁周末去门店做保养，但不想等太久
行为：
- 打开品牌App / 微信小程序
- 选择附近门店（根据定位自动推荐）
- 查看周日上午10:00-12:00的空闲时段
- 选择保养项目（系统根据车辆里程推荐）
- 确认预约，收到短信确认
期望：
- 整个流程3分钟内完成
- 无需打电话，不受时间限制
- 能看到实时空位情况
痛点：
- 如果没有空位，不知道什么时候有
- 不确定要选什么保养项目
场景2：服务顾问处理预约
角色：小美，26岁，服务顾问，工作经验1年
时间：周六上午10:30，门店高峰期
触发：系统推送新预约提醒
动机：快速处理预约，合理分配资源
行为：
- 打开电脑后台系统
- 查看客户预约详情（服务项目、时间、车型）
- 查看对应时段的技师和工位空闲情况
- 分配最适合的技师（根据技能匹配）
- 确认预约，系统自动通知客户
期望：
- 整个流程1分钟内完成
- 系统自动推荐最优资源分配
- 不需要手工翻看排班表
痛点：
- 如果没有空位，需要给客户推荐其他时间
- 客户可能中途取消，需要及时释放资源
💡 为什么重要？
- 场景描述让开发站在用户角度设计功能
- 明确期望与痛点，防止功能偏离目标
4. 功能清单与优先级
用MoSCoW法则划分优先级：
- M (Must have): 必须有，没有就无法上线
- S (Should have): 应该有，重要但不是必需
- C (Could have): 可以有，有更好但可以缓缓
- W (Won't have): 不会有，本期不做
示例：
| 功能模块 | 功能点 | 优先级 | 说明 |
|---|---|---|---|
| 客户端 | 门店查询与定位 | M | 根据GPS自动推荐最近3家门店 |
| 实时空位查询 | M | 显示未来7天每小时的空位数 | |
| 服务项目选择 | M | 根据车型和里程智能推荐 | |
| 预约确认 | M | 短信+App推送双重提醒 | |
| 预约取消/修改 | S | 至少提前2小时可取消 | |
| 历史预约记录 | C | 查看近12次预约 | |
| 语音预约 | W | 本期不做，V2.0考虑 | |
| 后台管理 | 预约列表查看 | M | 按日期/状态/门店筛选 |
| 智能资源分配 | M | 系统推荐+人工调整 | |
| 预约冲突提醒 | S | 同一技师同时段多个预约 | |
| 数据统计分析 | C | 预约率、爽约率等 |
💡 为什么重要？
- 明确优先级，开发才知道先做哪个后做哪个
- 预算不足时，可以先做M和S，缓做C和W
写给你的行动指南
今晚的任务：
✅ 基础练习
- 找出你最近的一个需求，用今天学的结构写一个简版PRD
- 必须包含：背景、目标、用户、场景、功能清单
✅ 进阶练习
- 给一个开发同事看你的PRD，问他是否能看懂
- 根据反馈调整，直到对方说「完全明白」
明天，我们将学习PRD的核心部分：功能详细设计、异常处理、非功能性需求，这些是决定项目成败的关键细节。