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