錦囊:學會這些方法,再也不擔心處理不好用戶問題
編輯導語:產(chǎn)品上線后,總會有各種各樣的問題出現(xiàn)。如何快速、高效的解決問題,關系到用戶的滿意度。對于一個產(chǎn)品而言,非常重要。通過這篇文章,希望你能獲得問題處理的一些基本原則和技巧。
產(chǎn)品經(jīng)理在日常工作中經(jīng)常會遇到被用戶問題打擾的情況,解答用戶疑問作為日常工作項之一常常讓產(chǎn)品經(jīng)理很頭疼,用戶提問時間不固定,有的時候很簡單的問題會打斷別的工作事項進度,但是用戶疑問有時候響應不及時又可能造成更大損失。所以處理用戶問題的方法和節(jié)奏就成了產(chǎn)品經(jīng)理的必修課,用戶問題處理好了諸事順遂,處理不好麻煩一堆。今天我們就來聊聊處理用戶問題的一些關鍵事項。
一、設置用戶提問渠道
首先應該明確,處理用戶問題是產(chǎn)品經(jīng)理在產(chǎn)品運營部分需要承擔的相關責任,而產(chǎn)品運營不應當是產(chǎn)品經(jīng)理核心工作,所以日常工作主線中是不應該出現(xiàn)處理問題這種事情的,應該把解答用戶提問設定為一個被動事項。
正常情況下,產(chǎn)品運營是有專門的運營人員去做的,一般情況的處理和承接都應該有產(chǎn)品運營人員去做,只有在產(chǎn)品運營也解決不了的時候才會反饋到產(chǎn)品經(jīng)理這里。但是也有很多公司是沒有設置產(chǎn)品運營崗位的,產(chǎn)品經(jīng)理本身就是唯一的產(chǎn)品運營人員,公司考慮產(chǎn)品使用人數(shù),使用頻次,投入產(chǎn)出比等因素,這種做法本身也是可以理解的,但是產(chǎn)品經(jīng)理自身不能任由自己的時間大量消耗在這個地方。
所以就應當為用戶設置好一系列解決問題的合理路徑:
1. 幫助入口
在產(chǎn)品頁面中應當能找到使用說明之類的基本介紹內容入口,要能支撐用戶自己按圖索驥解決自己遇到的問題。
2. 創(chuàng)建用戶群
在產(chǎn)品幫助頁留下群號或者群二維碼,在群里公告或置頂處放置產(chǎn)品使用說明和常見問題說明,并告訴用戶如果看說明后問題依然無法解決再聯(lián)系產(chǎn)品經(jīng)理,在群內把相關產(chǎn)品經(jīng)理設為管理員方便用戶找到。
3. 用戶留言
明確告知用戶先通過辦公溝通軟件留言,產(chǎn)品經(jīng)理會在某個時間集中統(tǒng)一處理留言,這樣產(chǎn)品經(jīng)理的其他工作事項也不會被打斷。
4. 急事電聯(lián)
考慮到用戶可能會有十分緊急的事項,還可以在辦公溝通軟件上設置一條自動回復,告訴用戶如果事項緊急可以打電話聯(lián)系。
有了這樣一套完整的用戶問題解決路徑,至少可以給到用戶一個自行解決問題的方式,不至于遇到問題就束手無策,同時也避免了絕大多數(shù)不重要不緊急的問題突然打斷產(chǎn)品經(jīng)理手頭的工作,影響工作進程。
二、撰寫產(chǎn)品幫助文檔
前面提到,用戶在遇到問題的第一時間應該先通過自己查找資料的方式解決,這對用戶和產(chǎn)品經(jīng)理來說都是最節(jié)省時間的方法,這就要求產(chǎn)品經(jīng)理要提前準備好相關資料以供用戶查看。
1. 產(chǎn)品手冊
產(chǎn)品手冊是產(chǎn)品經(jīng)理對外提供的最全面的產(chǎn)品解釋說明內容,應當涵蓋產(chǎn)品整體框架介紹,產(chǎn)品功能闡釋說明,產(chǎn)品中涉及的名詞解釋等等,要盡可能具體地把產(chǎn)品介紹清楚。
2. 操作手冊
區(qū)別于產(chǎn)品手冊的全面性和系統(tǒng)性,操作手冊更多地是從用戶使用角度出發(fā)來寫的一份指導性文檔,是針對用戶想要做的事情,給出的具體操作步驟。操作手冊應當能夠覆蓋到用戶日常在產(chǎn)品中要處理的各種事項,在用戶看來這應當是一份清晰的指引說明,而不是像產(chǎn)品手冊那樣是詳細的介紹說明。
3. 常見問題答疑手冊
有些時候產(chǎn)品本身是沒有問題的,但是因為大家認知不同,或者操作習慣不同,對一些名詞的理解不一致會導致用戶在有指引的情況下還是無法正常操作。產(chǎn)品經(jīng)理應當總結類似的問題做進一步的解釋說明,幫助用戶處理一些非產(chǎn)品問題導致的使用障礙。
4. 使用延伸手冊
產(chǎn)品中的很多功能是有隱藏屬性的,就是它表面可能是用來解決A問題的,但其實通過變通或者跟其他功能組合的形式也可以用來解決B問題,這種情況一般用戶是很難發(fā)現(xiàn)的,也需要產(chǎn)品經(jīng)理單獨說明。產(chǎn)品使用延伸可以邀請產(chǎn)品運營和產(chǎn)品用戶來一起創(chuàng)作,一份好的延伸手冊可以讓產(chǎn)品覆蓋到更多的使用場景,擴寬產(chǎn)品的市場。
產(chǎn)品幫助文檔像是產(chǎn)品經(jīng)理與用戶溝通的觸手,可以讓用戶更好地了解產(chǎn)品,更好地使用產(chǎn)品,所以產(chǎn)品經(jīng)理一定要重視產(chǎn)品文檔的設置,這個工作可以幫助產(chǎn)品經(jīng)理在后期節(jié)省很多跟用戶重復溝通的時間成本。
三、創(chuàng)建用戶問題清單
即便前面準備了充分的幫助文檔,也還是會有很多問題會流轉到產(chǎn)品經(jīng)理手上,這是很正常的現(xiàn)象,處理用戶問題本來也是產(chǎn)品經(jīng)理工作的一部分,我們前面準備那么多幫助文檔,也不是為了阻斷用戶提問,而是希望用戶能在不需要溝通協(xié)助的情況下就自己解決掉問題,解不掉那肯定還是要找產(chǎn)品經(jīng)理解決的。面對眾多的問題產(chǎn)品經(jīng)理也應該創(chuàng)建一張用來跟蹤用戶問題的表格。
創(chuàng)建用戶問題跟蹤表的好處有很多,一方面可以根據(jù)表頭內容提示更全面地了解問題的相關信息。另一方面對于現(xiàn)場未解決的問題也方便做進一步跟蹤,此外還可以定期回顧根據(jù)表格內容持續(xù)改進產(chǎn)品。下面我們來結合用戶問題跟蹤表具體字段來分享一下它的具體用法。
1. 創(chuàng)建時間
記錄首次發(fā)現(xiàn)問題的時間,方便后期結合時間確定解決問題的緊急程度。
2. 提問人
記錄問題是誰提出的,方便后期需要了解更多細節(jié)時找到具體的人員,或者問題解決后能夠及時通知到用戶。
3. 歸屬系統(tǒng)
一般一個產(chǎn)品經(jīng)理不會只負責一個產(chǎn)品,而且這種問題跟蹤表很可能還是部門共用的,所以記錄系統(tǒng)就很有必要了。
4. 操作環(huán)境
是測試環(huán)境還是正式的線上環(huán)境,根據(jù)本公司產(chǎn)品部署的環(huán)境做具體的設置。
5. 瀏覽器
用戶用什么瀏覽器使用系統(tǒng)時出現(xiàn)的問題,記錄時需要詳細到版本,方便開發(fā)排查問題時及時排除掉相關因素影響。同時復現(xiàn)問題時也可能會用到這個信息。
6. 問題概述
一句話簡短描述問題的主要內容,方便后期翻閱時可以快速定位到具體問題。
7. 問題詳情
補充問題的更多細節(jié)內容,記錄問題發(fā)生的具體情景,方便后續(xù)復現(xiàn)問題或解決問題時參考。
8. 問題歸類
可以預先為常見問題設定幾種類型,比如操作問題、性能問題、功能問題、界面問題、產(chǎn)品BUG等,后期可以根據(jù)問題類型做不同處理。
9. 記錄人
一般就是產(chǎn)品經(jīng)理自己,如果是團隊共用一張表的話,可以用來定位是誰對接到這個問題的。
10. 解決人
誰對解決這個問題負責,一般也是產(chǎn)品經(jīng)理自己,但也有時候需要開發(fā)同事介入,記錄解決人可以方便跟蹤后續(xù)解決進度。
11. 問題原因
由解決人定位出問題產(chǎn)生原因,可以方便排查類似原因有沒有可能導致更多問題,也可以結合原因劃分問題歸類。
12. 解決方案
說明問題最終怎么解決的,方便后期遇到類似問題時參考,也可以根據(jù)解決方案確定進一步推進策略。
13. 解決進度
可以直接提供三個選項,已解決、處理中、待分配,后期可根據(jù)解決進度確定是否繼續(xù)跟蹤。
14. 用戶驗收
問題解決后需要聯(lián)系用戶驗收解決結果,看用戶是否對解決結果滿意。根據(jù)驗收反饋及時調整,直到用戶滿意。
此外還可以結合公司實際情況以及產(chǎn)品實際情況設定諸如緊急程度、是否必現(xiàn)、影響范圍、用戶ID、處理排期、完成時間等等,只要你認為這個在問題的處理過程中或者事后跟蹤過程中是需要用到的,那就都可以考慮放到你的跟蹤表中。
一份好的用戶問題跟蹤表是可以直接跟用戶需求統(tǒng)計表完成對接的,有些用戶的問題屬于產(chǎn)品功能屬性的問題,那就可以直接從問題池升級到需求池。還有些問題可能是用戶不會操作導致的,那就可以排查一下幫助文檔中這個部分是不是有缺失,并將內容補充到對應的地方。
從問題跟蹤表的字段設置也可以看出,我們遵循的原則就是問題從用戶那里來,最后一定要再回到用戶那里去,最終形成一個解決問題的閉環(huán),只有用戶說這個問題解決了那才算是真正解決了,產(chǎn)品工作最忌諱的就是自嗨,一定要聽用戶的聲音,了解用戶的真實反饋。而解決用戶問題就是一個很好地聽用戶聲音的機會,各位產(chǎn)品經(jīng)理一定要用好這個機會。
四、梳理問題跟蹤流程
作為一個常規(guī)事項,而且又是具有突發(fā)性質的事項,如果沒有成體系的應對策略的話,往往會造成處理問題時考慮不到位留下隱患,或者問題解決不徹底造成用戶持續(xù)反饋消耗更多時間,又或者因為沒有清晰的流程在處理問題時手忙腳亂也會浪費很多時間。所以我們就在今天的最后一個部分來分享一下,如果最后問題還是給到產(chǎn)品經(jīng)理這邊的話,我們應該如何正確地應對和處理,該有哪些比較規(guī)范的處理流程。
1. 確認場景
跟用戶確認問題發(fā)生的具體場景,包括所屬環(huán)境、發(fā)生問題的系統(tǒng)、操作賬號、在進行的操作、涉及的任務或表、報錯提示以及所產(chǎn)生的影響等。場景越具體越有利于后續(xù)問題復現(xiàn)及定位解決。
2. 復現(xiàn)問題
根據(jù)用戶提供的問題發(fā)生場景嘗試在本地復現(xiàn),以此來確認是系統(tǒng)中的共性問題還是用戶那邊的偶發(fā)性問題。如果產(chǎn)品經(jīng)理自己無法完成復現(xiàn),可以邀請測試人員來共同完成,有時候測試人員對一些特殊場景的把控會比產(chǎn)品經(jīng)理更細致一些。
3. 排除操作原因
在了解問題發(fā)生場景和復現(xiàn)問題的過程中,首先要確認問題是不是由于用戶錯誤操作導致。如果是操作錯誤就進一步看這個操作我們是否有在前面的幫助文檔中寫到相關的內容,寫了就讓用戶再去看,沒寫就要把相關內容補充到文檔中。如果不是操作錯誤就再往下排查其他問題。
4. 問題建檔
將問題的相關信息維護到用戶問題跟蹤清單中,并在后續(xù)跟蹤中逐步完善跟蹤表中的相關內容,也可以根據(jù)用戶問題跟蹤表中的相關字段來梳理待辦事項。
5. 排除功能性問題
排除用戶操作錯誤導致的問題后,產(chǎn)品經(jīng)理首先應該排查一下問題是不是由于產(chǎn)品本身的功能缺失或者功能設置不合理等原因導致的,如果是功能性問題,可以進一步判斷是否有必要新增或調整功能,并將相關結論和計劃告知用戶。
6. 找前端定位
產(chǎn)品排除用戶操作問題和功能性問題后還沒能解決的話,就要找前端看一下是不是前端頁面的問題導致的,前端問題排查起來相對比較簡單,解決也會相對更快一些,所以技術排查的時候往往會先從前端開始排查。
7. 找后端定位
前端排查完以后還沒解決就得找后端來看了,根據(jù)問題發(fā)生時的具體場景,或者問題發(fā)生時的日志記錄等來確定問題發(fā)生的具體原因。如果是不需要發(fā)布就能解決的問題就直接解掉,如果會涉及到發(fā)布才可以解決的就走Bug修復流程。
8. 找測試提交Bug單
確認需要走Bug流程以后找測試人員提交Bug單,后續(xù)的發(fā)布流程中會關聯(lián)到。
9. 排查相關影響
開發(fā)明確問題原因后,產(chǎn)品需要進一步排查這個原因是不是還會導致其他相關問題出現(xiàn),以及有沒有類似問題存在的隱患,如果有的話也要一并解決掉。
10. 明確解決方案
經(jīng)過各方排查以后,根據(jù)大家的反饋確定相關的問題的明確解決方案,并請前后端開發(fā)及上下游等各相關方評估方案可行性及合理性,排除可能造成的其他影響。
11. 做好變更文檔
方案評審通過后將涉及到產(chǎn)品調整的內容維護到產(chǎn)品功能需求文檔中,確保需求文檔與線上產(chǎn)品保持一致,方便后期查看。
12. 修改上線
Bug修復后要按照正常的流程安排測試,測試確認無誤后發(fā)布上線,上線成功產(chǎn)品經(jīng)理需要在線上版本進行驗收,確保問題已經(jīng)解決。
13. 同步用戶
問題解決后,將問題解決結果同步給提出問題的用戶,邀請用戶重新試用相關功能,來確認相關問題是否已經(jīng)得到解決。
14. 接收反饋
主動找用戶獲取試用反饋,反饋已解決,整個問題處理流程結束。反饋還有問題再進入問題處理流程進一步跟蹤處理。
上面這個流程不同的產(chǎn)品或者不同的團隊,可以根據(jù)自己的產(chǎn)品特性和團隊習慣做相應的調整,把問題解決,得到用戶認可這個最核心的事情解決就可以。
五、總結
最后來回顧一下,用戶問題的解決應該是在用戶發(fā)現(xiàn)問題之前就開始準備的,所以我們最開始要給用戶設置合理的自己解決問題的路徑;而用戶自己解決問題的時候又必然要用到一系列產(chǎn)品幫助文檔,產(chǎn)品經(jīng)理要提前準備;問題最終還是回到產(chǎn)品手上,產(chǎn)品要有對問題整體把控和跟蹤,所以就需要用到用戶問題清單;具體的問題解決過程又需要有一個相對標準的流程去指導問題的解決,可以幫助產(chǎn)品經(jīng)理有一個清晰的解決問題思路。
只要按照這一整套邏輯去處理用戶問題,基本可以覆蓋80%以上的場景,希望能夠對大家的工作有所幫助,大家如果還有其他需要補充或者辯證的點,也可以一起探討。
本文由 @多云轉晴,原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉載。
題圖來自Unsplash,基于CC0協(xié)議。
要站在客戶的角度去思考問題,才能真正想明白客戶需要的是啥。