著名的產(chǎn)品人俞軍在自己的《俞軍產(chǎn)品方法論》一書中提到“產(chǎn)品即媒介，公司只是通過產(chǎn)品這個媒介向用戶傳遞可交易的價值”，所以當一個需求產(chǎn)生之后，實際是向用戶獲取交易價值，用戶在愿意交易的情況下，對于這個收益是超出自己所付出的成本，這里的成本包括“直接的金錢、還有間接的時間等等”，用戶才會愿意交易。

那這里談到的用戶反饋問題，其實從某種角度來說，用戶已經(jīng)使用過你的產(chǎn)品，且用戶覺得自己付出了一定的交易成本，但是卻得不到滿足，并且在找平臺反饋時（反饋的成本要小于自己的收益，或者預期收益較大時才會堅持找到你反饋）已經(jīng)有心里預期。

反饋問題的渠道有很多種，有些平臺特別重視用戶反饋的問題，專門設立了“客服回訪小組”，通過人工溝通，處理用戶的問題，最常見的就是在產(chǎn)品上有一個客服反饋入口，有的時候用戶處于的使用場景不同，找到的反饋渠道也不同，有些可能就是評論、或者公眾號留言、或者添加客服微信等等。

那最終要如何處理好用戶反饋的問題，以及用戶反饋的問題如何高效處理和安撫用戶的情緒以及結果反饋，對用戶都特別的重要，這里反饋問題的用戶以B端為例，產(chǎn)品形態(tài)面向用戶屬于免費模式。

對反饋流程進行梳理，大概分為四部：

1. 收集問題

2. 提交問題

3. 跟進問題

4. 反饋結果

一、收集問題

1. 不做問題純收集者

面向B端的問題，其實比較致命的，因為影響一個B端，背后其實影響著未知的C端體驗，尤其是2B又2C的平臺，所以響應速度尤其重要。

所以我們看到很多B端類型產(chǎn)品，在用戶使用中特別顯眼的位置，放入客服入口，為的就是為了快速響應用戶反饋的問題，因為沒有百分百的順利。

用戶反饋的問題種類繁多，分為大的三類：

1. 體驗類

2. BUG類

3. 需求類

體驗類，無非就是對產(chǎn)品使用理解成本高，或者覺得使用時特別不順，沒有達到自己的預期等等，這些都是為體驗類問題

針對體驗類問題，并不能一下子就能處理好，而是需要接受人員學會判斷，同時記錄好相關數(shù)據(jù)。例如：影響不嚴重，反饋數(shù)據(jù)不多，可能就需要另行判斷，如果影響不嚴重，但是反饋數(shù)據(jù)多，這個時候就需要嚴謹對待，可以用一個四象限法則來進行梳理。

對于體驗問題的嚴重，做一句解釋，比如：產(chǎn)出這個功能，是用戶進入產(chǎn)品必使用的，就是屬于嚴重的，如果反饋數(shù)量超過幾個，就可以進入緊急處理了。

另外對于用戶的反饋很多時候，都是主觀臆斷，因此需要界定標準，但是標準不會是死的，需要靈活制定或者定期調(diào)整，而出發(fā)的目的是為了給用戶提供更好的產(chǎn)品體驗，但是開發(fā)資源永遠都是稀缺的，所以要在稀缺資源中，解決效益高的問題，才能為項目創(chuàng)造更好的收益。

體驗問題是一個長期活，當然針對體驗問題，我們也可以主動出擊，通過用戶訪談的方式，來調(diào)研產(chǎn)品的某個功能、某個板塊對用戶的體驗是怎樣，有什么問題、包括用戶在什么場景下使用這塊產(chǎn)品、為什么會使用、使用的目的、以及對這個功能的期望等等，這里會涉及一套完整的調(diào)研流程和方法，期待下次深入分享調(diào)研。

從調(diào)研角度分享一句，一款功能上線后數(shù)據(jù)好不好，生產(chǎn)出來這個功能的產(chǎn)品經(jīng)理都需要對此負責，用戶訪談其實是提升數(shù)據(jù)、獲取功能對用戶的體驗的一個很好方式。

2. 針對BUG問題

在我們腦海中BUG都是相對比較緊急，因為嚴重影響用戶進程，在BUG面前從產(chǎn)品、運營、技術都是不希望出現(xiàn)，而一旦出現(xiàn)后，就需要處理，而且還需要看處理的效率，但是有些問題可能會進入排期處理，還是那句話，開發(fā)資源永遠是有限的。

在收集問題環(huán)節(jié)，就針對如何提高BUG的處理效率，做些簡單的梳理。

首先需要學會定位問題，問題來了，有可能不是問題，或者問題能直接處理，無需提交到研發(fā)，這樣一個來回耽誤了的研發(fā)時間，還增加了解決問題的時間成本，收集問題的人其實會變成兩邊得罪人。

定位問題的方式視用戶情況、產(chǎn)品不同，定位的方式會有些差異，但是會有些基本相同的東西，需要用戶提供證據(jù)（包括視頻、或者截圖），像在微信小程序里面，相同的產(chǎn)品太多了，有的時候用戶拿了一個別人家的產(chǎn)品來找你反饋，如果和用戶互動了半天，還未看到問題的證據(jù)，那證明收集問題的人自身有問題了。

從證據(jù)——操作步驟——使用環(huán)境——設備/版本（大致一個流程，但是不一定這么走的）

對產(chǎn)品業(yè)務比較熟悉時，一般有些簡單問題，在證據(jù)環(huán)節(jié)就能馬上產(chǎn)出對應的解決方案，而再難一點的問題，就需要用戶提供相關操作步驟，從而更好的處理問題。

定位問題，還有一點，就是需要判斷“問題的影響程度”，在這里也可以用四象限法則進行梳理，在這個前提我們需要界定“是否為核心流程、還是分支流程”，核心流程就不需要分析，直接定位清楚問題直接處理。

在面向用戶提價的BUG必須要自己走一遍流程，需要確認為是否必現(xiàn)，還是個別用戶會出現(xiàn)，個別用戶會出現(xiàn)，有可能是機型兼容問題、就需要進一步找到對應機型來操作一遍，如果未復現(xiàn)，就有可能是環(huán)境或者其它原因，這類型就會變成偶現(xiàn)BUG類型。

3. 針對需求類型

需求相信是產(chǎn)品經(jīng)理比較喜歡的，一個產(chǎn)品的功能，源自于用戶的需求，不是源自于功能本身，這個時候如果用戶在使用你的產(chǎn)品發(fā)現(xiàn)原有功能未能滿足自己想達到的目的時，就有可能找客服傾訴反饋。

但不是所有的功能訴求，都是能被滿足的，原因是“開發(fā)資源永遠是稀缺的”，調(diào)用資源時，需要考慮付出的成本，是否低于收益，如果是，則是可以考慮，當遠不止這些，還得考收益大成本的指數(shù)是多少，當然越高越好。

需求分類是可以用到四象限法則，市場空間，可以定位給我們能帶來多少效益，也可以理解為這個功能針對哪類人群推出，預計會有多少人使用。

在問題收集時，特別考驗收集人員的溝通技巧，因為你需要挖掘用戶背后的核心訴求、包括用戶為什么要這個功能、在什么場景下使用、想達到什么目的？是否有替代方案等等，相當于一次用戶訪談調(diào)研了。

二、提交問題

問題的提交設計到內(nèi)部協(xié)作，對接的是技術，想要問題得到快速處理，就需要讓技術放下手中其它重要的事情，來處理你認為的這件重要的事情，也就是技術心中的取舍。

前面在收集問題如果做好的話，如果進入到提交問題，基本已經(jīng)為處理問題的效率解決了一般以上的問題了。

解決問題的效率，是否把用戶反饋過來的問題丟到群內(nèi)就可以了，這樣肯定是不行的，除非那種整體崩盤、大面積影響的，直接在群內(nèi)艾特相關負責人來緊急處理，這類的問題比如：“服務器異常、某個主流程功能無法打開等等”。

提交問題必須有標準規(guī)范流程，因為標準所以才會高效，從用戶反饋——收集人員收集——技術，已經(jīng)被過濾了，如果沒有標準，處理問題起來，技術就會增加理解成本，從而導致處理問題的效率變得低效。

舉些簡單例子：操作步驟、用戶機型/版本、是否必現(xiàn)、影響程度、包括用戶設置好的信息（如用戶發(fā)布的文章無法打開，就需要文章鏈接）用戶的ID（內(nèi)部）。包括在哪里反饋問題都有規(guī)定，不能隨便在群內(nèi)丟個問題，這樣信息可能會被聊天記錄覆蓋，而是需要有專門的協(xié)作文檔。當信息特別齊全的時候，有專門的協(xié)作文檔，協(xié)作效率自然會變得高效。

三、跟進問題

認為跟進問題，也是需要有協(xié)作規(guī)范的，畢竟每個人都有忙不完的事情，既然是線上協(xié)作，那提交問題的人在哪里進行反饋，處理問題的人反饋的結果自然也要在反饋處進行回復。

當提交問題的人，提交上去后，最想知道的就是，問題什么時候能解決好，因為用戶會追著問你處理進度，會拷問你什么時候給我處理好，面對用戶的壓力，另外一邊又面對技術工作繁忙的壓力，除了規(guī)范的協(xié)作之外，還需要當面溝通，避免忘記。

另外個人認為，除了跟進問題的處理進度，以及處理好后的反饋，還需要知道問題導致的原因，畢竟每一次導致的原因，是收集問題最好學習的時候。

這個時候就需要內(nèi)部制定標準規(guī)范，所有的問題，都需要技術對問題的造成原因進行描述，以及處理好了進行描述，甚至還可以說處理的方法，以及處理好后對未來是否有隱患，都是需要寫清楚，這樣問題跟進起來，特別明了，也能追責，當再次遇到問題時，也能快速處理。

四、反饋結果

反饋問題，一般都是實時的，因為收集問題的人，有可能是微信溝通中，還有的時候用戶會時不時的問你進度，這都需要處理好。

在反饋過程中，有些用戶會有情緒，這個時候還要考驗收集問題人的安撫能力，需要站在用戶角度來安撫，而且還不能把話說死。

有些收集到問題的人，因為一直催一直鬧，這個時候當問到技術xx時間處理好后，收集問題的人會立馬反饋給到用戶，來安撫用戶，但是往往有的時候技術任務特別繁忙的時候，會讓問題處理的時間延后，這樣就會在用戶面前失信，從而更加激起用戶心中的不滿。

反饋結果還有需要特別注意，就是誰反饋的什么問題，處理好后需要向這個人反饋處理結果，這個情況是有的時候接待聊天的人數(shù)較多，同時反饋問題的人也多時，要么造成反饋結果不及時或者漏掉，當用戶主動再來找你時，已經(jīng)加重用戶內(nèi)心不滿的情緒，認為問題收集者需要有針對自己的專門記錄文檔，以便問題從處理到跟進到反饋，能有比較清晰的處理進度流程，這樣盡力保證處理起來特別順。

五、總結

關于問題收集，需要有很好的反饋入口，尤其是BUG類型的，用戶往往帶著不滿的情緒，來反饋時有的時候相當于是找地方發(fā)泄，尤其是帶著非常不滿情緒的這類用戶，安撫和處理進度反饋是特別重要，當然其它類型一樣重要，只是類用戶處理需要特別謹慎對待。

而針對處理問題的效率如何提升，需要內(nèi)部有良好的協(xié)作機制，最好有標準規(guī)范流程，以及特別考驗收集問題人的分析能力以及對產(chǎn)品業(yè)務的熟悉程度，決定問題是否能夠被很好的、且快速的處理完。

另外用戶如果是需求類型，考驗的是一個人的溝通技巧，在這個研發(fā)資源稀缺的環(huán)境下， 不是所有功能都能被滿足，只有效用高于成本時，才會被重視。

收集用戶的入口不是有一個入口就行，還需要考慮用戶反饋的成本，像滴滴在知否可以直接選擇評價，這就是一種反饋，而有些面向B端類型的產(chǎn)品，可能考慮的是就人工聊天，有些是在線聊天，有些是加微信，為的是能夠快速處理好問題。

一般來說用戶特別在乎的問題就是和自己利益相關的、不管問題大小用戶都會說的特別嚴重，判斷和定位問題特別重要?？傊ㄎ粏栴}越清晰，內(nèi)部協(xié)作有標準的規(guī)范流程，協(xié)作處理效率才會越高。

-END-