只有和团队一起评审了你的假设和创意之后（无论是在专门召集的会议上，喝咖啡时，或者桌上足球的休息时间），你才应该真正开始写产品文档。如果已经完成了沟通和评审，整个文档应该花费你 1-3 个小时的时间。

↓↓↓以下是产品文档示例部分↓↓↓

　　灰色引用部分是注释。

　　第一次阅读此文档时建议先忽略注释部分通读此文，然后再回到文初重新阅读所有内容。

　　文中提到的所有超链接并没有链接到任何地方。这篇文章中的外链就只是表明有一些待办事项和相关文档。

在支付时增加在线客服

由 Gaurav Oberoi 撰写

最后更新日期：2016年9月28日

　　这个项目的目标是通过在支付页面增加在线对话客服来提高支付转化率。这是一个为期 30 天的测试，测试完成后我们可能会上线或者关掉这个功能（薛定谔的客服？蛤蛤）。

　　用不超过两行文字描述此项目。我所说的“行”是指你的客户端的默认阅读宽度（例如 Google Docs、维基、文本文件等）。坚持字数限制是可读性的关键所在。

　　I. 概览

　　A. 问题

　　1. 支付转化率过低：只有 18% 的点击了「预订」按钮的用户完成了支付。竞品预订网站可以达到约 30% 的转化率（数据来源）。我们正在失去收入！

　　2. 没有明确的流失原因：之前的工单和用户调查给出了一系列非常多可能的原因（易用性、支付费用、支付耗时方面的问题），也没有明确的分类。

　　3. 增加帮助文档的内容并没有起到作用：上个季度，我们对帮助文档和预定信息的内容及界面设计做了A/B 测试。这只带来了 1.5% 的转化率轻微提升。

　　我强烈建议使用列表来增强文档的可读性。

　　使用粗体文字快捷指出每行文字的要点，并且限制列表在两三行以内。

　　我更喜欢有序列表，因为这样在口头沟通时很容易指示清楚。

　　B. 目标

　　1. 测试客服聊天是否可以明显地提高转化率：每天新增超过 90 个订单就能打平在线客服的运营成本，现在还不清楚是否能做到这一点。这是一次测试！

　　2. 降低测试成本：避免所有的过度优化，如果测试成功，在 Q1 我们就可以优化在线聊天的体验了。

　　3. 在 12 月 1 日前确定最终的结果：在开始做 Q1 计划前，我们还有 8 周时间。

　　确保文档可以提出一个明确的目标，这个目标应当是非常容易判断“达成目标了么？”的。

　　在文档中做出明确的承诺。

　　C. 不应考虑的问题

　　1. 重要的界面修改：只增加一个可见的聊天按钮，不做任何其他的设计改动。

　　2. 确定聊天服务供应商：目前而言先使用 SnapEngage，如果测试成功了，再考虑长期的服务供应商。

　　3. 国际化和非英语用户：为了简化处理，此次测试仅针对美国地区及其他英语用户。

　　这部分用来排除种种不利的假设，树立正确的项目预期。

　　D. 团队成员和角色划分

　　1. Heather（用户运营经理）：批准客服资源需求。

　　2. Randy（用户运营专员）：负责处理用户反馈，每周整理反馈总结。

　　3. Colin（工程师）：开发和测试。也要负责配置SnapEngage，并且给我们展示一下设置方法。

　　4. Kalpana（财务）：在测试阶段以及后续时间负责评审我的盈利预算。

　　5. Joha（设计师）：花一点时间看一下我们在设计上的改动，没有大块的设计需求。

　　6. Vikram（数据分析师）：确保我们能按时拿到此次测试的数据报告。

　　帮助大家明确项目成员及对每一个人的期望。

　　仅包括将会执行这件事情的人，和对这件事情有通过/否决权力的人。

　　II. 背景

　　这里应当包含了解当前问题以及解决方案所需要的所有背景信息。

　　添加任何你认为应该出现在这里的内容，例如：用例、用户模型、数据指标、竞品解决方案、调研结果等等。

　　A. 用例

　　1. 用户需求：

在 2 分钟内获得帮助：不确定是否可以实现，但是我们先冲着这个目标去努力吧。

适配移动端及桌面端：有 28% 的支付是在手机上完成的，所以移动端适配很重要。

　　2. 用户运营团队需求：

有反馈队列的客服后台：在桌面/web 端就可以，不需要支持移动端

增删客服人员：可自助完成，而不需要开发人员支持

设置在线时间：可以控制网站上的在线聊天按钮是否可见。

查看用户信息：需要传递用户 ID 的参数给后台，方便客服人员查找当前用户信息。

给会话打标签：在聊天结束后，可以在注释字段中记录一些非结构化的文本信息。

　　B. 假设