示例产品文档

这是一个示例产品文档，是这篇博客文章的一部分。
说明：

引用格式的文字是我的注释。
第一次阅读此文档时请忽略注释部分通读此文，然后再回到文初重新阅读所有内容。
所有的超链接并没有链接到任何地方。这篇文章中的外链就只是表明有一些待办事项和相关文档。

在支付时增加在线客服

由 Gaurav Oberoi 撰写 。最后更新日期：2016年9月28日。

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

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

概览

问题

1. 支付转化率过低：只有 18% 的点击了「预订」按钮的用户完成了支付。竞品预订网站可以达到约 30% 的转化率（数据来源）。我们正在失去收入！
2. 没有明确的流失原因：之前的工单和用户调查给出了一系列非常多可能的原因（易用性、支付费用、支付耗时方面的问题），也没有明确的分类。
3. 增加帮助文档的内容并没有起到作用：上个季度，我们 对帮助文档和预定信息的内容及界面设计做了 A/B 测试。这只带来了 1.5% 的转化率轻微提升。

我强烈建议使用列表来增强文档的可读性。
使用粗体文字快捷指出每行文字的要点，并且限制列表在两三行以内。
我更喜欢有序列表，因为这样在口头沟通时很容易指示清楚。

目标

1. 测试客服聊天是否可以明显地提高转化率：每天新增超过 90 个订单就能打平在线客服的运营成本，现在还不清楚是否能做到这一点。这是一次测试！
2. 降低测试成本：避免所有的过度优化，如果测试成功，在 Q1 我们就可以优化在线聊天的体验了。
3. 在 12 月 1 日前确定最终的结果：在开始做 Q1 计划前，我们还有 8 周时间。

确保文档可以提出一个明确的目标，这个目标应当是非常容易判断「达成目标了么？」的。
在文档中做出明确的承诺。

不应考虑的问题

1. 重要的界面修改：只增加一个可见的聊天按钮，不做任何其他的设计改动。
2. 确定聊天服务供应商：目前而言先使用 SnapEngage，如果测试成功了，再考虑长期的服务供应商。
3. 国际化和非英语用户：为了简化处理，此次测试仅针对美国地区及其他英语用户。

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

团队成员和角色划分

1. Heather（用户运营经理）：批准客服资源需求。
2. Randy（用户运营专员）：负责处理用户反馈，每周整理反馈总结。
3. Colin（工程师）：开发和测试。也要负责配置 SnapEngage，并且给我们展示一下设置方法。
4. Kalpana（财务）：在测试阶段以及后续时间负责评审我的盈利预算。
5. Joha（设计师）：花一点时间看一下我们在设计上的改动，没有大块的设计需求。
6. Vikram（数据分析师）：确保我们能按时拿到此次测试的数据报告。

帮助大家明确项目成员及对每一个人的期望。
仅包括将会执行这件事情的人，和对这件事情有通过/否决权力的人。

需求背景

这里应当包含了解当前问题以及解决方案所需要的所有背景信息。
添加任何你认为应该出现在这里的内容，例如：用例、用户模型、数据指标、竞品解决方案、调研结果等等。

用例

1. 用户需求：
2. 在 2 分钟内获得帮助：不确定是否可以实现，但是我们先冲着这个目标去努力吧。
3. 适配移动端及桌面端：有 28% 的支付是在手机上完成的，所以移动端适配很重要。
4. 用户运营团队需求：
5. 有反馈队列的客服后台：在桌面/web 端就可以，不需要支持移动端
6. 增删客服人员：可自助完成，而不需要开发人员支持
7. 设置在线时间：可以控制网站上的在线聊天按钮是否可见。
8. 查看用户信息：需要传递用户 ID 的参数给后台，方便客服人员查找当前用户信息。
9. 给会话打标签：在聊天结束后，可以在注释字段中记录一些非结构化的文本信息。

假设

1. 每天增加90个付费订单，可以打平一个客服人员的运营成本：根据每个客服人员的成本以及一个支付用户的 LTV（生命周期价值）。详见表格。
2. 一个客服人力可以支持 20% 的支付流量：基于对等待时间、聊天时长、并发聊天数量的一系列假设。我们没有数据能支持做出靠谱的假设，所以拍脑袋定一个数据，并且需要我们的系统支持快速增加/降低测试流量。
3. 支付转化率应该从18%增加到20％： 总转换率不需要增加特别多就已经意味着测试成功了。在这里查看我们的分析报告。

解决方案

用你能做到的最自然的方式描述你的方案。
需要做到清晰、条理清楚、合理分段。
根据不同项目的特点，你也可以加入： 线框图，用户流程图，表单输入/验证逻辑，数据模型……等执行该计划所需要的所有细节。

在线客服供应商

我选择了 SnapEngage ，符合我们的既定用例并且价格便宜（$60/月）。注：如果测试成功，我们会再选择适当的供应商 。我已经注册了一个付费账户，帐号密码在我们的密码管理工具中。

用户体验

通过 SnapEngage 的文档 来弄清楚他们这个聊天窗口的弹出逻辑。有以下几点：

1. 按钮：设置为「立即聊天」的文案，并且放在详情页中「预订」主按钮的旁边
2. 交互：点击时展示客服姓名，以及「您需要什么帮助？」的文案
3. 所有的支付页面：它应该在所有的三个付款步骤页面上都展示。
4. 不自动弹出：我们可以以后再试这个效果，现在先低调上线测试。

会话参数

1. 这是什么：当我们嵌入服务供应商的 Javascript 时，我们可以传入特定的参数。这些参数客服可以看得到，并且也会记录在日志和数据报告里。
2. 传递这些参数：用户 ID，用户邮箱，浏览器信息，预订 ID，预订订单价格。

测试流量开关

只会有部分支付流量看到在线客服功能。下面是我们需要做的工作：

1. 只展示给 X％ 的用户：我们必须能够在不重新部署的情况下就可以修改 X 的值，但是可以每次修改时都由用户运营团队向工程师提交一个工单来人工修改（例如，将这个值存储在我们的数据库/Redis 中）。
2. 对展示过的用户始终可见：只要用户看到过一次这个聊天窗口，在测试期间此用户就应该始终可以看到这个功能。可以通过 cookie 来存储这个状态，也可以用这批用户的用户 ID 来记录（例如：如果用户 ID 对 100 取模小于 X，就可以看到此功能）。
3. 流量递增方案：第一天，我们只开放 5% 的流量用于测试，如果用户运营团队反馈正常，则在第二天开放至 10% 的流量，第三天开放至 20%。

数据指标和报告

1. 日志记录：在现有的指标当中增加："live_checkout=true/false"。
2. 新的数据报告：
3. 对比有在线客服的用户（测试组）和没有在线客服的用户（对照组）的支付转化率。
4. 在线客服所带来的总订单数和收入。
5. 测试用户中有多少人点击了在线聊天窗口。
6. SnapEngage 的数据报告：可以告诉我们平均会话耗时，以及并发会话数等数据

上面我举的例子可能晦涩难懂，但是我们团队中的工程师和数据分析师则会很容易理解——因为他们正是这部分文档的受众。
记住：写下所有需要人脑执行的必要事项。

未来计划

1. 如果我们发现在线聊天的使用率很低：我们需要尝试一些优化方案，例如：（一）自动弹出聊天窗口，（二）修改聊天按钮样式，（三）在聊天按钮旁边增加客服人员照片。
2. 如果测试验证成功：我们会争取更多的客服人力，并且在 Q1 进行大规模迭代改进，包括选择合适的供应商，更深入的数据分析，以及正式的客服话术培训。

指明项目的未来发展方向永远都是好事，因为这样可以引导人们更长远地去思考。

任务和排期表

考虑到在「未来计划」中提到的问题，这个排期表可能会有一到两周的延期。只要我们能够在 12 月 1 日得到测试结果，我们就在 Q1 人力资源规划时争取到更多的人力。

1. 10 月 4 日：文档评审。
2. 10 月 8 日：和客服团队一起在开发环境中测试如何设置客服人员以及客服时间。
3. 10 月 11 日：上线。我们会在接下来的数天中逐步增加测试流量。
4. 10 月 17 日：在上线1周后同步信息。在此时我们可能会有一些额外的工作要做。
5. 11 月 12 日：最后一次沟通，评审当下状态以决定继续推进还是结束此项目。
6. 12 月 1 日：这是完成此项目并且得到测试结果的最终截止日。

开始的时候排期表可以只有一个大致的估期，通过更多的分析来逐步精确时间点（例如需要技术文档）。
但是尽早尝试拆解和确定时间点，大致框定每项工作的范围和规模仍然是非常重要的。
工期估算应当来自于 执行方（开发，设计等）。