當用戶提出須要一匹千里馬時，追問一句爲何

程序員客棧3.2今晚即將上線，隨着使用人數的愈來愈多，咱們也累積了愈來愈多的用戶反饋。咱們的開發猿已經日以繼夜了，可須要解決的問題依然愈來愈多。固然，這是好事，由於這意味着咱們的用戶和活躍度的確愈來愈高了，哥們兒要火了你知道嗎？

　　

　　客棧最近瀏覽趨勢

　　另一個方面，這也意味着，咱們必需要從各種碎片化的反饋中，識別真正的需求，排列出優先級別並實現。要作到第一步，是識別真正的需求。

　　看到過兩種大相徑庭的對待用戶反饋的態度：

　　1-只聽用戶的反饋，只要用戶反饋就記錄下來大會討論想辦法知足。

　　2-不聽用戶反饋的需求，只聽bug反饋。以爲用戶不懂需求。

　　前者自不可取：，用戶須要一匹千里馬的時候，你去知足他；因而他又提出須要一匹萬里馬呢？後者也過於武斷：用戶在使用過程當中即便沒碰到任何bug，但就是用得不順呢？我這麼看：

　　用戶提出的反饋，通常是基於使用過程當中觸發的問題（這是一個存在的事實）。他在和咱們溝通的時候，極可能就忽略了告訴咱們這個問題（事實）是什麼，直接提出要求（通過本身的經驗判斷給出的方案）。

　　咱們要作的，是先追問一句：爲何你會有這樣的反饋？你碰到什麼問題了麼？

　　還原問題以後，咱們再來判斷什麼樣的解決方案更合適。也許用戶的確牛逼，按照他的建議去作比咱們本身的方案更好，那就改唄；也許用戶的方案比較不完善，沒問題，咱們知道關鍵問題是什麼了，只要咱們可以更好地解決這一點，用戶只會驚喜不會有意見。

　　如下爲親身經歷的案例：

　　案例1：客戶在發佈項目的頁面直接進入與客服對話的狀態（恩，是的，目前我兼任客服:D)

　　客戶A:我提交審覈以後，大家尚未審覈完成以前，應該要增長一個功能，我應該還能夠修改項目呀，不然不方便。

　　客服喵：謝謝，您的建議咱們已經收到。請問爲何須要增長這個功能呢？

　　客戶A: 若是這個時候個人主意忽然變了怎麼辦？

　　客服喵：&……&……%）￥#@￥#（平靜一下子） （而後再回復）爲了不咱們審覈經過和報價的項目，和您最終提交的項目不是同一個項目，由此產生更多沒必要要的糾紛耽誤您的時間，提交審覈以後請不要再修改了哦。若是的確須要修改，請直接聯繫客服，咱們和您確認以後會先拒絕您的第一次申請，您能夠在原有申請基礎上修改好再次提交，而後咱們再審覈。

　　案例2：業務汪很着急地跑過來，要求增長一個新功能。

　　業務汪：後臺管理增長一個功能吧，用戶提交項目後咱們能夠幫他們修改。

　　產品喵：啥？咱們修改用戶的項目？爲何？

　　業務汪：客戶第一次填，不少內容沒有填寫好，咱們的填寫引導頁寫得不夠，我請他們從新填；第二次又填錯了，他們本身也懶得改，讓我直接幫他們改了，不然他們都懶得發佈項目了。。。

　　產品喵：若是咱們幫他們修改項目，意味着修改完以後還要獲得他們的確認，這在整個項目流程上便增長了兩步，何況，不多可以作到一次修改完成的，咱們的流程會變得很重，以後多少我的都服務不過來。

　　業務汪：也是，可這個問題很緊急，我若是不在後臺幫他們修改了他們也不肯意作了呀。

　　產品喵：這個問題，對於你而言，有兩種解決辦法：

　　1）經過遠程桌面控制工具，控制他的桌面幫他填寫完而後讓他檢查，提交；

　　2）讓他臨時修改本身密碼，再把帳號密碼給你，你修改好了以後還給他，讓他覈查沒問題後提交，而後修改回本身的密碼。對於產品自己而言，咱們要作的是增強產品的引導，儘可能減小用戶犯錯的機會。你看（喵調出已經好幾個屏幕長度的待優化列表），咱們上線前已經列下來了，只等完成此次的APP開發支持，立刻開始網站的優化。

　　案例x: 又一位客戶上線進入對話框。「我以爲大家須要增長一個功能。。。」