什麼是收集用戶反饋的正確姿勢 | 基於騰訊「吐個槽」的思考

本篇文章基於騰訊「吐個槽」，對用戶反饋關鍵點、收集流程、評估及分級進行了深入探討，分析了用戶反饋平台當前面臨的問題給出相關優化建議，並對未來用戶反饋平台的發展方向進行了展望。

編者按

作者|李陽/京東金融數據產品經理

轉自|人人都是產品經理

一、當我們說用戶反饋的時候，我們在說什麼？

【提問】用戶反饋是什麼？我們為什麼要收集反饋？

【回答】用戶反饋能夠幫我們的產品變得更好呀！我們快搭個平台吧！

等等！什麼是「更好」的產品？我們的產品又是怎麼「變好」的？還有5W1H啊同學！這些基本的問題不解決，直接做反饋平台可能有點小浪費啊親。

1.1 用戶反饋的關鍵點

既然是收集用戶反饋，那麼這個事還要從用戶說起。對於用戶來說，提交反饋絕對是個「多餘」的工作量。但是，我們只要在產品上開了提交反饋的口（一般都會開的吧），就多多少少能收到一些用戶提交的反饋，捧上天的也有，按到地上摩擦的也有。那麼是什麼讓用戶「放棄」了「直接流失」這個選項，而來提反饋呢？我們從積極和消極兩個方面來看：

1. 【積極用戶】：這個產品太好了，我的主要訴求已經滿足，如果能夠再改改，或者在增加一些外圍的功能就更好了！
2. 【消極用戶】：這個……哎這個產品是個什麼鬼！老板還必須讓用這個，趕快讓他們改改！（或者其他一些讓用戶必須選擇這款產品的因素，比如：獨此一份再無競品、有大量歷史資料不方便遷移等等。）

那麼，對於以上兩種用戶來說，「好」的標準是完全不同的——

1.對於已經比較滿意的用戶，可能會願意花費更多的時間和精力協助團隊改善產品，相應的也比較能忍耐一些臨時方案和延誤的時間點；因此，對於這樣的用戶，其反饋為產品提供的一般是中長期的發展參考。比如，還有哪些場景沒有覆蓋？以往收集到的需求是否有所變化？等等。

2.對於那些不滿意的用戶，盡快解決最緊急的問題才是關鍵。同時，這樣的用戶通常也會有意無意地主動調低自己的期望值，一些更加高遠的需求可以暫時放棄。這樣的用戶一般會幫助團隊找到一些未被發現嚴重問題以及相應的復現Case。

通過這樣的分析不難看出，如果此時我們把大量資源用來滿足積極用戶的那些「錦上添花」的功能，那麼另一邊的消極用戶就要罵街了。這就是對於兩種用戶的「好」的不同標準。

此外，關於用戶反饋和需求，在產品圈子還流傳著這麼一句：「不要完全聽用戶的，對於用戶的直接訴求，需要進一步深挖其本質。」這個狀況，在一定程度上就是因為，願意提出反饋的用戶，都會提出一些跟自己切身利益相關的訴求，但這種切身的訴求未必能夠推廣到更多的用戶身上。而對於那些還有其它選擇的用戶，可能就真的流失了。我們可以把這些流失的用戶，歸為第三類「沉默用戶」（與前面的積極擁護和消極用戶並列）。要收集這些用戶的「反饋」，就需要通過對用戶的行為數據進行分析。

1.2 用戶反饋的基本流程

基於以上幾點，關於用戶反饋以及如何切實地讓自己的產品越來越「好」，我們可以發現的5個關鍵點：

• 需要傾聽用戶的聲音——需要收集到用戶的意見和建議，或其它相關數據；
• 需要深入挖掘用戶的訴求——需要有相應的數據和分析能力支撐；
• 需要考慮用戶訴求的緊急程度——需要給反饋設置緊急程度，評估處理的優先級；
• 需要讓優化切實落地——需要持續跟進反饋的後續進展，進行工程實施；
• 需要提高處理效率——需要系統化、自動化地處理反饋；

結合這5方面，整體的反饋與落地的流程如下圖：

1.3 騰訊「吐個槽」平台帶來了什麼

上面說了一些關於用戶反饋的通用性內容，現在要邀請我們的主角出場了。接下來我們來分析一下騰訊的「吐個槽」平台。騰訊公司面臨的是大體量的用戶群體、複雜而明細的內部產品線，並且公司內部員工眾多。在這樣的情況下，「吐個槽」這款產品就需要具備足夠的能力適應公司組織、產品及用戶群體的特性，同時還要兼顧此平台的外部客戶多重多樣的請款。

【常規收集和定向收集】：在開始向用戶收集反饋之前，我們可以先登錄騰訊「吐個槽」的管理端，並設置相應的問題分類，方便後續的分類和匯總。

1.【評估影響】：在評估的過程中，可以直接通過「反饋列表」中的過濾功能，查找是否出現了大量的相關的問題；如果需要使用更加專業的軟件進行數據分析，也可以通過「吐個槽」平台導出用戶的相關反饋數據。確定需要處理之後，可以在「反饋列表」中批量回復相關用戶的反饋；同時為了跟進進度，可以將相關的用戶反饋標記為「待處理」狀態。

2.【同步用戶】：當用戶提出的反饋有了最新的處理進度，或者得到妥善處理之後，我們需要通知用戶。通過「問題列表」可以對之前的用戶反饋進行批量回復。用戶可以通過自己的微信接收最新的反饋情況。

下面我們分別深入探討一下用戶反饋流程中的幾個關鍵環節。

二、用戶反饋的收集

收集是關鍵的第一步。同時，又可以分為幾種收集方式。

2.1 定向收集

2.1.1 定向收集的「已知條件」

從公司或團隊的角度，這是比較常見的場景。當我們因為不了解用戶而滿心焦慮的時候，自然會想到要向用戶收集反饋。這個時候，我們會有很清晰的研究意向、目標和限制條件——

要針對哪個產品或模塊收集反饋？

• 要詢問哪方面的問題？是產品的特性、交互、體驗？還是用戶的基本信息、使用場景、選品理由？這些會具體落地為調查問卷中的問題列表。
• 要通過什麼管道收集？調查問卷？用戶訪談？選擇線上還是線下？要不要通過一些利益點推動用戶反饋？
• 要投入多少成本？向哪些用戶收集，收集規模有多大？怎麼界定「任務完成」？如果有添加用來促進反饋的利益點，怎麼防止那些不真實的反饋？

……

我們可以根據這些「已知條件」，對整個收集過程進行前置的設計，以確保整個過程可控。

2.1.2 使用「吐個槽」做到定向收集

在 「吐個槽」的產品方向上並不是為了解決這類定向收集的問題而生的，更何況還有騰訊自家的「騰訊問卷」，專門用來解決這個問題。但是，如果「吐個槽」能夠參與這類定向反饋收集的過程，能夠很好的解決「開放性」問題的收集、匯總和實施落地過程。

在一般的用戶調查問卷中，都會提出1~2種開放性的問題。例如：「您對我們的產品還有什麼建議和意見？」「您覺得我們的產品還有哪些待解決的問題？」在這樣的問題中，用戶的反饋是通過文字描述的，通常無法預先知道內容的大概方向。比較適合使用論壇的方式展開討論，逐步細化並且明確實質性的問題在哪。

要做到這樣的功能，在公司內部可以採取技術層面的打通，讓「吐個槽」直接讀取產品相關的開放性問題，並導入到對應的產品反饋項目下。如果是第三方的產品在使用「吐個槽」平台，就需要吐個槽再提供一個批量導入問題的功能，就可以通過手工的方式，做到與各種問卷平台的打通了。

2.2 常規收集

從用戶的角度，這是比較常見的場景了。前面我們提到了兩類會主動反饋的用戶——積極用戶和消極用戶。這兩種用戶都有足夠的動機，主動尋找反饋入口並提交內容，來幫助產品進行優化。

說到常規收集，就需要結合「主產品」的形態統一設計，讓它成為「主產品」的一部分。比如我們的「吐個槽」，就提供了嵌入到其它產品平台的接入方式。

因此，在設計的時候需要考慮一些與交互和融合相關的因素——

2.2.1 交互方式分類

這方面需要盡量考慮與「主產品」的結合，盡量與目標用戶的使用習慣貼近，同時盡量不打斷用戶的正常使用流程。按照不同的交互形態，可以分為以下幾種：

• 論壇式：這個就是「吐個槽」的基本形態了。用戶主動提交自己的問題、對產品的吐槽、優化意見等等，形成交流主題。其他用戶能夠方便的查看別人提交的問題，也能通過反饋平台與產品團隊和其他用戶進行交流。
• 對話式：App端的反饋比較喜歡採用這種方式，而且這種交互形態經常會加入自動回復與人工客服的切換機制——當用戶的問題比較常規時，可以通過機器人自主解決問題，減少人力成本；而當用戶的問題比較刁鑽時，又可以通過主動觸發的方式切換到人工服務，以保證用戶體驗。

• 工單式：偏向技術服務的平台更容易採用這種形式，比如著名的域名平台GoDaddy。當用戶提交反饋之後，反饋會自動變成一條流程工單在工作人員之間流轉，因此會有明確的負責人跟進並推進問題的處理，並且以工單為單位記錄所有的處理過程。這樣，用戶就可以隨時查看自己的問題處理到什麼程度了。
• 留言式：這是一種更常見的交互形態，只給用戶提供了幾個輸入框，可以填寫主題、描述、分類、聯繫方式等內容。當用戶提交了問題之後，就要等著工作人員主動聯繫了。這樣的反饋難免讓用戶覺得「石沉大海」，一般要等到問題開始處理之後，才會有人主動聯繫用戶。

2.2.2 交互流程體驗

這方面的設計，與一般的產品交互區別就不大了。也要考慮用戶使用過程中的體驗如何。比如，入口的深度設計得是否方便找到？是否能在產品出現異常的情況下自動介入進行引導？等等。

另一種設計得比較好的處理方式，是在用戶遇到問題的時候，先將常見的問題和解決辦法供用戶參考。比如下面就是「吐個槽」平台提供的匯總常見問題的列表。針對每個常見問題，用戶都可選擇是否對自己有幫助，之後平台根據這些反饋情況，再對這些常見問題進行優化和排序，以便更快地解決一些高頻發生的問題。這種設計方案，不僅提供了操作上的便利性，也幫團隊減少了處理重復問題的資源浪費，同時在情感上也給用戶一定的安慰，因為可以看到不少其他用戶也遇到了類似的問題。

2.2.3 關於反饋的「反饋」

這一點在設計反饋機制的時候也是相當重要的。好的處理流程，需要時刻保持處理進度向用戶透明。這種信息反饋，能夠讓用戶感到自己受到了足夠的重視。如果在前面的幾種交互形態中比較，留言式反饋收集應當算是最差的了。

除非有工作人員主動聯繫用戶，否則幾乎感受不到有什麼最新的進展。對話式的反饋收集應當是體驗上最好的，能得到即時的反饋。

2.2.4 使用「吐個槽」做到常規收集

只要按照「吐個槽」官方接入文檔進行配置，就可以在自己的產品中使用「吐個槽」平台收集用戶反饋了。比如下面這兩張圖，展示的就是接入了「吐個槽」平台之後，呈現在產品上的入口，以及用戶提交反饋的入口。（官方文檔地址：https://tucao.qq.com/dashboard/dev/index）

在用戶提交反饋之前，根據歷史的用戶反饋，或者參考同類型的產品，我們可以大概給用戶的反饋分分類，既可以引導用戶快速定位到與自己的問題類似的相關問題，也可以幫助產品團隊預先對反饋進行分類整理。功能入口在【管理後台】-【設置】-【反饋分類】。「吐個槽」平台提供了支持三級問題配置的分類功能。例如，我們可以這樣使用這三級配置：

• 一級分類，用來設置問題相關的產品、或功能模塊；
• 二級分類，用來設置一些更加細節的場景。比如，用戶遇到了功能失靈、以外退出等，或者只是在特定的場景下覺得使用不便、存在體驗問題。在這里不建議直接具體到BUG、交互體驗等分類方式，畢竟用戶很難從自己的角度將問題放到這些分類里邊，應當盡量採用貼近用戶「語境」的描述方式。
• 三級分類，就可以對二級中的場景進一步細化，比如「只在特定手機上出現」、「只在特定瀏覽器上出現」、或者「朋友也出現同樣的問題」等等。

通過這樣配置問題分類，我們就可以引導用戶提供更多有助於幫助解決問題的信息，同時也可以更容易幫助用戶在常見問題中選出那些可以直接幫助解決問題的內容。

2.3 廣義收集

前面我們已經說過了，大量用戶在面對不滿意的產品時會選擇「流失」，根本不會提供反饋，也就是前面說的「沉默用戶」。但是這樣的用戶，多多少少還是跟產品有些「交集」的。比如，這樣的用戶至少使用過產品的某些部分，在產品上留下了一些痕跡。或者，通過其它更「低成本」的方式進行了反饋，比如發了條微博罵了一下。對於這樣的反饋收集，就與前兩種收集方式有所區別了。

我們重點關注兩種管道的反饋收集——

2.3.1 數據分析中的反饋收集

在數據分析中，行為分析是大家熱衷的焦點之一。對於一般的用戶行為分析，從長遠來講，我們的主要目的還是希望通過找到一些規律，來預測用戶未來的行為。比如我們找到了用戶的某種特性與用戶流失之間的關係，就可以通過監控這種特性的變化，及時挽留用戶。

除此之外，用戶行為方面的數據分析也可以幫助我們解決一些眼前的問題。比如現在的一些第三方數據分析平台（比如Google Analytics），就提供了行為路徑的匯總統計和可視化的工具。當我們著眼於用戶最終的轉化行為時，行為路徑分析可以幫助我們呈現由不同路徑而來、並最終完成轉化的用戶量和其它指標。如果這些路徑與我們的預期不一致，而且有相當數量的用戶走了常規路徑之外的路徑，就足以發現產品設計中的問題。（如下圖）

2.3.2 第三方平台的反饋收集

當我們說到收集用戶反饋的時候，這類的第三方平台也是經常登場的。不過從這種第三方平台收集到的反饋，內容的質量就不敢保證了，可能文不對題、內容寬泛而缺少核心主旨、言語污穢等等。

這樣的平台大致可以分為幾類：

• 問答平台：對於習慣提問的用戶，當遇到問題時，可能首先想到的就是問答平台了。在這些平台上，用戶的反饋會以提問和回答的方式出現。比如問某個產品的具體操作方式，探討某個產品的功能迭代和發展方向等等。
• 社交平台：社交平台應該是最讓用戶心情放鬆的平台了。一方面這些平台聚集了各路親朋好友，另一方面平台自身也會不斷評估用戶的喜好，向用戶推薦符合喜好的內容。因此，在這種放鬆的狀態下，用戶更容易留下自己的一些真實想法。從這些平台上收集反饋也是個不錯的選擇。
• 應用市場平台：除了在產品內部，這是第二主要的反饋來源了。尤其是像App Store這種相對封閉而集中的市場，更便於產品團隊收集與自己相關的用戶反饋信息。相比之下，數量眾多的安卓市場就沒那麼樂觀了，當然也還是有據可循的。另外也可以通過下面要提到的應用分析平台輔助解決。
• 應用分析平台：大名鼎鼎的App Annie就是這個分類下的翹楚，並列的還有七麥數據（原ASO100）等等。這些平台對各大應用市場的數據進行了收集整理。相對於前面那種直接獲取反饋的方式，從這些平台獲取經過整理的數據會更加高效。當然，這些平台也會把一部分服務劃定為收費服務。具體值不值得，就要看用戶反饋對於產品的價值了。

三、反饋的評估與分級

前面已經介紹了一大堆關於收集反饋的內容了。那麼收集完了就完了麼？當然不是。下面真正「硬核」的部分才剛剛開始。

3.1 評估影響

對於收集來的用戶反饋，第一步、也是最最重要的一步，就是評估影響。（按理說，在收集之後最直接的下一步應當是歸類整理。但是只要對產品足夠了解，這一步不管是鋪人力做還是上算法做，都不會遇到太大的「認知門檻」。所以這里暫時忽略。）同時，這個環節還需要大量的數據支持。

3.1.1 為什麼要評估影響？

我們都知道，影響越「大」的反饋必然越重要，需要優先處理。也就是說反饋的影響程度決定了反饋的重要性。那麼怎麼定義這個「影響大」呢？通俗的理解，影響範圍越大越重要、越深遠越重要、後果越嚴重越重要。

影響範圍下面會重點列出四個方面，先不細說。

影響深遠指的是會不會影響產品的迭代和發展方向？會不會影響產品現有的功能結構和技術架構？會不會影響產品的整體風格等等。如果對這些重要的方面有所影響，就需要格外重視。

而後果指的就是那些公司或團隊關心的指標，尤其是KPI相關的指標。比如盈利是否減少、市場占有率是否下降、品牌形象是否受損等等。

3.1.2 怎麼評估影響範圍？

在具體操作中，我們可以從四個方面評估影響範圍，分別是用戶、場景、產品和團隊。

• 用戶中的範圍：這個比較好理解，就是說多少用戶面臨類似的問題。當然功利地講，不同用戶對於產品的價值也是不同的。比如對於新產品，如果核心種子用戶受到了影響，就會比其他嘗試型用戶重要得多。
• 場景中的範圍：這個比較有意思，把控起來也需要一些經驗。有些反饋在特定的時間、特定的產品版本中才是問題，脫離了這些場景就不再是問題了。比如，雙十一期間由於訂單量極大，才會出現服務器響應緩慢之類的問題，但過了雙十一就不再是問題了。再比如，產品的特定版本存在問題，如果說服用戶更新到最新版本，就沒問題了。對於這類問題，可輕可重，要根據所處的時間點和其它因素綜合判斷。
• 產品中的範圍：也就是影響到了產品的哪些部分。用戶的反饋是針對某個具體的功能提出的？還是針對某一個模塊提出的？再或者是遍布整條產品線，乃至整個產品組合的問題？當然，這其中還要考慮，出問題的模塊在整個產品形態中的重要程度。比如對於電商平台，圖片服務和支付服務如果出現問題，將會成為整個產品線的災難。
• 團隊中的範圍：這部分已經有點工程的味道了，就是說有多少相關團隊需要共同合作來解決這個問題。在分工明細的大公司里尤其常見。這種工作決定了需要投入多少成本來解決一個用戶反饋中的問題。後邊的工程落地部分會詳細說。

3.1.3 使用「吐個槽」評估影響範圍

「吐個槽」平台中有兩項功能能夠幫助我們完成影響範圍的評估——反饋篩選和導出。

反饋篩選功能位於【管理後台】-【管理】-【反饋列表】頁面的右上角。可用的篩選條件包括：反饋分類、反饋時間和反饋關鍵詞。比如，我們可以篩選出：

最近一周認為我們的新功能「不好用」的反饋。通過這樣的方式，我們就能評估出關於一個問題，到底有多少用戶收到了影響。

當然，這只是簡單的篩選反饋的例子，在「吐個槽」平台中的實際用戶反饋可能比這個複雜的多，相應的也需要更專業的工具進行分析。這時，我們就需要通過「吐個槽」平台的導出功能，獲取到原始數據，在進行下一步分析。

導出功能同樣位於【管理後台】-【管理】-【反饋列表】頁面的右上角，與「設置顯示字段」功能並列。點擊後，可以獲得用CSV格式保存的用戶反饋詳細內容，並且不受「設置顯示字段」的限制，可以獲得全部字段。

3.2 分級與細化

3.2.1 通用的分級標準

經過以上評估，我們就知道用戶的一條反饋到底重不重要了。但這還是一種定性的描述方式，不夠精準，需要量化。比較簡單可行的辦法，就是進行分級。

5級的分級是最常用的。分得再少就缺少了一些中間狀態，有些問題不知道怎麼歸類；但分得再多又太過瑣碎，各級之間區分度不明顯，不好操作。簡單的5級就可以分為：嚴重、比較嚴重、一般、比較輕微、輕微。再結合前面說的影響評估做較差，我們就可以制定出具體的劃分標準了。

比如下面的例子：

整體而言，分級是為了最優化地分配團隊的有限資源。集中資源修復那些影響巨大的問題。這在工程落地的階段表現的最為突出。

3.2.2 「吐個槽」平台的反饋分級

我們在這一部分說了對於用戶反饋的幾種評估和細化方法。對於「吐個槽」平台，我們已經很明顯的感受到其「論壇式」的用戶交流風格了。因此，在對於內容的分級方面，「吐個槽」同樣使用了與論壇類似的分級方式，讓用戶更容易理解。

首先，我們可以金融【管理後台】-【管理】-【反饋列表】頁面。在這個頁面選中一個或者多個用戶反饋之後，在頁面上方就會出現一排專門用來處理用戶反饋的功能按鈕。在這里，我們著重介紹三個「論壇風」的按鈕——「置頂」、「標記為精華」和「標記為水軍」。

其實不需要過多理解， 從字面上大家就能輕鬆明白它們的含義。「置頂」產生的結果，主要是用戶反饋的帖子會成為列表中的第一項。團隊成員每次打開列表，都會格外關注那些置頂的反饋，體現了反饋內容的重要性。「標記為精華」則更側重於內容質量好，這里不僅是用戶反饋的內容質量好，還可以是團隊回復用戶的內容質量好，對其他用戶有幫助參考意義。「標記為水軍」當然正好相反，指的是反饋帖子的內容不好。

四、反饋的落地優化

這部分就是前面一直在說的工程部分了。這也是大家做產品的同學最常見的場景——需求、評審、研發、測試、上線的過程。與工程相關的常規工作，我們就不再多說了，重點說一些跟反饋有關的東西。

4.1 「吐個槽」的處理流程與工程初探

作為一個用戶反饋平台，其實「吐個槽」是考慮到了團隊之間的溝通與功能落地的。其工作流程應當大致如下——

• 當用戶提交了反饋，負責經營的同學首先需要把控內容的質量，對它標記精華、操作置頂或者標記水軍；
• 之後，如果是需要後續處理的反饋，選中之後可以點擊「待處理」按鈕，表示需要後續工作；
• 再之後，當用戶反饋的問題處理完時，可以批量選中相關的問題，並統一回復給用戶。如果反饋本身不需要額外處理，也可以使用同樣的方法，直接批量恢復用戶。

在這個過程中，一條被標記了「待處理」並且「置頂」的反饋，將會始終提醒著相關的負責人關注其進度。目前感覺還欠缺的一點是，目前只有一個待處理的狀態，並沒有根據互聯網產品實際的迭代節奏，對這個狀態再進行細分，給用戶更明確的反饋。比如像這樣：

• 待處理；
• 處理中；
• 處理完成。

這些狀態，第一是給用戶看的，讓用戶知道自己的反饋的最新進展；其次是給團隊成員看的，了解這個問題已經在處理中了還是無人問津的狀態；再次，留下了這個概念之後，後續可以從這個點出發，讓「吐個槽」平台與其他平台更好的融合，共同支撐迭代的落地和監控。

4.2 反饋平台普遍面臨的工程問題

「吐個槽」平台在用戶反饋層面為經營和客服同學給予了支撐，接下來就到了產品團隊層面的需求梳理階段。既然到了需求階段，自然要有明確的待解決問題、目標、方案和價值評估。好在這些問題我們已經在前面做了大量鋪墊——

• 各種方式的反饋收集，為工程實踐提供了需求池的內容來源；
• 了解用戶的行為路徑，提供了用戶視角的最佳實踐和測試Case的沉淀；
• 影響評估，為工程實踐提供了優先級評估、工作量評估、人員分配、技術方案和架構調整等多方面的參考。

但是任何團隊的資源都是有限的。在有限的資源面前，我們還會面臨其它一些具體的問題：

• 用戶的反饋，如何「搬運」到團隊協作和項目管理中？
• 如何讓團隊有效地圍繞反饋進行協作？
• 緊急情況，如何排除人工低效的影響因素？

4.2.1 「搬運」與系統打通

針對「搬運」，前面關於用戶反饋的5個關鍵點中，我們提到了系統化、自動化的問題。簡單凝煉成兩個字，就叫「打通」。在這方面，貼近技術的工單式用戶反饋平台是具備天然優勢的。用戶的反饋直接與任務和團隊協作系統打通。這種做到方式在客服團隊比較常見，可惜的是，客服團隊到具體執行團隊之間的鏈路上，容易出現大量的人工操作，降低了效率。

這種系統打通，表面上看不會提供多少可見的短期價值，但是對於團隊整體的緊密配合有很大的幫助；同時又能堵住大家都很忙、「人力莫名流失」的漏洞。這種機器能輕鬆搞定的事情，還是應當交給機器來做。

4.2.2 反饋的自動化反饋

（註：吐個槽目前已經做到每日/每周/每月的微信推送簡報，以及企業微信群周報機器人功能。）

要讓團隊有效的圍繞反饋進行協作，重要的一步就是信息同步。信息有斷檔，大家的認知就無法統一，自然效率低下。

前面提到過反饋的反饋，也就是讓用戶知道自己提的問題處理到什麼進度了。可想而知，這個工作如果要用人工來做，特別是在大公司，很可能變成是一項跨團隊的巨大工程——產研團隊、客服團隊、BD團隊甚至還有更多。在這種人力損耗面前，系統化的價值就大大凸顯出來了。

另一方面，團隊也需要更高效的獲取到用戶反饋的相關信息。當用戶提出一個問題時，除了直接相關的問題描述、分類等信息，還需要獲得這位用戶最近的行為軌跡、偏好預測等非敏感信息，以及與這位用戶類似的其他用戶的非敏感信息。這都有助於執行團隊在充分了解狀況的前提下，高效地解決問題。

4.2.3 緊急情況

這種可能是老板們比較頭疼的狀況。在一些緊急情況下，即便麾下千軍萬馬，卻有力不從心的感覺。這里邊的問題，還是效率的問題。

第一，要說的是工具效率的問題。比如在用戶面前直接大顯身手的客服團隊，就需要為其設計強大的支撐工具。當用戶一個電話打進來，與用戶相關的信息都要及時傳遞給接待的客服同學；同時還要有配套的操作工具來幫用戶實際地解決問題。最差情況，就算當時無法立即解決用戶的問題，也要為客服同學提供一個簡單好用的記錄工具，這同樣是用戶反饋的收集過程。

第二，要說的是人的效率的問題。比如需要人工進行系統修復的過程，從理解系統拋出來的那些複雜的報警信息，到找到出問題的點，再到最終修復問題，這個流程相當長。再加上如果是大團隊，效率可想而知。怎麼辦？幾套常見情況的應急預案是「必備良藥」。人的行為慣性相對於深思熟慮要高效得多。提前準備預案並經常演練，是做到人的高效的好辦法。

第三，那麼還有沒有更好的辦法呢？我們下個部分再說。

五、發展的大方向

5.1 用戶反饋平台的通用發展方向

前面我們已經將用戶反饋從各個角度進行的拆分：

• 從感情態度上，區分積極與消極用戶的基本訴求；
• 從收集方式上，區分了定向、常規和廣義收集；
• 從重要程度上，給了5級分級方法；
• 從自動化上，評價了人工和自動的應對方案及提高效率的方法；

但在前一部分的末尾我們留了個小問題——對於緊急情況，我們有沒有更好的辦法呢？當然有！就是讓緊急情況別發生！也就是從「處理」走向「預防」的方向。這就像著名的「質量免費」觀念一樣。

我們前面提到了，可以通過用戶行為分析，來沉淀用戶視角下的測試Case。我們收集的大量用戶行為Case，其使用場景可不僅僅是對新功能進行自動化測試。根據這些基礎數據，我們理應比用戶更早的「反饋」問題；等到用戶找上門來，我們就應當能拿得出像樣的解決方案了；或者直接在用戶準備提交問題的時候給出解決引導；或者再往前，直接進行產品優化，將問題扼殺在搖籃里。

當然做到這個目的並非易事，我們總結一下本文中提到過的「三座大山」：

1. 信息同步：即盡可能的，在那些與處理用戶反饋相關的團隊之間做到信息同步，而不是讓產品或者經營團隊孤軍奮戰；
2. 價值取向：這會體現在各種標準的制定上。還記的前面那張《用戶反饋評估表》嗎？那些標準應當在你的團隊里達成一致意見。
3. 觀念轉變：這是前面最後這部分提到的。就是好的產品質量是免費的，我們是在為糟糕的產品質量投入大量成本，而不是在為改進產品的過程投入成本。這可能會要求團隊成員付出一些看似「額外」的努力，但這些努力會帶來客觀的回報。

當然，預防不代表對用戶反饋「趕盡殺絕」，與用戶的直接溝通，依然是獲得一手資料的最佳途徑。

5.2 針對「吐個槽」平台的發展方向建議

前面已經提到了一些關於「吐個槽」平台的建議，我們在這里匯總一下，作為未來發展方向的總體建議：

• 在數據來源上，目前「吐個槽」平台主要是從實際用戶的角度，提交文字描述、配圖附件等相關內容。未來，為了豐富更多維度的數據來源，需要在數據源上更豐富，比如：做到從其他系統讀取數據，或者支持手動導入數據。
• 在管理後台中，為經營同學增加更多可供標記的內容。前面主要提到了關於處理狀態的豐富，其實在這個點上還可以擴展出其他類型的達標標籤，比如體驗優化項目相關的、負責人相關的、最終問題定位相關的等等。
• 有需要工程落地的反饋存在，這就要求在反饋平台上體現一些「工程特性」。「吐個槽」平台加入了「待處理」狀態是一個絕佳的開始。後續在這個方向上，還可以補充「分配到管理員」等圍繞任務和工程的特性。

• 用戶反饋平台的理想狀態，就是能最大限度的降低那些普通又頻發的問題的處理成本，比如少投入人力、多應用自動化和智能方案。而基於「吐個槽」平台目前的功能結構，可以考慮的是通過用戶反饋數量自動提取「常見問題」，變成半人工半自動的做到方案。這樣人工只需要關注那些判定錯誤的反饋就可以了。

合作夥伴