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

本文是筆者在處理反饋時(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)載。
那個(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)品的猿猿 ??
畢竟功能迭代和優(yōu)化等很多問題都是涉及到產(chǎn)品而非運(yùn)營~
產(chǎn)品經(jīng)理做用戶反饋應(yīng)該還容易些,那運(yùn)營人員要做用戶反饋 請(qǐng)問該如何提高產(chǎn)品思維呢?
關(guān)于“我知道有一種工具,是可以在出現(xiàn) bug 時(shí),直接精準(zhǔn)到導(dǎo)致出錯(cuò)的那一行代碼”表示很好奇,我想應(yīng)該還是需要搜集到用戶具體在哪步操作、什么操作環(huán)境下等各種細(xì)節(jié)后,才能重現(xiàn)問題吧,所以不能怪開發(fā)人員吧?
Fabric 產(chǎn)品怎么用?
Fabric確實(shí)可以定位到崩潰代碼到行數(shù),但要定位某一用戶反饋的問題好像不容易吧。
請(qǐng)問捕捉bug的軟件叫什么名字?
fabric
你知道 Fabric怎么用?
總結(jié)得很全面了,感謝作者分享
最近也在處理同樣的事,整個(gè)環(huán)節(jié)的迭代的推動(dòng)還是需要多方協(xié)調(diào),也是最耗時(shí),最難的,不知道你們?cè)谔幚淼臅r(shí)候有啥高招?
這個(gè)確實(shí)不是一己之力能夠決定的。除了注意和各部門溝通的技巧之外,還有無其他?
哪個(gè)環(huán)節(jié)呢?
【什么工具?】話說后來有一天,我知道有一種工具,是可以在出現(xiàn) bug 時(shí),直接精準(zhǔn)到導(dǎo)致出錯(cuò)的那一行代碼,根本不需要問用戶雜七雜八…
同問
同問,就看到這個(gè)重點(diǎn)
fabric
技術(shù)猿?
我不是啦,fabric是運(yùn)維的工具。。。產(chǎn)品如何使用?
fabric