把每一則回饋都當成待辦事項的團隊，最後會做出一個誰都不討厭、但也沒有人特別需要的產品或服務。
以客為尊是幾乎沒有人會反對的原則，也因此很少被仔細檢視。實務上它經常被執行成一個簡單的規則：客戶提出的每一個要求都要想辦法滿足。這在服務初期通常有效，因為那時候你需要的正是快速貼近真實需求。但當客戶數量成長之後，這個規則會開始產生問題，因為不同客戶的要求會互相衝突。
衝突發生時，照單全收的組織會採取一種看似合理的解法：兩邊都做，用選項或設定來滿足。這就是複雜度開始累積的起點。三年之後你會有一個功能繁多、選項複雜、新客戶需要教學才會用的產品或服務，而每一個複雜度都可以追溯到某一則被認真對待的回饋。
絕大多數的回饋抵達你手上時，都已經被客戶自己翻譯成表層要求了。這是自然的，因為人習慣提供解決方案而不是描述問題。問題在於，客戶的解決方案是在他對你的產品或服務有限的理解下想出來的，未必是最好的做法，甚至常常會與其他人的需求衝突。
所以收到回饋時的第一個動作不是排進待辦，而是往下追兩層。追問的方式很簡單：可以請問你目前是怎麼處理這件事的、以及如果這個功能有了，你接下來會做什麼。這兩個問題通常能在三分鐘內把表層要求還原成底層目標，而還原之後你會發現，五則看起來不同的回饋可能指向同一個問題。
第二項在實務上最常被忽略。所有回饋都被平等對待的組織，會不自覺地被聲音最大的客戶牽著走，而聲音最大的通常不是最有代表性的。合理的做法是在記錄回饋時同時標註來源客戶的類型，累積三個月之後你會看到一個清楚的分布，也就知道自己過去的資源實際上流向了哪一群人。
第一是複雜度累積，前面已經談過。第二是方向感喪失：當每一次的優先順序都由外部聲音決定，團隊會逐漸失去自己的判斷，也說不出這個產品或服務究竟為誰而做。第三是最隱蔽的，就是它會擠掉那些沒有人提出但真正重要的改善，因為沒有客戶會主動要求你去修一個他還不知道存在的問題。
第三項值得多說幾句。客戶的回饋只能涵蓋他們意識得到的範圍，而許多最有價值的改善來自於觀察行為而非聽取意見，例如發現多數人在某一步驟停留特別久、或某個功能被用在完全不是設計本意的地方。如果你的優先順序完全由回饋清單決定，這一類洞察永遠排不進去。
不採納某個要求時，最糟的處理是不回應或含糊帶過。比較好的做法是回到底層目標：告訴對方你理解他真正想解決的是什麼，說明你們目前用什麼方式處理那個目標，以及為什麼暫時不採用他提出的做法。多數客戶要的不是那個功能，而是他的問題被認真看待。
另外建議建立一個公開的處理原則，例如我們會優先處理重複出現且與核心用途相關的需求。有了公開的原則，個別的婉拒就不再是針對某個人的決定，而是一個一致標準的結果。這一點對維持長期關係非常有幫助，也能減少業務端的壓力。
最後想說的是，認真對待回饋與照單全收是兩件不同的事。前者需要投入時間去理解，後者只需要把它排進待辦。真正尊重客戶的做法是花力氣搞清楚他要什麼，然後用你的專業判斷給他最好的解法，而不是把判斷的責任推回給他。
不需要專案管理系統，一份共用表格就夠。欄位建議只有六個：日期、來源客戶類型、原始說法、往下追兩層後的底層目標、出現次數、以及目前狀態。原始說法那一欄務必保留客戶的原句而不要改寫，因為原句的措辭本身就是資訊，日後做內容規劃時可以直接使用。狀態欄只需要三種：觀察中、已處理、不處理但已回覆。
每個月花三十分鐘檢視一次這份表格，重點不是逐條處理，而是看有沒有哪一個底層目標的出現次數跨過了門檻。門檻要事先定義，例如三個月內來自理想客戶的相同目標出現三次以上。有了明確的門檻，優先順序就不再依賴誰的聲音大或誰最近才提過，而是依賴一個團隊事先同意的規則。
前面提到最有價值的改善往往來自觀察而非意見，這裡補充實際的做法。最低成本的方式是每季挑三位客戶，請他們在你面前實際操作一次他們平常會做的事，過程中你只看不說話，也不要在他卡住時立刻幫忙。半小時的觀察通常會發現兩三個從來沒有人反映過的問題，因為使用者已經自己找到了繞路的方法，久而久之就不覺得那是問題了。
把觀察到的問題與回饋表格上的項目對照，你會得到一個更完整的優先順序。有些回饋看起來很急，但觀察後發現只有少數人會走到那一步；有些從來沒有人提過的環節，卻讓每一個人都停頓了三十秒。這種落差正是為什麼不能只靠回饋清單來決定方向。
另外提醒把不處理但已回覆的那一類回饋也記錄下來並統計數量。當某個被歸類為不處理的目標在半年後累積到一定次數，就該重新評估當初的判斷。回饋處理最怕的不是拒絕，而是拒絕之後就再也沒有人回頭看那個決定。