本系列取材自真實經歷，人物、場景、對話與時間順序經過合成與小說化處理。文中假設案例與示意數字用於說明觀念。

許小姐說那盞燈又閃了。

我剛買完便當走進大廳，聽見這句話，原本以為師父會直接寫「燈壞了」。他卻先問是哪個位置、什麼時間看到，是一直不亮，還是走近了才忽明忽暗。

許小姐指的是地下二樓，電梯走到停車位會經過的那一盞。她說有時正常、有時閃，昨天晚歸又遇到一次。師父把位置和現象記下，告訴她會轉交總幹事安排處理。許小姐確認有人接手，便先上樓。

我等師父寫完，問他：「你這樣一直問細節，跟創業找人訪談是不是有點像？客戶說想要一個功能，你也要問他半天？」

先問最近發生的事情

師父說，詢問細節是為了弄清楚問題。許小姐描述的是看到的現象，維修原因還要由合適的人確認。產品討論也有類似情況：使用者會提出自己想到的解法，團隊仍需要了解他正在處理什麼。

他拿一個假設的客服工具舉例。某位主管說想要 AI 幫忙回覆客戶，如果工程師立刻開始選模型，可能還不知道對方究竟忙在哪裡。是找資料慢、重複打字多、需要跨部門確認，還是每封回覆都卡在主管批准？不同問題需要的做法差很多。

我說：「所以先問他，你每天花多久回信？」

師父回答，可以問，但最好接著請他描述最近一次的流程。哪封信進來、交給誰、查了什麼、在哪裡等最久，最後怎麼回覆。對方說「每天都很忙」的時候，這些具體事情比較有辦法一起檢查。

如果可以取得適合討論的去識別化範例，甚至能看見口頭描述沒有提到的細節。例如回覆文字只花幾分鐘，查訂單和確認退款政策卻花了大半天。這時把文字產生速度提高，未必能讓整個流程快多少。

我問師父：「如果他只說記不清楚呢？」

師父說，那就先保留不知道，可以約下一次帶一個實際例子來談。不需要把每次訪談都逼成完整答案，更不能替對方把空白補滿。

稱讚點子，和願意改變做法還有距離

我說，假設聽完產品介紹的人都覺得很棒，總是個好開始。師父同意，至少表示對方願意聊；但接下來仍要知道，他喜歡的是展示效果，還是這個工具真的能處理手上的工作。

他反問我：「你看一個 demo 覺得很厲害，會立刻把公司的流程搬過去嗎？」

我回答：「不會。要先看資料能不能放、同事怎麼用，還有現在的系統要怎麼接。」

師父說，這些就是採用時會付出的成本。對方可能承認問題存在，卻覺得目前靠熟悉的試算表和同事幫忙還撐得住。新工具要讓人願意切換，需要解決的麻煩大到值得他花時間調整。

我追問：「那他一直說需要，卻沒有下一步，是不是客套？」

師父說，有可能，也可能是最近沒有時間、沒有權限，或我們根本沒把下一步講清楚。可以邀請他做一件和需求有關的小事，例如安排真正負責的人一起討論，或提供一份可用的範例。對方願不願意投入，以及投入時遇到什麼阻礙，能提供比一句稱讚更多的資訊。

這裡談的投入不一定是立刻付款。早期探索可以是時間、資料、內部協調；開始談採用之後，才需要逐步確認預算和決策條件。不能把每次客戶願意開會，都記成一筆即將成交的生意。

問題存在，也不保證你的解法適合

我問師父：「如果已經確認客服真的忙，也願意給資料，是不是就可以開始做了？」

師父說，可以開始驗證一個範圍清楚的做法，但還需要看它能不能改善真正的工作。假設產生草稿很快，客服卻得逐句查證內容，最後可能比自己寫更慢。這種結果應該拿回來修正方案，不能只挑「產生速度快」那一項報告。

我又問：「那要問客戶想加什麼功能嗎？」

師父回答，可以聽，但要繼續追問用途。如果客戶說要一個匯出按鈕，就了解他匯出後交給誰、做什麼決定。也許需求只是每週寄一份摘要，也可能真的有既有流程只能接檔案。問清楚以後，才知道要做哪一種。

談話中間，有住戶走進來問剛才的燈是不是有人處理。師父告訴他，已經記下位置和間歇閃爍的現象，會交由總幹事安排檢查；目前還沒有確定的維修時間。住戶點頭，說那就麻煩他們了。

我看師父沒有直接答應明天修好，便說：「你連報修都不肯多保證一句。」

師父回答：「還不知道哪裡有問題，也還沒約到人。」

產品訪談同樣需要留下這種分寸。先了解對方最近怎麼處理問題、付出了什麼，再確認他是否願意投入下一步。 這些資料能幫助團隊判斷值得做什麼，也能讓我們及早發現，原本想做的功能可能沒有解決重點。

師父依社區的方式把報修事項轉交，交接簿上留下等待處理的紀錄。我提著便當上樓，今晚那盞燈的事情有人接了，但還沒有修好。