1. 每天增加90个付费订单，可以打平一个客服人员的运营成本：根据每个客服人员的成本以及一个支付用户的 LTV（生命周期价值）。详见表格。

　　2. 一个客服人力可以支持 20% 的支付流量：基于对等待时间、聊天时长、并发聊天数量的一系列假设。我们没有数据能支持做出靠谱的假设，所以拍脑袋定一个数据，并且需要我们的系统支持快速增加/降低测试流量。

　　3. 支付转化率应该从18%增加到20％：总转换率不需要增加特别多就已经意味着测试成功了。在这里查看我们的分析报告。

　　III. 解决计划

　　用你能做到的最自然的方式描述你的计划。

　　需要做到清晰、条理清楚、合理分段。

　　根据不同项目的特点，你也可以加入：线框图，用户流程图，表单输入/验证逻辑，数据模型……等执行该计划所需要的所有细节。

　　A. 在线客服提供商

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

　　B. 用户体验

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

　　1. 按钮：设置为“立即聊天”的文案，并且放在详情页中“预订”主按钮的旁边；

　　2. 交互：点击时展示客服姓名，以及“您需要什么帮助？”的文案；

　　3. 所有的支付页面：它应该在所有的三个付款步骤页面上都展示；

　　4. 不自动弹出：我们可以以后再试这个效果，现在先低调上线测试。

　　C. 会话参数

　　1. 这是什么：当我们嵌入服务供应商的 Java 时，我们可以传入特定的参数。这些参数客服可以看得到，并且也会记录在日志和数据报告里。

　　2. 传输这些参数：用户 ID，用户邮箱，浏览器信息，预订 ID，预订订单价格。

　　D. 测试流量开关

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