編輯導(dǎo)語：產(chǎn)品上線后，總會(huì)有各種各樣的問題出現(xiàn)。如何快速、高效的解決問題，關(guān)系到用戶的滿意度。對(duì)于一個(gè)產(chǎn)品而言，非常重要。通過這篇文章，希望你能獲得問題處理的一些基本原則和技巧。

產(chǎn)品經(jīng)理在日常工作中經(jīng)常會(huì)遇到被用戶問題打擾的情況，解答用戶疑問作為日常工作項(xiàng)之一常常讓產(chǎn)品經(jīng)理很頭疼，用戶提問時(shí)間不固定，有的時(shí)候很簡單的問題會(huì)打斷別的工作事項(xiàng)進(jìn)度，但是用戶疑問有時(shí)候響應(yīng)不及時(shí)又可能造成更大損失。所以處理用戶問題的方法和節(jié)奏就成了產(chǎn)品經(jīng)理的必修課，用戶問題處理好了諸事順?biāo)?，處理不好麻煩一堆。今天我們就來聊聊處理用戶問題的一些關(guān)鍵事項(xiàng)。

一、設(shè)置用戶提問渠道

首先應(yīng)該明確，處理用戶問題是產(chǎn)品經(jīng)理在產(chǎn)品運(yùn)營部分需要承擔(dān)的相關(guān)責(zé)任，而產(chǎn)品運(yùn)營不應(yīng)當(dāng)是產(chǎn)品經(jīng)理核心工作，所以日常工作主線中是不應(yīng)該出現(xiàn)處理問題這種事情的，應(yīng)該把解答用戶提問設(shè)定為一個(gè)被動(dòng)事項(xiàng)。

正常情況下，產(chǎn)品運(yùn)營是有專門的運(yùn)營人員去做的，一般情況的處理和承接都應(yīng)該有產(chǎn)品運(yùn)營人員去做，只有在產(chǎn)品運(yùn)營也解決不了的時(shí)候才會(huì)反饋到產(chǎn)品經(jīng)理這里。但是也有很多公司是沒有設(shè)置產(chǎn)品運(yùn)營崗位的，產(chǎn)品經(jīng)理本身就是唯一的產(chǎn)品運(yùn)營人員，公司考慮產(chǎn)品使用人數(shù)，使用頻次，投入產(chǎn)出比等因素，這種做法本身也是可以理解的，但是產(chǎn)品經(jīng)理自身不能任由自己的時(shí)間大量消耗在這個(gè)地方。

所以就應(yīng)當(dāng)為用戶設(shè)置好一系列解決問題的合理路徑：

1. 幫助入口

在產(chǎn)品頁面中應(yīng)當(dāng)能找到使用說明之類的基本介紹內(nèi)容入口，要能支撐用戶自己按圖索驥解決自己遇到的問題。

2. 創(chuàng)建用戶群

在產(chǎn)品幫助頁留下群號(hào)或者群二維碼，在群里公告或置頂處放置產(chǎn)品使用說明和常見問題說明，并告訴用戶如果看說明后問題依然無法解決再聯(lián)系產(chǎn)品經(jīng)理，在群內(nèi)把相關(guān)產(chǎn)品經(jīng)理設(shè)為管理員方便用戶找到。

3. 用戶留言

明確告知用戶先通過辦公溝通軟件留言，產(chǎn)品經(jīng)理會(huì)在某個(gè)時(shí)間集中統(tǒng)一處理留言，這樣產(chǎn)品經(jīng)理的其他工作事項(xiàng)也不會(huì)被打斷。

4. 急事電聯(lián)

考慮到用戶可能會(huì)有十分緊急的事項(xiàng)，還可以在辦公溝通軟件上設(shè)置一條自動(dòng)回復(fù)，告訴用戶如果事項(xiàng)緊急可以打電話聯(lián)系。

有了這樣一套完整的用戶問題解決路徑，至少可以給到用戶一個(gè)自行解決問題的方式，不至于遇到問題就束手無策，同時(shí)也避免了絕大多數(shù)不重要不緊急的問題突然打斷產(chǎn)品經(jīng)理手頭的工作，影響工作進(jìn)程。

二、撰寫產(chǎn)品幫助文檔

前面提到，用戶在遇到問題的第一時(shí)間應(yīng)該先通過自己查找資料的方式解決，這對(duì)用戶和產(chǎn)品經(jīng)理來說都是最節(jié)省時(shí)間的方法，這就要求產(chǎn)品經(jīng)理要提前準(zhǔn)備好相關(guān)資料以供用戶查看。

1. 產(chǎn)品手冊(cè)

產(chǎn)品手冊(cè)是產(chǎn)品經(jīng)理對(duì)外提供的最全面的產(chǎn)品解釋說明內(nèi)容，應(yīng)當(dāng)涵蓋產(chǎn)品整體框架介紹，產(chǎn)品功能闡釋說明，產(chǎn)品中涉及的名詞解釋等等，要盡可能具體地把產(chǎn)品介紹清楚。

2. 操作手冊(cè)

區(qū)別于產(chǎn)品手冊(cè)的全面性和系統(tǒng)性，操作手冊(cè)更多地是從用戶使用角度出發(fā)來寫的一份指導(dǎo)性文檔，是針對(duì)用戶想要做的事情，給出的具體操作步驟。操作手冊(cè)應(yīng)當(dāng)能夠覆蓋到用戶日常在產(chǎn)品中要處理的各種事項(xiàng)，在用戶看來這應(yīng)當(dāng)是一份清晰的指引說明，而不是像產(chǎn)品手冊(cè)那樣是詳細(xì)的介紹說明。

3. 常見問題答疑手冊(cè)

有些時(shí)候產(chǎn)品本身是沒有問題的，但是因?yàn)榇蠹艺J(rèn)知不同，或者操作習(xí)慣不同，對(duì)一些名詞的理解不一致會(huì)導(dǎo)致用戶在有指引的情況下還是無法正常操作。產(chǎn)品經(jīng)理應(yīng)當(dāng)總結(jié)類似的問題做進(jìn)一步的解釋說明，幫助用戶處理一些非產(chǎn)品問題導(dǎo)致的使用障礙。

4. 使用延伸手冊(cè)

產(chǎn)品中的很多功能是有隱藏屬性的，就是它表面可能是用來解決A問題的，但其實(shí)通過變通或者跟其他功能組合的形式也可以用來解決B問題，這種情況一般用戶是很難發(fā)現(xiàn)的，也需要產(chǎn)品經(jīng)理單獨(dú)說明。產(chǎn)品使用延伸可以邀請(qǐng)產(chǎn)品運(yùn)營和產(chǎn)品用戶來一起創(chuàng)作，一份好的延伸手冊(cè)可以讓產(chǎn)品覆蓋到更多的使用場景，擴(kuò)寬產(chǎn)品的市場。

產(chǎn)品幫助文檔像是產(chǎn)品經(jīng)理與用戶溝通的觸手，可以讓用戶更好地了解產(chǎn)品，更好地使用產(chǎn)品，所以產(chǎn)品經(jīng)理一定要重視產(chǎn)品文檔的設(shè)置，這個(gè)工作可以幫助產(chǎn)品經(jīng)理在后期節(jié)省很多跟用戶重復(fù)溝通的時(shí)間成本。

三、創(chuàng)建用戶問題清單

即便前面準(zhǔn)備了充分的幫助文檔，也還是會(huì)有很多問題會(huì)流轉(zhuǎn)到產(chǎn)品經(jīng)理手上，這是很正常的現(xiàn)象，處理用戶問題本來也是產(chǎn)品經(jīng)理工作的一部分，我們前面準(zhǔn)備那么多幫助文檔，也不是為了阻斷用戶提問，而是希望用戶能在不需要溝通協(xié)助的情況下就自己解決掉問題，解不掉那肯定還是要找產(chǎn)品經(jīng)理解決的。面對(duì)眾多的問題產(chǎn)品經(jīng)理也應(yīng)該創(chuàng)建一張用來跟蹤用戶問題的表格。

創(chuàng)建用戶問題跟蹤表的好處有很多，一方面可以根據(jù)表頭內(nèi)容提示更全面地了解問題的相關(guān)信息。另一方面對(duì)于現(xiàn)場未解決的問題也方便做進(jìn)一步跟蹤，此外還可以定期回顧根據(jù)表格內(nèi)容持續(xù)改進(jìn)產(chǎn)品。下面我們來結(jié)合用戶問題跟蹤表具體字段來分享一下它的具體用法。

1. 創(chuàng)建時(shí)間

記錄首次發(fā)現(xiàn)問題的時(shí)間，方便后期結(jié)合時(shí)間確定解決問題的緊急程度。

2. 提問人

記錄問題是誰提出的，方便后期需要了解更多細(xì)節(jié)時(shí)找到具體的人員，或者問題解決后能夠及時(shí)通知到用戶。

3. 歸屬系統(tǒng)

一般一個(gè)產(chǎn)品經(jīng)理不會(huì)只負(fù)責(zé)一個(gè)產(chǎn)品，而且這種問題跟蹤表很可能還是部門共用的，所以記錄系統(tǒng)就很有必要了。

4. 操作環(huán)境

是測試環(huán)境還是正式的線上環(huán)境，根據(jù)本公司產(chǎn)品部署的環(huán)境做具體的設(shè)置。

5. 瀏覽器

用戶用什么瀏覽器使用系統(tǒng)時(shí)出現(xiàn)的問題，記錄時(shí)需要詳細(xì)到版本，方便開發(fā)排查問題時(shí)及時(shí)排除掉相關(guān)因素影響。同時(shí)復(fù)現(xiàn)問題時(shí)也可能會(huì)用到這個(gè)信息。

6. 問題概述

一句話簡短描述問題的主要內(nèi)容，方便后期翻閱時(shí)可以快速定位到具體問題。

7. 問題詳情

補(bǔ)充問題的更多細(xì)節(jié)內(nèi)容，記錄問題發(fā)生的具體情景，方便后續(xù)復(fù)現(xiàn)問題或解決問題時(shí)參考。

8. 問題歸類

可以預(yù)先為常見問題設(shè)定幾種類型，比如操作問題、性能問題、功能問題、界面問題、產(chǎn)品BUG等，后期可以根據(jù)問題類型做不同處理。

9. 記錄人

一般就是產(chǎn)品經(jīng)理自己，如果是團(tuán)隊(duì)共用一張表的話，可以用來定位是誰對(duì)接到這個(gè)問題的。

10. 解決人

誰對(duì)解決這個(gè)問題負(fù)責(zé)，一般也是產(chǎn)品經(jīng)理自己，但也有時(shí)候需要開發(fā)同事介入，記錄解決人可以方便跟蹤后續(xù)解決進(jìn)度。

11. 問題原因

由解決人定位出問題產(chǎn)生原因，可以方便排查類似原因有沒有可能導(dǎo)致更多問題，也可以結(jié)合原因劃分問題歸類。

12. 解決方案

說明問題最終怎么解決的，方便后期遇到類似問題時(shí)參考，也可以根據(jù)解決方案確定進(jìn)一步推進(jìn)策略。

13. 解決進(jìn)度

可以直接提供三個(gè)選項(xiàng)，已解決、處理中、待分配，后期可根據(jù)解決進(jìn)度確定是否繼續(xù)跟蹤。

14. 用戶驗(yàn)收

問題解決后需要聯(lián)系用戶驗(yàn)收解決結(jié)果，看用戶是否對(duì)解決結(jié)果滿意。根據(jù)驗(yàn)收反饋及時(shí)調(diào)整，直到用戶滿意。

此外還可以結(jié)合公司實(shí)際情況以及產(chǎn)品實(shí)際情況設(shè)定諸如緊急程度、是否必現(xiàn)、影響范圍、用戶ID、處理排期、完成時(shí)間等等，只要你認(rèn)為這個(gè)在問題的處理過程中或者事后跟蹤過程中是需要用到的，那就都可以考慮放到你的跟蹤表中。

一份好的用戶問題跟蹤表是可以直接跟用戶需求統(tǒng)計(jì)表完成對(duì)接的，有些用戶的問題屬于產(chǎn)品功能屬性的問題，那就可以直接從問題池升級(jí)到需求池。還有些問題可能是用戶不會(huì)操作導(dǎo)致的，那就可以排查一下幫助文檔中這個(gè)部分是不是有缺失，并將內(nèi)容補(bǔ)充到對(duì)應(yīng)的地方。

從問題跟蹤表的字段設(shè)置也可以看出，我們遵循的原則就是問題從用戶那里來，最后一定要再回到用戶那里去，最終形成一個(gè)解決問題的閉環(huán)，只有用戶說這個(gè)問題解決了那才算是真正解決了，產(chǎn)品工作最忌諱的就是自嗨，一定要聽用戶的聲音，了解用戶的真實(shí)反饋。而解決用戶問題就是一個(gè)很好地聽用戶聲音的機(jī)會(huì)，各位產(chǎn)品經(jīng)理一定要用好這個(gè)機(jī)會(huì)。

四、梳理問題跟蹤流程

作為一個(gè)常規(guī)事項(xiàng)，而且又是具有突發(fā)性質(zhì)的事項(xiàng)，如果沒有成體系的應(yīng)對(duì)策略的話，往往會(huì)造成處理問題時(shí)考慮不到位留下隱患，或者問題解決不徹底造成用戶持續(xù)反饋消耗更多時(shí)間，又或者因?yàn)闆]有清晰的流程在處理問題時(shí)手忙腳亂也會(huì)浪費(fèi)很多時(shí)間。所以我們就在今天的最后一個(gè)部分來分享一下，如果最后問題還是給到產(chǎn)品經(jīng)理這邊的話，我們應(yīng)該如何正確地應(yīng)對(duì)和處理，該有哪些比較規(guī)范的處理流程。

1. 確認(rèn)場景

跟用戶確認(rèn)問題發(fā)生的具體場景，包括所屬環(huán)境、發(fā)生問題的系統(tǒng)、操作賬號(hào)、在進(jìn)行的操作、涉及的任務(wù)或表、報(bào)錯(cuò)提示以及所產(chǎn)生的影響等。場景越具體越有利于后續(xù)問題復(fù)現(xiàn)及定位解決。

2. 復(fù)現(xiàn)問題

根據(jù)用戶提供的問題發(fā)生場景嘗試在本地復(fù)現(xiàn)，以此來確認(rèn)是系統(tǒng)中的共性問題還是用戶那邊的偶發(fā)性問題。如果產(chǎn)品經(jīng)理自己無法完成復(fù)現(xiàn)，可以邀請(qǐng)測試人員來共同完成，有時(shí)候測試人員對(duì)一些特殊場景的把控會(huì)比產(chǎn)品經(jīng)理更細(xì)致一些。

3. 排除操作原因

在了解問題發(fā)生場景和復(fù)現(xiàn)問題的過程中，首先要確認(rèn)問題是不是由于用戶錯(cuò)誤操作導(dǎo)致。如果是操作錯(cuò)誤就進(jìn)一步看這個(gè)操作我們是否有在前面的幫助文檔中寫到相關(guān)的內(nèi)容，寫了就讓用戶再去看，沒寫就要把相關(guān)內(nèi)容補(bǔ)充到文檔中。如果不是操作錯(cuò)誤就再往下排查其他問題。

4. 問題建檔

將問題的相關(guān)信息維護(hù)到用戶問題跟蹤清單中，并在后續(xù)跟蹤中逐步完善跟蹤表中的相關(guān)內(nèi)容，也可以根據(jù)用戶問題跟蹤表中的相關(guān)字段來梳理待辦事項(xiàng)。

5. 排除功能性問題

排除用戶操作錯(cuò)誤導(dǎo)致的問題后，產(chǎn)品經(jīng)理首先應(yīng)該排查一下問題是不是由于產(chǎn)品本身的功能缺失或者功能設(shè)置不合理等原因?qū)е碌模绻枪δ苄詥栴}，可以進(jìn)一步判斷是否有必要新增或調(diào)整功能，并將相關(guān)結(jié)論和計(jì)劃告知用戶。

6. 找前端定位

產(chǎn)品排除用戶操作問題和功能性問題后還沒能解決的話，就要找前端看一下是不是前端頁面的問題導(dǎo)致的，前端問題排查起來相對(duì)比較簡單，解決也會(huì)相對(duì)更快一些，所以技術(shù)排查的時(shí)候往往會(huì)先從前端開始排查。

7. 找后端定位

前端排查完以后還沒解決就得找后端來看了，根據(jù)問題發(fā)生時(shí)的具體場景，或者問題發(fā)生時(shí)的日志記錄等來確定問題發(fā)生的具體原因。如果是不需要發(fā)布就能解決的問題就直接解掉，如果會(huì)涉及到發(fā)布才可以解決的就走Bug修復(fù)流程。

8. 找測試提交Bug單

確認(rèn)需要走Bug流程以后找測試人員提交Bug單，后續(xù)的發(fā)布流程中會(huì)關(guān)聯(lián)到。

9. 排查相關(guān)影響

開發(fā)明確問題原因后，產(chǎn)品需要進(jìn)一步排查這個(gè)原因是不是還會(huì)導(dǎo)致其他相關(guān)問題出現(xiàn)，以及有沒有類似問題存在的隱患，如果有的話也要一并解決掉。

10. 明確解決方案

經(jīng)過各方排查以后，根據(jù)大家的反饋確定相關(guān)的問題的明確解決方案，并請(qǐng)前后端開發(fā)及上下游等各相關(guān)方評(píng)估方案可行性及合理性，排除可能造成的其他影響。

11. 做好變更文檔

方案評(píng)審?fù)ㄟ^后將涉及到產(chǎn)品調(diào)整的內(nèi)容維護(hù)到產(chǎn)品功能需求文檔中，確保需求文檔與線上產(chǎn)品保持一致，方便后期查看。

12. 修改上線

Bug修復(fù)后要按照正常的流程安排測試，測試確認(rèn)無誤后發(fā)布上線，上線成功產(chǎn)品經(jīng)理需要在線上版本進(jìn)行驗(yàn)收，確保問題已經(jīng)解決。

13. 同步用戶

問題解決后，將問題解決結(jié)果同步給提出問題的用戶，邀請(qǐng)用戶重新試用相關(guān)功能，來確認(rèn)相關(guān)問題是否已經(jīng)得到解決。

14. 接收反饋

主動(dòng)找用戶獲取試用反饋，反饋已解決，整個(gè)問題處理流程結(jié)束。反饋還有問題再進(jìn)入問題處理流程進(jìn)一步跟蹤處理。

上面這個(gè)流程不同的產(chǎn)品或者不同的團(tuán)隊(duì)，可以根據(jù)自己的產(chǎn)品特性和團(tuán)隊(duì)習(xí)慣做相應(yīng)的調(diào)整，把問題解決，得到用戶認(rèn)可這個(gè)最核心的事情解決就可以。

五、總結(jié)

最后來回顧一下，用戶問題的解決應(yīng)該是在用戶發(fā)現(xiàn)問題之前就開始準(zhǔn)備的，所以我們最開始要給用戶設(shè)置合理的自己解決問題的路徑；而用戶自己解決問題的時(shí)候又必然要用到一系列產(chǎn)品幫助文檔，產(chǎn)品經(jīng)理要提前準(zhǔn)備；問題最終還是回到產(chǎn)品手上，產(chǎn)品要有對(duì)問題整體把控和跟蹤，所以就需要用到用戶問題清單；具體的問題解決過程又需要有一個(gè)相對(duì)標(biāo)準(zhǔn)的流程去指導(dǎo)問題的解決，可以幫助產(chǎn)品經(jīng)理有一個(gè)清晰的解決問題思路。

只要按照這一整套邏輯去處理用戶問題，基本可以覆蓋80%以上的場景，希望能夠?qū)Υ蠹业墓ぷ饔兴鶐椭?，大家如果還有其他需要補(bǔ)充或者辯證的點(diǎn)，也可以一起探討。

本文由 @多云轉(zhuǎn)晴，原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。