買錯票 某天我要去台北，卻發現自己前一天起迄站買反，買成 台北 —> 台南 ，但是搭車前才發現，詢問服務台人員，只得到回覆說發車前 30 分之前才能退票，自己也依稀記得規定是如此，因此只好認栽，誰叫自己買票沒看清楚，趕緊自己去重買一張到台北的車票。後來老婆提醒我也許可以換票，再至服務台詢問，服務小姐說若是錯過班車，可以當天的票搭乘較晚班次的自由座，但是我給她看我的票是早上出發，卻要搭晚上的車，我就解釋是因為我買錯票，她猶豫了一下，竟然說了一個聽起來可以幫我換票的說詞（我忘了他確切的用詞），我雖然感到驚訝但是我已經買了到台北的票，只能說來不及了，她就建議我仍然採用換搭自由座的方法。 預期解法 - 退票 這件事我也犯了一個跟某些客戶常犯的錯誤，就是「沒有提供背景資訊」，或說「 預期解法 」。我心理預期我的問題的解法只有「 退票 」，因此我只問了特定的「退票」事宜，發現不能用「退票」解決，就以為沒有解法了。如果我能第一時間提供比較完整的背景資訊（也就是買錯票的狀況）給服務台，因為服務小姐擁有較完整的解決方案，她可以從我的背景資訊中，更清楚我的需求，進而幫我想到其他解法。 破除方法 - 主動探詢 當然服務是雙方的，如果服務台小姐可以在我第一次詢問時，就更主動探詢更多的背景資訊，她也就有機會促使我講出原本的問題，並從中找出其他解法，最終就提供了一個更好的服務體驗。 回到原始問題 在 ZK 技術支援上，有時客戶問到一個特定的功能可否做到某個效果，問題很簡短，也沒有交代需求或應用情境。如果該功能確實可以達到該效果，我通常會簡短肯定回覆，只是確認或補充說明。如果無法做到，或是該功能跟客戶預期的效果沒有什麼關聯，我會在信末提說：「 如果你能告訴我們你的應用情境，也許我們能找到其他解法 」。因為我推測這位客戶已經落入「預期解法」的思維，他已經認定這個特定的功能就是解法，如果不能做到他的要求，就是不能解。我問的那句話就會 促使客戶描述原本的應用情境 ，我可以據此去找到另外的替代方案或更好的解法。