處理用戶反饋時(shí),我總結(jié)的幾點(diǎn)經(jīng)驗(yàn)

白啦
20 評(píng)論 41444 瀏覽 231 收藏 12 分鐘
🔗 产品经理的不可取代的价值是能够准确发现和满足用户需求,把需求转化为产品,并协调资源推动产品落地,创造商业价值。

本文是筆者在處理反饋時(shí)總結(jié)的經(jīng)驗(yàn),可能和你在做的有一些不一樣。不過,用心去對(duì)待用戶,認(rèn)真對(duì)待每一條反饋,我相信肯定都是一樣的。

互聯(lián)網(wǎng)的用戶支持和傳統(tǒng)客服的重要區(qū)別在于:相比于客服被動(dòng)地響應(yīng)用戶的問題,用戶支持更多的會(huì)主動(dòng)出擊,發(fā)現(xiàn)并解決問題。

以前做這部分工作的時(shí)候,是借助于一款協(xié)作軟件去開展的,這里不提名字了。我最初是覺著這樣的事情做起來沒什么意思,直到慢慢的摸索出這樣一套流程來,算是這部分工作最直接的收獲了。

我想你可能已經(jīng)留意到了,它是一個(gè)閉環(huán)的流程。

一、需求收集

1、用戶反饋

要給用戶留下可以聯(lián)系你的渠道,一般說來有以下這些:

  • 用戶反饋郵箱
  • 產(chǎn)品反饋后臺(tái)
  • 用戶群(QQ 群/微信群等)
  • 新媒體(公眾號(hào)、微博等)
  • 第三方社區(qū)(知乎、豆瓣、貼吧等)
  • 其他(應(yīng)用市場、公關(guān)稿、辦公室的一聲吼…)

用戶會(huì)通過這些渠道把使用過程中遇到的情況反饋過來,反饋通常分為以下幾類:

  • 產(chǎn)品 bug
  • 吐槽
  • 功能建議
  • 其他(比如,以前聽到多位用戶來打聽 CEO 有木有女盆友的…)

(1)產(chǎn)品 Bug

如果用戶描述的很清楚,我通常會(huì)自己動(dòng)手看看能不能捕捉到這個(gè) bug(嗯,「人肉」測(cè)試下),然后報(bào)給團(tuán)隊(duì);如果描述的不是很清楚,就按照技術(shù)猿們問我們的套路來向用戶收集信息:平臺(tái)、版本、頁面、操作……

話說后來有一天,我知道有一種工具,是可以在出現(xiàn) bug 時(shí),直接精準(zhǔn)到導(dǎo)致出錯(cuò)的那一行代碼,根本不需要問用戶雜七雜八…我承認(rèn)那一刻,我其實(shí)內(nèi)心深處真的是很想問候下,當(dāng)年那些不尊重我們時(shí)間的猿們…愿你們有一天也要直面用戶的怒火,然后持續(xù)個(gè)百十天。

(2)吐槽

很多原因?qū)е掠脩敉虏?,交互設(shè)計(jì)、頁面設(shè)計(jì)、操作流暢度、業(yè)務(wù)流程等,但通常都是用戶感到非常沮喪時(shí),才會(huì)引起吐槽。所以,在和吐槽用戶的交涉過程中,多含一些同理心吧。

當(dāng)然,吐槽真的很容易讓人產(chǎn)生負(fù)面情緒,有段時(shí)間看吐槽多了,負(fù)能量爆棚,就天天想要逃避用戶…但是,不得不承認(rèn),很多的吐槽都是有價(jià)值的,爭取引導(dǎo)用戶說出來,找到問題。如果實(shí)在累了,就休息幾天調(diào)整調(diào)整心態(tài)吧。

(3)功能建議

功能建議分為兩大類:新增功能、功能優(yōu)化。這部分是反饋的重點(diǎn),下文慢慢說。

2、反饋收集

在進(jìn)行需求收集的時(shí)候,可以從以下幾個(gè)方面考慮:

(1)用戶畫像

了解下反饋用戶的基本信息,性別、職業(yè)、年齡層、收入等,這通常與我們所運(yùn)營的產(chǎn)品相關(guān),了解下是否是目標(biāo)用戶提出的需求。

(2)用戶場景

用戶提出這個(gè)需求的原因是什么,在什么樣的情況下,想完成什么事情,做了哪些操作,結(jié)果如何?這些信息非常有助于團(tuán)隊(duì)成員理解需求。

(3)產(chǎn)品信息

了解用戶使用的是哪個(gè)客戶端(web、iOS、android、WP等),使用的版本號(hào)。很可能反饋的需求在新版本中已經(jīng)解決了,但用戶沒有升級(jí),所以并不知曉。

(4)用戶聯(lián)系方式

記錄下用戶的聯(lián)系方式,這條很有用,一方面用于統(tǒng)計(jì)分析,一方面為了完成反饋的閉環(huán)。通常,用戶通過哪個(gè)渠道反饋的,就記錄下該用戶在這個(gè)渠道下的聯(lián)系方式,如QQ號(hào)、郵箱、評(píng)論鏈接、電話等。

3、反饋處理

(1)已知需求

很多時(shí)候,用戶的反饋是團(tuán)隊(duì)已知悉的,對(duì)于已知悉的需求,通常我會(huì)告訴用戶團(tuán)隊(duì)對(duì)這個(gè)需求的考慮,以及大概的開發(fā)計(jì)劃(一定記得給團(tuán)隊(duì)留點(diǎn)時(shí)間,不要向用戶透露具體時(shí)間,除非這件事是板上釘釘,絕不會(huì)改變的,而這種情況是極少的)。時(shí)間允許的情況下,還可以和用戶一起聊一聊對(duì)于解決方案的看法。

(2)新需求

對(duì)于新的需求,作好記錄的同時(shí),也不忘告訴用戶,你的反饋已經(jīng)收到啦。

(3)使用問題

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

二、需求管理

1、需求記錄

用戶反饋在經(jīng)過篩選整理后,有很多建議會(huì)被放到需求池。通常建議是和產(chǎn)品迭代聯(lián)系在一起的,舊的去了,新的又會(huì)來。所以,就需要對(duì)需求池進(jìn)行管理。

(1)歸類

如果用戶的反饋在之前已經(jīng)有類似的反饋,只需要將相同的建議統(tǒng)一在一處即可,不需要單獨(dú)開新的需求;而對(duì)于同一功能模塊下的需求,也可以歸集在一處,按照不同模塊來簡單分類;而具備上下游關(guān)系的多個(gè)需求,可以進(jìn)行關(guān)系的梳理,待上游的問題解決后,下游的需求可能自然就對(duì)應(yīng)的解決了。

(2)次數(shù)

對(duì)于相同的需求,記錄有多少用戶反饋過,從反饋總次數(shù)的維度了解用戶比較關(guān)心的幾個(gè)問題。這里要注意,并不是反饋的次數(shù)多,這個(gè)需求就一定是重要到非做不可的。一個(gè)需求能不能做,還需要考慮公司對(duì)產(chǎn)品的戰(zhàn)略規(guī)劃、占用的開發(fā)資源以及開發(fā)難度等問題。對(duì)于需求的考慮需要單獨(dú)討論,這通常也是產(chǎn)品經(jīng)理考慮的問題,這里先不展開了。

(3)頻次

顧名思義,頻次就是在一定時(shí)間內(nèi),同一個(gè)需求反饋的次數(shù)。這個(gè)是從緊急度的維度去看一個(gè)需求。通常,會(huì)在新版本上線后,重點(diǎn)留意這個(gè)維度。如果新版本上線后一段時(shí)間,有多個(gè)用戶反饋了同一個(gè)問題,那可能新版本出現(xiàn)問題了,就要及時(shí)通知團(tuán)隊(duì),但是立即修復(fù)發(fā)新版,還是回滾到之前的版本,就要看團(tuán)隊(duì)的考慮了。

2、進(jìn)度跟蹤

(1)對(duì)用戶

其實(shí)和用戶交流就像和一個(gè)正常的朋友打交道一樣,交朋友很重要的一點(diǎn)就是,讓對(duì)方知道你是靠譜的。那怎么讓用戶感受到你是靠譜的呢?我的建議是:做產(chǎn)品的專家。

在用戶張嘴的時(shí)候,就能判斷出大概是什么問題,解決方案有哪些,最合適該用戶的方案是什么;如果現(xiàn)在沒有解決方案,那么這個(gè)問題在不在團(tuán)隊(duì)的考慮范圍內(nèi),如果不在,原因是什么;如果在考慮了,目前在什么階段了,大概的解決時(shí)間和解決方案是什么。最后用戶容易接受的方式告訴用戶原因。不用擔(dān)心這樣的舉動(dòng)會(huì)導(dǎo)致用戶流失,說實(shí)話用戶未必就不能接受,和套話、空話相比,說實(shí)話給用戶的體驗(yàn)可能更好。并且有些用戶的流失真的不可避免,因?yàn)榇_實(shí)不在服務(wù)范圍內(nèi)。

也許你的用戶有來自各個(gè)領(lǐng)域的領(lǐng)袖人物,但是確保在自家產(chǎn)品上,你是領(lǐng)袖。專業(yè)的知識(shí)總是令人信服的,也是最容易樹立威望的。

(2)對(duì)團(tuán)隊(duì)

進(jìn)度跟蹤一方面要參與到團(tuán)隊(duì)內(nèi)部的需求決策過程中來,在產(chǎn)品決策的時(shí)候,要確保團(tuán)隊(duì)對(duì)用戶的意思理解正確,對(duì)于不確定的解決方案,還可以找?guī)讉€(gè)用戶實(shí)際了解下方案的偏好。

進(jìn)度跟蹤的另一方面,是要及時(shí)了解團(tuán)隊(duì)對(duì)需求處理的實(shí)際情況,比如,開發(fā)計(jì)劃有沒有被調(diào)整,開發(fā)進(jìn)度有沒有延期,設(shè)計(jì)方案和用戶期望有多大的差距…根據(jù)實(shí)際情況更新需求池信息,可以讓我們?cè)诿鎸?duì)用戶的時(shí)候,減少錯(cuò)誤信息的傳遞。

三、需求實(shí)現(xiàn)

1、產(chǎn)品更新

(1)通知反饋用戶

產(chǎn)品更新后,第一時(shí)間通過反饋收集環(huán)節(jié)記錄的用戶聯(lián)系方式去通知反饋對(duì)應(yīng)需求的用戶,這樣做的好處是:

  • 讓這些反饋的用戶能第一時(shí)間收到消息,獲得良好的反饋體驗(yàn);
  • 了解這部分用戶對(duì)新功能的看法,帶來新的反饋;

對(duì)于N久之前反饋的用戶,以一種友好的方式嘗試召回。

(2)發(fā)布更新消息

主動(dòng)反饋的用戶占比是不高的,大部分都是沉默用戶。因此,在產(chǎn)品更新后,要將針對(duì)新版本/新功能的更新內(nèi)容,通過建立起來的各個(gè)渠道發(fā)布出去,讓其他未直接反饋的用戶了解到更新信息。

2、歸檔/完成

需求的處理到這里并沒有結(jié)束,還需要對(duì)需求做個(gè)歸檔。在已解決的需求下記錄對(duì)應(yīng)的解決方案、更新版本、發(fā)布的時(shí)間,因?yàn)楹笃诜治鲇脩粜袨榛虍a(chǎn)品數(shù)據(jù)時(shí),如果遇到數(shù)據(jù)異常,可能需要從歸檔的需求里面找依據(jù)。

比如,回顧數(shù)據(jù)時(shí),發(fā)現(xiàn)上個(gè)月的某個(gè)功能使用率明顯提升,然后猜測(cè)是和上個(gè)月發(fā)布了新版本有關(guān),在需求池發(fā)現(xiàn),這個(gè)功能的優(yōu)化建議在上個(gè)版本實(shí)現(xiàn)了,這樣就可以幫助我們找到了一些異常發(fā)生的依據(jù)了。

以上是本人在處理反饋時(shí)總結(jié)的經(jīng)驗(yàn),可能和你在做的有一些不一樣。不過,用心去對(duì)待用戶,認(rèn)真對(duì)待每一條反饋,我相信肯定都是一樣的。

 

本文由 @白啦?原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 那個(gè)可以捕捉到bug并定位到具體某一行代碼的東東, 有很多, 舉個(gè)栗子: bugly 就可以, 類似于代碼檢測(cè)的, 雖然有bug產(chǎn)生的環(huán)境版本等信息, 但是并不能知道具體出現(xiàn)的路徑, 對(duì)于復(fù)雜的bug來說即使改了也不一定能準(zhǔn)確驗(yàn)證, 當(dāng)然對(duì)于低級(jí)bug來說很管用, 所以程序員詢問bug相關(guān)信息并不是在刁難產(chǎn)品哦~,當(dāng)然既然APP里集成了這種監(jiān)測(cè)工具, 說明程序員會(huì)定期去上面清理bug的. 大家要相互理解哦~ by一只正在轉(zhuǎn)產(chǎn)品的猿猿 ??

    來自北京 回復(fù)
  2. 畢竟功能迭代和優(yōu)化等很多問題都是涉及到產(chǎn)品而非運(yùn)營~

    來自北京 回復(fù)
  3. 產(chǎn)品經(jīng)理做用戶反饋應(yīng)該還容易些,那運(yùn)營人員要做用戶反饋 請(qǐng)問該如何提高產(chǎn)品思維呢?

    來自北京 回復(fù)
  4. 關(guān)于“我知道有一種工具,是可以在出現(xiàn) bug 時(shí),直接精準(zhǔn)到導(dǎo)致出錯(cuò)的那一行代碼”表示很好奇,我想應(yīng)該還是需要搜集到用戶具體在哪步操作、什么操作環(huán)境下等各種細(xì)節(jié)后,才能重現(xiàn)問題吧,所以不能怪開發(fā)人員吧?

    來自福建 回復(fù)
  5. Fabric 產(chǎn)品怎么用?

    來自廣東 回復(fù)
  6. Fabric確實(shí)可以定位到崩潰代碼到行數(shù),但要定位某一用戶反饋的問題好像不容易吧。

    回復(fù)
  7. 請(qǐng)問捕捉bug的軟件叫什么名字?

    回復(fù)
    1. fabric

      來自上海 回復(fù)
    2. 你知道 Fabric怎么用?

      來自廣東 回復(fù)
  8. 總結(jié)得很全面了,感謝作者分享

    來自北京 回復(fù)
  9. 最近也在處理同樣的事,整個(gè)環(huán)節(jié)的迭代的推動(dòng)還是需要多方協(xié)調(diào),也是最耗時(shí),最難的,不知道你們?cè)谔幚淼臅r(shí)候有啥高招?

    回復(fù)
    1. 這個(gè)確實(shí)不是一己之力能夠決定的。除了注意和各部門溝通的技巧之外,還有無其他?

      回復(fù)
    2. 哪個(gè)環(huán)節(jié)呢?

      來自上海 回復(fù)
  10. 【什么工具?】話說后來有一天,我知道有一種工具,是可以在出現(xiàn) bug 時(shí),直接精準(zhǔn)到導(dǎo)致出錯(cuò)的那一行代碼,根本不需要問用戶雜七雜八…

    來自浙江 回復(fù)
    1. 同問

      來自福建 回復(fù)
    2. 同問,就看到這個(gè)重點(diǎn)

      來自江蘇 回復(fù)
    3. fabric

      來自上海 回復(fù)
    4. 技術(shù)猿?

      來自上海 回復(fù)
    5. 我不是啦,fabric是運(yùn)維的工具。。。產(chǎn)品如何使用?

      來自江蘇 回復(fù)
    6. fabric

      來自上海 回復(fù)
专题
72294人已学习13篇文章
产品经理天天跟“需求”打交道,产品经理的核心价值就是处理“需求”的能力。
专题
53205人已学习15篇文章
无论是个人运营体系还是公司运营体系的构建,你都能在这里找到。
专题
15173人已学习12篇文章
用户体验五要素包括战略层、范围层、框架层、结构层、表现层五个方面,本专题的文章分享了用户体验五要素的看法。
专题
88173人已学习12篇文章
世间万物皆有套路,面试更是如此,多拿几个靠谱offer。
专题
40131人已学习22篇文章
不想当CEO的产品经理不是好运营
专题
17115人已学习14篇文章
RFM模型是与用户价值相关的常见模型之一。本专题的文章分享了什么是RFM模型?如何应用RFM模型?