泡了 1 年用戶後，我總結了這些反饋處理經驗

我想認真的嘮嘮關於互聯網的用戶支持（初級用戶運營），看完本文就不要再說別人是客服了喲~

互聯網的用戶支持和傳統客服的重要區別在於：相比於客服被動地響應用戶的問題，用戶支持更多的會主動出擊，發現並解決問題。

以前做這部分工作的時候，是藉助於一款協作軟體去開展的，這裡不提名字了。我最初是覺著這樣的事情做起來沒什麼意思，直到慢慢的摸索出這樣一套流程來，算是這部分工作最直接的收穫了。

我想你可能已經留意到了，它是一個閉環的流程。

第一部分 需求收集

一、用戶反饋

在冷啟動的文章裡面介紹過，要給用戶留下可以聯繫你的渠道，一般說來有以下這些：

• 用戶反饋郵箱

• 產品反饋後台

• 用戶群（QQ 群/微信群等）

• 新媒體（公眾號、微博等）

• 第三方社區（知乎、豆瓣、貼吧等）

• 其他（應用市場、公關稿、辦公室的一聲吼...）

用戶會通過這些渠道把使用過程中遇到的情況反饋過來，反饋通常分為以下幾類：

• 產品 bug

• 吐槽

• 功能建議

• 其他（比如，以前聽到多位用戶來打聽 CEO 有木有女盆友的...）

1、產品Bug

如果用戶描述的很清楚，我通常會自己動手看看能不能捕捉到這個 bug（嗯，「人肉」測試下），然後報給團隊；如果描述的不是很清楚，就按照技術猿們問我們的套路來向用戶收集信息：平台、版本、頁面、操作...

話說後來有一天，我知道有一種工具，是可以在出現 bug 時，直接精準到導致出錯的那一行代碼，根本不需要問用戶雜七雜八...我承認那一刻，我其實內心深處真的是很想問候下，當年那些不尊重我們時間的猿們...願你們有一天也要直面用戶的怒火，然後持續個百十天。

2、吐槽

很多原因導致用戶吐槽，交互設計、頁面設計、操作流暢度、業務流程等，但通常都是用戶感到非常沮喪時，才會引起吐槽。所以，在和吐槽用戶的交涉過程中，多含一些同理心吧。

當然，吐槽真的很容易讓人產生負面情緒，有段時間看吐槽多了，負能量爆棚，就天天想要逃避用戶...但是，不得不承認，很多的吐槽都是有價值的，爭取引導用戶說出來，找到問題。如果實在累了，就去特么的，休息幾天調整調整心態吧。

3、功能建議

功能建議分為兩大類：新增功能、功能優化。這部分是反饋的重點，下文慢慢說。

二、反饋收集

在進行需求收集的時候，可以從以下幾個方面考慮：

1、用戶畫像

了解下反饋用戶的基本信息，性別、職業、年齡層、收入等，這通常與我們所運營的產品相關，了解下是否是目標用戶提出的需求。

2、用戶場景

用戶提出這個需求的原因是什麼，在什麼樣的情況下，想完成什麼事情，做了哪些操作，結果如何？這些信息非常有助於團隊成員理解需求。

3、產品信息

了解用戶使用的是哪個客戶端（web、iOS、android、WP等），使用的版本號。很可能反饋的需求在新版本中已經解決了，但用戶沒有升級，所以並不知曉。

4、用戶聯繫方式

記錄下用戶的聯繫方式，這條很有用，一方面用於統計分析，一方面為了完成反饋的閉環。通常，用戶通過哪個渠道反饋的，就記錄下該用戶在這個渠道下的聯繫方式，如QQ號、郵箱、評論鏈接、電話等。

三、反饋處理

1、已知需求

很多時候，用戶的反饋是團隊已知悉的，對於已知悉的需求，通常我會告訴用戶團隊對這個需求的考慮，以及大概的開發計劃（一定記得給團隊留點時間，不要向用戶透露具體時間，除非這件事是板上釘釘，絕不會改變的，而這種情況是極少的）。時間允許的情況下，還可以和用戶一起聊一聊對於解決方案的看法。

2、新需求

對於新的需求，作好記錄的同時，也不忘告訴用戶，你的反饋已經收到啦。

3、使用問題

如果是功能使用的問題，就可以第一時間幫用戶解決掉，告訴下正確的使用方法即可。

第二部分 需求管理

一、需求記錄

用戶反饋在經過篩選整理後，有很多建議會被放到需求池。通常建議是和產品迭代聯繫在一起的，舊的去了，新的又會來。所以，就需要對需求池進行管理。

1、歸類

如果用戶的反饋在之前已經有類似的反饋，只需要將相同的建議統一在一處即可，不需要單獨開新的需求；而對於同一功能模塊下的需求，也可以歸集在一處，按照不同模塊來簡單分類；而具備上下游關係的多個需求，可以進行關係的梳理，待上游的問題解決後，下游的需求可能自然就對應的解決了。

2、次數

對於相同的需求，記錄有多少用戶反饋過，從反饋總次數的維度了解用戶比較關心的幾個問題。這裡要注意，並不是反饋的次數多，這個需求就一定是重要到非做不可的。一個需求能不能做，還需要考慮公司對產品的戰略規劃、佔用的開發資源以及開發難度等問題。對於需求的考慮需要單獨討論，這通常也是產品經理考慮的問題，這裡先不展開了。

3、頻次

顧名思義，頻次就是在一定時間內，同一個需求反饋的次數。這個是從緊急度的維度去看一個需求。通常，會在新版本上線後，重點留意這個維度。如果新版本上線後一段時間，有多個用戶反饋了同一個問題，那可能新版本出現問題了，就要及時通知團隊，但是立即修複發新版，還是回滾到之前的版本，就要看團隊的考慮了。

二、進度跟蹤

1、對用戶

其實和用戶交流就像和一個正常的朋友打交道一樣，交朋友很重要的一點就是，讓對方知道你是靠譜的。那怎麼讓用戶感受到你是靠譜的呢？我的建議是：做產品的專家。

在用戶張嘴的時候，就能判斷出大概是什麼問題，解決方案有哪些，最合適該用戶的方案是什麼；如果現在沒有解決方案，那麼這個問題在不在團隊的考慮範圍內，如果不在，原因是什麼；如果在考慮了，目前在什麼階段了，大概的解決時間和解決方案是什麼。最後用戶容易接受的方式告訴用戶原因。不用擔心這樣的舉動會導致用戶流失，說實話用戶未必就不能接受，和套話、空話相比，說實話給用戶的體驗可能更好。並且有些用戶的流失真的不可避免，因為確實不在服務範圍內。

也許你的用戶有來自各個領域的領袖人物，但是確保在自家產品上，你是領袖。專業的知識總是令人信服的，也是最容易樹立威望的。

2、對團隊

進度跟蹤一方面要參與到團隊內部的需求決策過程中來，在產品決策的時候，要確保團隊對用戶的意思理解正確，對於不確定的解決方案，還可以找幾個用戶實際了解下方案的偏好。

進度跟蹤的另一方面，是要及時了解團隊對需求處理的實際情況，比如，開發計劃有沒有被調整，開發進度有沒有延期，設計方案和用戶期望有多大的差距...根據實際情況更新需求池信息，可以讓我們在面對用戶的時候，減少錯誤信息的傳遞。

第三部分 需求實現

一、產品更新

1、通知反饋用戶

產品更新後，第一時間通過反饋收集環節記錄的用戶聯繫方式去通知反饋對應需求的用戶，這樣做的好處是：

讓這些反饋的用戶能第一時間收到消息，獲得良好的反饋體驗；

了解這部分用戶對新功能的看法，帶來新的反饋；

對於N久之前反饋的用戶，以一種友好的方式嘗試召回。

2、發布更新消息

主動反饋的用戶佔比是不高的，大部分都是沉默用戶。因此，在產品更新後，要將針對新版本/新功能的更新內容，通過建立起來的各個渠道發布出去，讓其他未直接反饋的用戶了解到更新信息。

二、歸檔/完成

需求的處理到這裡並沒有結束，還需要對需求做個歸檔。在已解決的需求下記錄對應的解決方案、更新版本、發布的時間，因為後期分析用戶行為或產品數據時，如果遇到數據異常，可能需要從歸檔的需求裡面找依據。比如，回顧數據時，發現上個月的某個功能使用率明顯提升，然後猜測是和上個月發布了新版本有關，在需求池發現，這個功能的優化建議在上個版本實現了，這樣就可以幫助我們找到了一些異常發生的依據了。

—————————————————————————————————————————

以上是本人在處理反饋時總結的經驗，可能和你在做的有一些不一樣。不過呢，用心去對待用戶，認真對待每一條反饋，我相信肯定都是一樣的。

老規矩：

覺著有收穫，就請動手留個贊咯

如果有不同的看法，我們評論區見吧

想鼓勵下我的，別忘了關注下專欄，幫我一起傳播哦

謝謝~~~
推薦閱讀：