企業如何從客戶聲音找到線索、驗證假設，透過 PDCA 將洞察轉化為改善行動
前陣子，一位朋友跟我說，他把手機裡用了很多年的叫車 APP 刪掉了。
我有點意外。
因為他算是這個車隊的忠實客戶。這幾年新的叫車平台愈來愈多，有些價格比較便宜，也經常推出優惠。他偶爾也會試試看，最後還是回到原本這一家。
我曾經問過他為什麼。
「用習慣了，而且一直都還不錯。」
直到有一次，他照常用 APP 叫車。
車子抵達後，他晚了一分鐘到上車地點。等他趕到時，司機已經離開，系統也通知他需要支付一筆等待費。
金額不高，而且他自己也承認，遲到是事實。
只是對當時的處理有些疑問，所以他寫了一封信給客服，把事情經過和自己的想法說明清楚。
信寄出去後，沒有收到任何回覆。
隔了幾天，還是沒有消息。
原本他在意的是那筆等待費，後來卻開始想：
「他們到底有沒有收到我的信？」
大約一個星期後，客服終於回覆了。
朋友跟我說，到那個時候，他已經沒有那麼在意那筆費用最後怎麼處理。
「其實他們不用馬上處理我的問題。只要寄完信之後，系統先告訴我：『我們已經收到您的來信，預計五個工作天內回覆。』這樣就好了。」
後來，他把用了很多年的 APP 刪掉，開始使用另一家叫車平台。
我聽完之後，反而對那一個星期很有興趣。
因為站在朋友這一端，我們知道他的感受怎麼一路發生變化。
可是，站在車隊那一端，他們知道嗎？
從等待費，再往後看一步
如果這件事情進入客服系統，最後很可能被記錄成：
「客戶反映等待費問題。」
這樣的紀錄沒有錯。
客服收到案件，依照流程確認狀況，一週後完成回覆，案件結案。
至於這位客戶後來把 APP 刪掉了，企業未必知道。即使發現他不再使用服務，也不一定能把他的離開和這次客服經驗連在一起。
這正是這個故事讓我覺得值得討論的地方。
因為認識這位朋友，我們才聽到了客服紀錄裡可能沒有出現的後半段。
他承認自己遲到了，也沒有要求客服立即解決問題。真正讓他的感受愈來愈差的，是信寄出去之後，長時間不知道有沒有人收到，也不知道什麼時候會得到回覆。
如果只看到「等待費客訴」，後續很自然會去檢查收費規則、司機的處理方式，或客服該如何回答。
這些方向都合理。
朋友的經驗只是讓我們多看到一個可能性：
等待客服處理的這段時間，會不會也是影響客戶感受的一部分？
這裡需要特別小心。
我們知道這位朋友很在意，不代表所有客戶都有相同的感受。一個人的經驗可以提供線索，還不能直接成為企業改善的結論。
也正因如此，客戶的聲音很有價值。
它常常讓我們注意到原本沒有看見的地方，接下來還需要繼續確認。
一條線索，怎麼知道值不值得改善？
假設今天我們就在這家企業裡，也聽到了這位客戶完整的經歷。
第一個動作不一定是立刻設定自動回覆。
可以先回頭看看手上的資料。
例如，客服處理時間較長的案件，是否比較容易收到第二次詢問？有沒有一些客戶會主動追問「我的案件有人收到嗎？」等待時間拉長之後，後續抱怨或客訴升級的情況是否跟著增加？
如果現有資料還看不出來，也可以找幾位有過類似經驗的客戶聊一聊，了解他們在等待客服回覆期間最在意的是什麼。
這時候可能發現，朋友的情況很普遍。
也可能發現，多數客戶真正介意的是正式處理時間太久，和我們原先想的不一樣。
無論是哪一種結果，都比一開始只看到「等待費客訴」多了一些資訊。
假設進一步確認後，真的發現不少客戶在等待期間最困擾的是：不知道案件有沒有收到，也不知道還需要等多久。
這時候才有一個值得測試的想法。
如果收到客戶來信後，先告訴他案件已經收到，同時提供預計回覆時間，情況會不會有所改善？
要確認這件事，第一步其實不用做得很大。
可以先從一個客服管道開始，在收到來信後自動回覆：
「您好，我們已收到您的來信，客服人員預計於五個工作天內回覆，謝謝您的耐心等候。」
跑一段時間，再回來看結果。
原本重複詢問案件進度的情況有沒有減少？等待期間產生的抱怨是否出現變化？如果企業原本就有滿意度或相關服務數據，也可以一起觀察。
結果如果有改善，我們就多了一些證據支持原來的判斷。如果沒有，也不用急著把它解讀成失敗，至少我們知道，真正影響客戶感受的因素可能還在別的地方。
回頭看這段過程，其實就是一個 PDCA 的過程。先釐清問題、想清楚這次要驗證什麼，再用小規模的方式試做；有了結果之後，回頭檢查原來的判斷，再決定保留、調整，或進入下一輪。
PDCA 在這裡的價值，不只是把事情做完。每跑完一輪，我們都應該比原來更了解問題，也更了解客戶。
這也是為什麼，我不太傾向看到一則客戶抱怨，就立刻開始討論完整解法。
有時候先花一點時間確認問題，再做一個成本不高的小嘗試，後面的決定反而會更有依據。
專案做完，留下的不能只有「已上線」
假設最後確認這個做法有效，公司也正式建立了收件確認機制。
專案簡報上可能出現一句：
「客服信件自動回覆功能已完成上線。」
工作完成了。
可是半年後，如果另一個部門來問：
「我們最近也遇到很多客戶一直打電話問申請進度，你們之前是不是處理過類似問題？」
這時候，如果留下來的只有「功能已上線」，能提供的幫助其實很有限。
真正值得下一個團隊參考的，是當時怎麼走到這一步。
最初收到什麼客戶聲音？
一開始大家怎麼理解問題？
後來看到哪些資料或客戶反應，讓原來的想法產生改變？
曾經試過什麼？
結果和預期一不一樣？
還有哪些事情，到專案結束時仍然沒有答案？
這些經驗留下來，下一個團隊不一定照著做，至少知道前面的人曾經看過什麼、試過什麼。
我覺得這也是很多改善專案容易少掉的一塊。
我們很習慣記錄成果，因為成果容易放進報告裡：完成了什麼功能、處理時間縮短多少、指標改善多少。
過程中的判斷比較難整理，卻往往是下一個人最需要的東西。
因為真正可以被累積的經驗，除了「最後怎麼做」，還包括「當初怎麼知道應該往這裡做」。
這些內容不用變成一份厚厚的報告。
只要下一次有人遇到相似的情況，找得到當時的重要發現，就已經有價值。
再回到那位離開的老客戶
朋友最後還是離開了那個使用多年的平台。
我們現在知道，沒有及時收到任何確認，是影響他感受的重要因素。
車隊可能永遠不知道。
這也不代表企業只要多寄一封自動回覆信，就可以留住所有客戶。如果最後得到的是這個結論，反而把這個故事看得太簡單了。
這個案例真正讓我在意的是：企業每天都在收到客戶的聲音，其中有多少在完成回覆、分類或結案之後，也跟著停在那裡？
一句「太慢」，可能還需要知道究竟是哪個環節讓客戶覺得慢。
一句「很麻煩」，也值得回頭看他實際走過哪些流程。
至於同樣遇到問題的客戶，為什麼有些人願意留下，有些人最後離開，更不會只靠客訴分類就得到答案。
這些問題，需要有人願意沿著客戶的經歷再往前後多看一點。
有時候最後找到的是一個需要跨部門處理的大問題。
有時候可能只是發現，企業內部知道案件正在處理，客戶卻一直不知道發生了什麼事。
改善的規模可以不同。
重要的是，我們有沒有從客戶留下來的線索裡，找到值得驗證的問題。
如果最近正在進行一個客戶體驗或流程改善專案，在準備整理成果時，我會建議先把簡報放在旁邊，回頭想想幾件事：
- 最初，客戶到底說了什麼？我們當時怎麼理解？
- 後來看到哪些資料、現象或客戶反應，讓原來的想法有了改變？
- 最後真正決定改善的問題，和一開始想的一樣嗎？
- 為了確認判斷，我們實際試過什麼？
- 結果讓我們多知道了什麼？
- 有哪些事情，是實際做過以後才發現的？
- 如果明天換一個人接手，最希望把哪一段經驗告訴他？
專案最後有沒有得到原先期待的結果，當然重要。
過程中被修正的判斷，也值得留下來。
因為下一次遇到類似的客戶聲音時，它很可能就是另一個團隊開始思考的位置。
企業不會因為完成一次改善，就從此完全懂得客戶。
能做的是在每一次客戶開口之後，多看一些、多確認一些，再把這次真正學到的事情留下來。
下一次再遇到新的聲音時，我們已經比上一次，多知道該往哪裡找。
