前一陣子，公司的客服回報：「客戶又打電話來了，說功能有問題。」
但是客服主管礙於部門提升效率的KPI，無法花時間去釐清並解決真正的問題，只能告訴公司的客服同仁，說他們解決問題的動作太慢了，要想辦法降低跟客戶的通話時間，越快處理完客訴電話越好。
聽起來很合理吧？縮短處理時間就等於提升效率。結果就是，客服開始講話語速變快、回答的內容變短，甚至略過細節或是忽視客戶的情緒，只為了快速把接起來的電話掛掉。
但是客戶的問題真的被解決了嗎?
客戶想要解決產品使用上的問題，他真的在乎要多花一點時間來處理嗎?少花一點時間但是無法完全解決問題，甚至是無法解決問題，是客戶想要的嗎?還是其他利害關係人的需求呢?
有時候，從一開始，真正的問題就被定義錯誤了。常造成定義錯誤的原因有：
你看到的是「結果」，不是「問題」
銷售額下滑，你以為是廣告打的不夠。
用戶在網頁的留存變低了，你以為是 UI 不夠漂亮所造成。
客訴變多了，公司以為是客服太雷或是程度太低，沒有辦法解決客戶的問題所導致。
很多時候，你看到、聽到、想到的其實是症狀，而不是造成問題的根本原因。
如果只是想辦法處理這些表象，最後的結果，可能是公司倒閉。
就像是發燒了，以為只是單純的感冒，自己買個退燒藥吃就好。
卻不知，其實是前幾天被割傷的小傷口，變成蜂窩性組織炎造成了發燒。
到最後，運氣好一點，早點發現還有救。運氣不好，可能就需要截肢或是來生再見。
你定義的是「錯誤命題」，根本沒法解決實際問題
有次公司高層說：「我們的客戶滿意度太低，要提升客戶滿意度，這樣才有辦法接到新訂單。」
事實上，公司的產品已經是上個世代的產品了，公司並沒有針對產品品質及功能設計去做更新優化。
反而是要求客戶幫忙按五星好評。
真正的問題在於客戶需要新功能以因應市場的新需求，沒有滿足客戶的實際需求，營業額真的有辦法提升嗎?
問題還沒定義清楚前，就進入解決問題的模式
某次專案開會時，客戶要求：「我們想加一個 A 功能。」
公司馬上指派研發單位進行開發，研發單位整組人花了三個禮拜，加班加點搞定。
結果客戶說：「這不是我要的。」
後來追問後才發現，客戶真正要解決的其實是 C 問題，而不是要A功能。
而且，公司既有的產品本來就有 B 功能可以處理客戶要解決的C問題。
公司沒有先釐清客戶的真正需求，就急著提供解法，結果浪費資源，白忙一場。
不是解決問題的行為有問題，而是一開始連要解決什麼問題根本就沒定義清楚。
你問錯人了
客戶的 PM窗口專業能力很強，所以怎麼樣複雜的設計跟操作都難不倒他。
我們以為客戶端的使用者程度都跟PM窗口一樣好，於是產品設計的操作流程都以他為主來進行。
但是當產品交付之後才發現，真正的使用者根本就沒辦法順利使用。
操作流程太複雜、邏輯不直覺，甚至錯一步還得全部重做。
更慘的是，一開始測試的時候，大家看到錯誤發生，直覺反應竟然是使用者怎麼這麼粗心？
問題是可以被「定義清楚」的
真實世界裡，我們不可能要求客戶一次就講對自己的需求，
但是可以透過合理的流程步驟，幫助團隊把客戶的問題定義正確。
- 建立客觀事實現象，不急著下判斷
像是客戶來電次數升高，重複詢問率上升。不要直覺反應是客服太爛無法解決客戶問題，所以客戶重複詢問率才會上升。 - 確認理想狀況與真實現況的差距
理想狀況是每件反應 1 次解決，現況是平均要 2.7 次才能解決客戶的問題。確實清楚差距才能定位問題的嚴重程度。 - 問自己5 個Why已確認真實原因
每多問一次為什麼，離真正的問題原因就更近一步。 - 寫下具體的問題陳述
將客觀事實陳述、理想狀況與真實現況的差距還有初步判斷的根本原因寫下，讓團隊聚焦找出真正的問題。 - 確認邊界與影響層面
找出問題後，還要確認這個問題影響哪些人？影響範圍有多大？問題有沒有開始蔓延？這樣可以讓你決定問題處理的優先順序。
下一次遇到問題時，不要看到黑影就開槍。先問自己：真正的問題是什麼?
