產品鯨鯉披星帶月，程式猿哥哥拋家舍業，測試妹紙廢寢忘食，終於把產品更新上線了，可是一大波問題回饋瀟瀟灑灑砸來了，本宮該如何是好?
答案就是：搜集回饋的問題，分析使用者痛點，反覆運算產品呈現。
一. 收集用戶回饋為哪般?
古語雲：知己知彼百戰不殆。用戶使用過程中，或多多少會發出不同聲音，這時自然需要急用戶之所急。收集用戶回饋，在互聯網公司，一般有個高達上的職稱，叫運營攻城師，他們的工作目的無非如下：
為產品：
瞭解產品有哪些BUG?是程式猿偷工減料還是使用者雞蛋裡挑骨頭;
瞭解競品優勢，自己是需要在體驗上優化還是完善新功能?
為用戶：
瞭解產品的目標使用者與實際使用使用者是否匹配?
使用者愛哪個模組?討厭哪個功能點?有沒有更高期許?使用時遇到哪些問題?
有些公司，特別是初創型的公司，產品經理兼做運營，而有些公司設有專門的運營團隊，而有的卻不知運營為何物。無論如何，做好用戶回饋問題收集，已是大勢所趨。
二. 條條大路通收集
有些公司 bigger than bigger，所以同一款產品有web 版，有移動版(iphone & Android)，有微信版等，收集問題管道就五花八門;有些是小型mini，管道主要走經典路線。歸納起來，主要如下：
自建回饋問題系統：
郵件：一般會在網頁有顯示郵件，但真正發郵件的會少之又少，因為懶!
工單：內部自建系統
需求池：需求流程一般是客戶提出—>運營收集—>PM整理，更新成需求池文檔
面對面言語溝通：主要用於內部回饋管道
產品中的問題回饋功能：這個大家都懂的
協力廠商工具：
熱線電話：據統計，使用這種方式用的人也不多
官方QQ群：QQ 大法好
微信公眾號：流行趨勢
官方微博：weibo 還是很 hot 的
每種管道各有優劣勢，可以據自身產品定位，建設符合產品長期穩定發展的特色管道。
三. 吐槽紛紛來
當各個回饋管道逐漸建立起來，運營妹紙們就會“享受”著那如波濤般洶湧的吐槽了。
收到的用戶回饋基本可以分為四類：
1.BUG：程式猿哥哥最怕的，如XX功能沒回應，xx功能失敗，xx功能，404頁面……
2.建議：令 PM 頭疼的，如為什麼沒有xx功能?隔壁那產品的xx功能挺好的，這個介面該優化下……
3.吐槽：有些是噴子，心理建設要牢固，如真是爛系統!浪費精力……
4.其他：如好喜歡xx功能呀!沒有回饋的產品不是一個好產品，都是讚美之詞的產品，除非是一個神一樣的存在。
四. 轉化大法好
對問題進行分類之後，運營妹紙接下來要做的就是解決問題或轉化成新需求。
當然，收到回饋後，不管用戶是否在扯淡，都要以良好的姿態傾聽，並給予感謝和確認收到的回饋，讓用戶實切感受到“再小的聲音，我們也能聽得到”。除了這樣，就具體問題具體分析了：
BUG：
1. 是 BUG 的立馬走入 BUG 修改程式，有測試人員的，與其建立好溝通機制;
2. 分清優先順序高低及嚴重程度劃分;
3. 集中處理迅速上線，如果可以，在上線的時候告訴提出問題的用戶已經解決了，或者給用戶一個小獎勵，這是個特別好的讓用戶感受到關心的機會。
建議：
1. 篩選核心用戶的需求，考慮此需求是否會損害目標使用者的利益和產品目標，挖掘合理建議轉化成需求，可與用戶進行二次溝通，避免理解不對稱;
2. 再根據產品的目標(長期和階段性的)去排需求優先順序;
3. 進入版本的反覆運算開發流程，對現存問題進行改進;
吐槽 & 其他：
1. 大聲的罵聲比較刺耳，未必是核心用戶發出來的，很多人罵罵就走，不要放大這樣的聲音，可以適當忽略，平常心對待，但也要反思用戶為何如此憤怒;
2. 做到心裡有數，對產品改版的目標堅持，對其能做成簡而美的 top 產品充滿信心;
3. 用戶特別喜愛的功能，要持續加強;
用戶回饋不是人微言輕，但慎重對待，運營人員要做挖掘機中的戰鬥機，發現背後的金子回饋。當然，不能被用戶的回饋牽著鼻子走，有時候用戶的需求看是不是可以曲折實現。
要擴大產品，但也要精簡需求，不要做大而虛的產品。
一千個用戶就會有一千個哈姆雷特，當你面對成千上萬個哈姆雷特的時候你要學會區分“what they need”和“what they want”的區別。
五. 總結
互聯網產品上線後，如何對待用戶回饋，寫了那麼多，總結來無非就是：
聽，重視用戶聲音，再小的聲音也要聽得到;
思，聽完之後探索聲音背後深層的需求，分析痛點;
做，提取需求、轉化需求、實現需求。
留言列表
