起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識用戶反饋的問題如何高效處理好？
編輯導讀：用戶在使用產品后，某些需求沒有辦法被滿足，就會找平臺反饋。而平臺需要做的，就是安撫好用戶的情緒并及時對問題進行解決。本文作者以B端產品為例，圍繞“如何高效處理用戶反饋問題”展開四個維度的分析，希望對你有幫助。
著名的產品人俞軍在自己的《俞軍產品方法論》一書中提到“產品即媒介，公司只是通過產品這個媒介向用戶傳遞可交易的價值”，所以當一個需求產生之后，實際是向用戶獲取交易價值，用戶在愿意交易的情況下，對于這個收益是超出自己所付出的成本，這里的成本包括“直接的金錢、還有間接的時間等等”，用戶才會愿意交易。
那這里談到的用戶反饋問題，其實從某種角度來說，用戶已經使用過你的產品，且用戶覺得自己付出了一定的交易成本，但是卻得不到滿足，并且在找平臺反饋時（反饋的成本要小于自己的收益，或者預期收益較大時才會堅持找到你反饋）已經有心里預期。
反饋問題的渠道有很多種，有些平臺特別重視用戶反饋的問題，專門設立了“客服回訪小組”，通過人工溝通，處理用戶的問題，最常見的就是在產品上有一個客服反饋入口，有的時候用戶處于的使用場景不同，找到的反饋渠道也不同，有些可能就是評論、或者公眾號留言、或者添加客服微信等等。
那最終要如何處理好用戶反饋的問題，以及用戶反饋的問題如何高效處理和安撫用戶的情緒以及結果反饋，對用戶都特別的重要，這里反饋問題的用戶以B端為例，產品形態面向用戶屬于免費模式。
對反饋流程進行梳理，大概分為四部：
- 收集問題
- 提交問題
- 跟進問題
- 反饋結果
一、收集問題
1. 不做問題純收集者
面向B端的問題，其實比較致命的，因為影響一個B端，背后其實影響著未知的C端體驗，尤其是2B又2C的平臺，所以響應速度尤其重要。
所以我們看到很多B端類型產品，在用戶使用中特別顯眼的位置，放入客服入口，為的就是為了快速響應用戶反饋的問題，因為沒有百分百的順利。
用戶反饋的問題種類繁多，分為大的三類：
- 體驗類
- BUG類
- 需求類
體驗類，無非就是對產品使用理解成本高，或者覺得使用時特別不順，沒有達到自己的預期等等，這些都是為體驗類問題
針對體驗類問題，并不能一下子就能處理好，而是需要接受人員學會判斷，同時記錄好相關數據。例如：影響不嚴重，反饋數據不多，可能就需要另行判斷，如果影響不嚴重，但是反饋數據多，這個時候就需要嚴謹對待，可以用一個四象限法則來進行梳理。
對于體驗問題的嚴重，做一句解釋，比如：產出這個功能，是用戶進入產品必使用的，就是屬于嚴重的，如果反饋數量超過幾個，就可以進入緊急處理了。
另外對于用戶的反饋很多時候，都是主觀臆斷，因此需要界定標準，但是標準不會是死的，需要靈活制定或者定期調整，而出發的目的是為了給用戶提供更好的產品體驗，但是開發資源永遠都是稀缺的，所以要在稀缺資源中，解決效益高的問題，才能為項目創造更好的收益。
體驗問題是一個長期活，當然針對體驗問題，我們也可以主動出擊，通過用戶訪談的方式，來調研產品的某個功能、某個板塊對用戶的體驗是怎樣，有什么問題、包括用戶在什么場景下使用這塊產品、為什么會使用、使用的目的、以及對這個功能的期望等等，這里會涉及一套完整的調研流程和方法，期待下次深入分享調研。
從調研角度分享一句，一款功能上線后數據好不好，生產出來這個功能的產品經理都需要對此負責，用戶訪談其實是提升數據、獲取功能對用戶的體驗的一個很好方式。
2. 針對BUG問題
在我們腦海中BUG都是相對比較緊急，因為嚴重影響用戶進程，在BUG面前從產品、運營、技術都是不希望出現，而一旦出現后，就需要處理，而且還需要看處理的效率，但是有些問題可能會進入排期處理，還是那句話，開發資源永遠是有限的。
在收集問題環節，就針對如何提高BUG的處理效率，做些簡單的梳理。
首先需要學會定位問題，問題來了，有可能不是問題，或者問題能直接處理，無需提交到研發，這樣一個來回耽誤了的研發時間，還增加了解決問題的時間成本，收集問題的人其實會變成兩邊得罪人。
定位問題的方式視用戶情況、產品不同，定位的方式會有些差異，但是會有些基本相同的東西，需要用戶提供證據（包括視頻、或者截圖），像在微信小程序里面，相同的產品太多了，有的時候用戶拿了一個別人家的產品來找你反饋，如果和用戶互動了半天，還未看到問題的證據，那證明收集問題的人自身有問題了。
從證據——操作步驟——使用環境——設備/版本（大致一個流程，但是不一定這么走的）
對產品業務比較熟悉時，一般有些簡單問題，在證據環節就能馬上產出對應的解決方案，而再難一點的問題，就需要用戶提供相關操作步驟，從而更好的處理問題。
定位問題，還有一點，就是需要判斷“問題的影響程度”，在這里也可以用四象限法則進行梳理，在這個前提我們需要界定“是否為核心流程、還是分支流程”，核心流程就不需要分析，直接定位清楚問題直接處理。
在面向用戶提價的BUG必須要自己走一遍流程，需要確認為是否必現，還是個別用戶會出現，個別用戶會出現，有可能是機型兼容問題、就需要進一步找到對應機型來操作一遍，如果未復現，就有可能是環境或者其它原因，這類型就會變成偶現BUG類型。
3. 針對需求類型
需求相信是產品經理比較喜歡的，一個產品的功能，源自于用戶的需求，不是源自于功能本身，這個時候如果用戶在使用你的產品發現原有功能未能滿足自己想達到的目的時，就有可能找客服傾訴反饋。
但不是所有的功能訴求，都是能被滿足的，原因是“開發資源永遠是稀缺的”，調用資源時，需要考慮付出的成本，是否低于收益，如果是，則是可以考慮，當遠不止這些，還得考收益大成本的指數是多少，當然越高越好。
需求分類是可以用到四象限法則，市場空間，可以定位給我們能帶來多少效益，也可以理解為這個功能針對哪類人群推出，預計會有多少人使用。
在問題收集時，特別考驗收集人員的溝通技巧，因為你需要挖掘用戶背后的核心訴求、包括用戶為什么要這個功能、在什么場景下使用、想達到什么目的？是否有替代方案等等，相當于一次用戶訪談調研了。
二、提交問題
問題的提交設計到內部協作，對接的是技術，想要問題得到快速處理，就需要讓技術放下手中其它重要的事情，來處理你認為的這件重要的事情，也就是技術心中的取舍。
前面在收集問題如果做好的話，如果進入到提交問題，基本已經為處理問題的效率解決了一般以上的問題了。
解決問題的效率，是否把用戶反饋過來的問題丟到群內就可以了，這樣肯定是不行的，除非那種整體崩盤、大面積影響的，直接在群內艾特相關負責人來緊急處理，這類的問題比如：“服務器異常、某個主流程功能無法打開等等”。
提交問題必須有標準規范流程，因為標準所以才會高效，從用戶反饋——收集人員收集——技術，已經被過濾了，如果沒有標準，處理問題起來，技術就會增加理解成本，從而導致處理問題的效率變得低效。
舉些簡單例子：操作步驟、用戶機型/版本、是否必現、影響程度、包括用戶設置好的信息（如用戶發布的文章無法打開，就需要文章鏈接）用戶的ID（內部）。包括在哪里反饋問題都有規定，不能隨便在群內丟個問題，這樣信息可能會被聊天記錄覆蓋，而是需要有專門的協作文檔。當信息特別齊全的時候，有專門的協作文檔，協作效率自然會變得高效。
三、跟進問題
認為跟進問題，也是需要有協作規范的，畢竟每個人都有忙不完的事情，既然是線上協作，那提交問題的人在哪里進行反饋，處理問題的人反饋的結果自然也要在反饋處進行回復。
當提交問題的人，提交上去后，最想知道的就是，問題什么時候能解決好，因為用戶會追著問你處理進度，會拷問你什么時候給我處理好，面對用戶的壓力，另外一邊又面對技術工作繁忙的壓力，除了規范的協作之外，還需要當面溝通，避免忘記。
另外個人認為，除了跟進問題的處理進度，以及處理好后的反饋，還需要知道問題導致的原因，畢竟每一次導致的原因，是收集問題最好學習的時候。
這個時候就需要內部制定標準規范，所有的問題，都需要技術對問題的造成原因進行描述，以及處理好了進行描述，甚至還可以說處理的方法，以及處理好后對未來是否有隱患，都是需要寫清楚，這樣問題跟進起來，特別明了，也能追責，當再次遇到問題時，也能快速處理。
四、反饋結果
反饋問題，一般都是實時的，因為收集問題的人，有可能是微信溝通中，還有的時候用戶會時不時的問你進度，這都需要處理好。
在反饋過程中，有些用戶會有情緒，這個時候還要考驗收集問題人的安撫能力，需要站在用戶角度來安撫，而且還不能把話說死。
有些收集到問題的人，因為一直催一直鬧，這個時候當問到技術xx時間處理好后，收集問題的人會立馬反饋給到用戶，來安撫用戶，但是往往有的時候技術任務特別繁忙的時候，會讓問題處理的時間延后，這樣就會在用戶面前失信，從而更加激起用戶心中的不滿。
反饋結果還有需要特別注意，就是誰反饋的什么問題，處理好后需要向這個人反饋處理結果，這個情況是有的時候接待聊天的人數較多，同時反饋問題的人也多時，要么造成反饋結果不及時或者漏掉，當用戶主動再來找你時，已經加重用戶內心不滿的情緒，認為問題收集者需要有針對自己的專門記錄文檔，以便問題從處理到跟進到反饋，能有比較清晰的處理進度流程，這樣盡力保證處理起來特別順。
五、總結
關于問題收集，需要有很好的反饋入口，尤其是BUG類型的，用戶往往帶著不滿的情緒，來反饋時有的時候相當于是找地方發泄，尤其是帶著非常不滿情緒的這類用戶，安撫和處理進度反饋是特別重要，當然其它類型一樣重要，只是類用戶處理需要特別謹慎對待。
而針對處理問題的效率如何提升，需要內部有良好的協作機制，最好有標準規范流程，以及特別考驗收集問題人的分析能力以及對產品業務的熟悉程度，決定問題是否能夠被很好的、且快速的處理完。
另外用戶如果是需求類型，考驗的是一個人的溝通技巧，在這個研發資源稀缺的環境下， 不是所有功能都能被滿足，只有效用高于成本時，才會被重視。
收集用戶的入口不是有一個入口就行，還需要考慮用戶反饋的成本，像滴滴在知否可以直接選擇評價，這就是一種反饋，而有些面向B端類型的產品，可能考慮的是就人工聊天，有些是在線聊天，有些是加微信，為的是能夠快速處理好問題。
一般來說用戶特別在乎的問題就是和自己利益相關的、不管問題大小用戶都會說的特別嚴重，判斷和定位問題特別重要?？傊ㄎ粏栴}越清晰，內部協作有標準的規范流程，協作處理效率才會越高。
本文由 @大劉小飛 原創發布于人人都是產品經理，未經作者許可，禁止轉載
題圖來自Unsplash，基于CC0協議
怎么樣才可以看到圖
我和你一樣看不到，就很bad