示例產(chǎn)品文檔

這是一個示例產(chǎn)品文檔，是這篇博客文章的一部分。
說明：

引用格式的文字是我的注釋。
第一次閱讀此文檔時請忽略注釋部分通讀此文，然后再回到文初重新閱讀所有內(nèi)容。
所有的超鏈接并沒有鏈接到任何地方。這篇文章中的外鏈就只是表明有一些待辦事項和相關(guān)文檔。

在支付時增加在線客服

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

這個項目的目標是通過在支付頁面增加在線對話客服來提高支付轉(zhuǎn)化率。這是一個為期 30 天的測試，測試完成后我們可能會上線或者關(guān)掉這個功能（薛定諤的客服？蛤蛤）。

用不超過兩行文字描述此項目。我所說的「行」是指你的客戶端的默認閱讀寬度（例如 Google Docs、維基、文本文件等）。堅持字數(shù)限制是可讀性的關(guān)鍵所在。

概覽

問題

1. 支付轉(zhuǎn)化率過低：只有 18% 的點擊了「預訂」按鈕的用戶完成了支付。競品預訂網(wǎng)站可以達到約 30% 的轉(zhuǎn)化率（數(shù)據(jù)來源）。我們正在失去收入！
2. 沒有明確的流失原因：之前的工單和用戶調(diào)查給出了一系列非常多可能的原因（易用性、支付費用、支付耗時方面的問題），也沒有明確的分類。
3. 增加幫助文檔的內(nèi)容并沒有起到作用：上個季度，我們 對幫助文檔和預定信息的內(nèi)容及界面設計做了 A/B 測試。這只帶來了 1.5% 的轉(zhuǎn)化率輕微提升。

我強烈建議使用列表來增強文檔的可讀性。
使用粗體文字快捷指出每行文字的要點，并且限制列表在兩三行以內(nèi)。
我更喜歡有序列表，因為這樣在口頭溝通時很容易指示清楚。

目標

1. 測試客服聊天是否可以明顯地提高轉(zhuǎn)化率：每天新增超過 90 個訂單就能打平在線客服的運營成本，現(xiàn)在還不清楚是否能做到這一點。這是一次測試！
2. 降低測試成本：避免所有的過度優(yōu)化，如果測試成功，在 Q1 我們就可以優(yōu)化在線聊天的體驗了。
3. 在 12 月 1 日前確定最終的結(jié)果：在開始做 Q1 計劃前，我們還有 8 周時間。

確保文檔可以提出一個明確的目標，這個目標應當是非常容易判斷「達成目標了么？」的。
在文檔中做出明確的承諾。

不應考慮的問題

1. 重要的界面修改：只增加一個可見的聊天按鈕，不做任何其他的設計改動。
2. 確定聊天服務供應商：目前而言先使用 SnapEngage，如果測試成功了，再考慮長期的服務供應商。
3. 國際化和非英語用戶：為了簡化處理，此次測試僅針對美國地區(qū)及其他英語用戶。

這部分用來排除種種不利的假設，樹立正確的項目預期。

團隊成員和角色劃分

1. Heather（用戶運營經(jīng)理）：批準客服資源需求。
2. Randy（用戶運營專員）：負責處理用戶反饋，每周整理反饋總結(jié)。
3. Colin（工程師）：開發(fā)和測試。也要負責配置 SnapEngage，并且給我們展示一下設置方法。
4. Kalpana（財務）：在測試階段以及后續(xù)時間負責評審我的盈利預算。
5. Joha（設計師）：花一點時間看一下我們在設計上的改動，沒有大塊的設計需求。
6. Vikram（數(shù)據(jù)分析師）：確保我們能按時拿到此次測試的數(shù)據(jù)報告。

幫助大家明確項目成員及對每一個人的期望。
僅包括將會執(zhí)行這件事情的人，和對這件事情有通過/否決權(quán)力的人。

需求背景

這里應當包含了解當前問題以及解決方案所需要的所有背景信息。
添加任何你認為應該出現(xiàn)在這里的內(nèi)容，例如：用例、用戶模型、數(shù)據(jù)指標、競品解決方案、調(diào)研結(jié)果等等。

用例

1. 用戶需求：
2. 在 2 分鐘內(nèi)獲得幫助：不確定是否可以實現(xiàn)，但是我們先沖著這個目標去努力吧。
3. 適配移動端及桌面端：有 28% 的支付是在手機上完成的，所以移動端適配很重要。
4. 用戶運營團隊需求：
5. 有反饋隊列的客服后臺：在桌面/web 端就可以，不需要支持移動端
6. 增刪客服人員：可自助完成，而不需要開發(fā)人員支持
7. 設置在線時間：可以控制網(wǎng)站上的在線聊天按鈕是否可見。
8. 查看用戶信息：需要傳遞用戶 ID 的參數(shù)給后臺，方便客服人員查找當前用戶信息。
9. 給會話打標簽：在聊天結(jié)束后，可以在注釋字段中記錄一些非結(jié)構(gòu)化的文本信息。

假設

1. 每天增加90個付費訂單，可以打平一個客服人員的運營成本：根據(jù)每個客服人員的成本以及一個支付用戶的 LTV（生命周期價值）。詳見表格。
2. 一個客服人力可以支持 20% 的支付流量：基于對等待時間、聊天時長、并發(fā)聊天數(shù)量的一系列假設。我們沒有數(shù)據(jù)能支持做出靠譜的假設，所以拍腦袋定一個數(shù)據(jù)，并且需要我們的系統(tǒng)支持快速增加/降低測試流量。
3. 支付轉(zhuǎn)化率應該從18%增加到20％： 總轉(zhuǎn)換率不需要增加特別多就已經(jīng)意味著測試成功了。在這里查看我們的分析報告。

解決方案

用你能做到的最自然的方式描述你的方案。
需要做到清晰、條理清楚、合理分段。
根據(jù)不同項目的特點，你也可以加入： 線框圖，用戶流程圖，表單輸入/驗證邏輯，數(shù)據(jù)模型……等執(zhí)行該計劃所需要的所有細節(jié)。

在線客服供應商

我選擇了 SnapEngage ，符合我們的既定用例并且價格便宜（$60/月）。注：如果測試成功，我們會再選擇適當?shù)墓?。我已經(jīng)注冊了一個付費賬戶，帳號密碼在我們的密碼管理工具中。

用戶體驗

通過 SnapEngage 的文檔 來弄清楚他們這個聊天窗口的彈出邏輯。有以下幾點：

1. 按鈕：設置為「立即聊天」的文案，并且放在詳情頁中「預訂」主按鈕的旁邊
2. 交互：點擊時展示客服姓名，以及「您需要什么幫助？」的文案
3. 所有的支付頁面：它應該在所有的三個付款步驟頁面上都展示。
4. 不自動彈出：我們可以以后再試這個效果，現(xiàn)在先低調(diào)上線測試。

會話參數(shù)

1. 這是什么：當我們嵌入服務供應商的 Javascript 時，我們可以傳入特定的參數(shù)。這些參數(shù)客服可以看得到，并且也會記錄在日志和數(shù)據(jù)報告里。
2. 傳遞這些參數(shù)：用戶 ID，用戶郵箱，瀏覽器信息，預訂 ID，預訂訂單價格。

測試流量開關(guān)

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

1. 只展示給 X％ 的用戶：我們必須能夠在不重新部署的情況下就可以修改 X 的值，但是可以每次修改時都由用戶運營團隊向工程師提交一個工單來人工修改（例如，將這個值存儲在我們的數(shù)據(jù)庫/Redis 中）。
2. 對展示過的用戶始終可見：只要用戶看到過一次這個聊天窗口，在測試期間此用戶就應該始終可以看到這個功能?？梢酝ㄟ^ cookie 來存儲這個狀態(tài)，也可以用這批用戶的用戶 ID 來記錄（例如：如果用戶 ID 對 100 取模小于 X，就可以看到此功能）。
3. 流量遞增方案：第一天，我們只開放 5% 的流量用于測試，如果用戶運營團隊反饋正常，則在第二天開放至 10% 的流量，第三天開放至 20%。

數(shù)據(jù)指標和報告

1. 日志記錄：在現(xiàn)有的指標當中增加："live_checkout=true/false"。
2. 新的數(shù)據(jù)報告：
3. 對比有在線客服的用戶（測試組）和沒有在線客服的用戶（對照組）的支付轉(zhuǎn)化率。
4. 在線客服所帶來的總訂單數(shù)和收入。
5. 測試用戶中有多少人點擊了在線聊天窗口。
6. SnapEngage 的數(shù)據(jù)報告：可以告訴我們平均會話耗時，以及并發(fā)會話數(shù)等數(shù)據(jù)

上面我舉的例子可能晦澀難懂，但是我們團隊中的工程師和數(shù)據(jù)分析師則會很容易理解——因為他們正是這部分文檔的受眾。
記住：寫下所有需要人腦執(zhí)行的必要事項。

未來計劃

1. 如果我們發(fā)現(xiàn)在線聊天的使用率很低：我們需要嘗試一些優(yōu)化方案，例如：（一）自動彈出聊天窗口，（二）修改聊天按鈕樣式，（三）在聊天按鈕旁邊增加客服人員照片。
2. 如果測試驗證成功：我們會爭取更多的客服人力，并且在 Q1 進行大規(guī)模迭代改進，包括選擇合適的供應商，更深入的數(shù)據(jù)分析，以及正式的客服話術(shù)培訓。

指明項目的未來發(fā)展方向永遠都是好事，因為這樣可以引導人們更長遠地去思考。

任務和排期表

考慮到在「未來計劃」中提到的問題，這個排期表可能會有一到兩周的延期。只要我們能夠在 12 月 1 日得到測試結(jié)果，我們就在 Q1 人力資源規(guī)劃時爭取到更多的人力。

1. 10 月 4 日：文檔評審。
2. 10 月 8 日：和客服團隊一起在開發(fā)環(huán)境中測試如何設置客服人員以及客服時間。
3. 10 月 11 日：上線。我們會在接下來的數(shù)天中逐步增加測試流量。
4. 10 月 17 日：在上線1周后同步信息。在此時我們可能會有一些額外的工作要做。
5. 11 月 12 日：最后一次溝通，評審當下狀態(tài)以決定繼續(xù)推進還是結(jié)束此項目。
6. 12 月 1 日：這是完成此項目并且得到測試結(jié)果的最終截止日。

開始的時候排期表可以只有一個大致的估期，通過更多的分析來逐步精確時間點（例如需要技術(shù)文檔）。
但是盡早嘗試拆解和確定時間點，大致框定每項工作的范圍和規(guī)模仍然是非常重要的。
工期估算應當來自于 執(zhí)行方（開發(fā)，設計等）。