需求訪談問題的直接答案是：先問公司現在卡在哪裡、這件事為什麼現在要解、誰會參與決策、想在什麼時程內完成、目前怎麼處理，以及若不處理會有什麼後果，再來談 demo、方案或報價。對多數台灣中小企業來說，第一次需求訪談的任務不是立刻說服客戶買單，而是先判斷這是不是同一個問題、是不是同一個決策階段、以及你接下來該給報價、安排展示，還是先補資料。
為什麼很多台灣 SME 一開始就談方案，最後反而越談越不準
很多團隊一收到詢問就急著講產品、報功能、排 demo，表面上看起來很積極，實際上卻常常把談話帶進錯的方向。對方只說想提升名單品質，你就開始講 CRM；對方其實只是想縮短回覆時間，你卻直接排完整簡報，最後不是報價報不準，就是會議排給還沒準備好的人。
HubSpot 在 discovery call questions 指南裡，把第一次談話重點放在 open-ended questions、目標、痛點、時程、決策流程與 next steps，而不是先講產品。這個順序很重要。
只要前面問題問得太淺，後面再完整的方案也會建立在錯的前提上。來源：HubSpot: 28 Questions to Ask on a Discovery Call During the Sales Process。
HubSpot 2026 年仍在 pre-call planning 指南裡強調，需求訪談前要先準備 current processes、pain points、desired outcomes、decision-making process、budget 與 authority 的探索方式。這代表成熟團隊並不是想到什麼就問什麼，而是先知道自己要確認哪些決策條件。來源：HubSpot: Pre-call planning。
最值得先問的 6 個需求訪談問題
如果你只能先問幾題，最穩的做法不是照腳本念滿，而是先把六個會影響後續路由的問題問清楚。問到這裡，你通常就已經知道接下來是該報價、排 demo，還是先補資訊。
| 先問什麼 | 你想確認什麼 | 為什麼重要 | 常見錯誤 |
|---|---|---|---|
| 1. 你現在最想解決的是什麼問題？ | 核心痛點與情境 | 避免一開始就跳進產品介紹 | 直接問想看哪個功能 |
| 2. 這個問題現在怎麼影響你？ | 商業影響與優先級 | 判斷是不是眼前真正要處理的事 | 只知道問題名稱，不知道嚴重程度 |
| 3. 你們目前是怎麼處理的？ | 現有流程與替代方案 | 避免提一個根本接不進現況的解法 | 完全沒問現況就報新流程 |
| 4. 希望在什麼時間內改善？ | 時程與緊急度 | 影響報價節奏、導入方式與回覆優先權 | 只問要不要合作，不問何時要動 |
| 5. 誰會一起參與評估？ | 決策人與使用人 | 避免只和窗口講完，真正決策者完全沒進來 | 把窗口當唯一決策人 |
| 6. 若這次不做，最可能卡在哪裡？ | 不作為成本與購買動機 | 判斷是否值得繼續推進 | 只談理想目標，不談不處理的代價 |
1. 先問對方現在最想解決什麼，不要先問想看哪個方案
HubSpot 的 discovery call 問題設計，前段先讓對方講公司、角色、目標與問題，本質上是在避免業務太早把對方塞進自己熟悉的產品分類。對台灣 SME 來說，這一步尤其重要，因為很多詢問其實還停留在「我知道哪裡卡，但我不確定要用什麼工具解」。
只要你第一題就問「想看哪個方案」或「預算多少」，對方很容易直接進防備模式。先讓他講問題，你才知道該回到客服流程、內容營運、名單分級，還是交接機制。
2. 再追問這個問題現在造成什麼影響，才能知道優先級
同樣是名單品質差，有些公司只是想提高效率，有些公司已經因為回覆太慢而漏掉成交。這兩種情況要排的下一步完全不同。HubSpot 在 layered questions 指南裡提醒，第一層問題拿到的是表面資訊，第二層問題要進一步問 why，才能知道真正的 buying motive。來源：HubSpot: The 3 Layers of Sales Questions and How to Use Them。
這也是為什麼需求訪談不能只蒐集名詞。你要知道的是這件事到底讓他少了營收、拖慢回覆、塞住排程，還是只是內部覺得流程不順。
3. 問現在怎麼做，避免提一個根本接不進現況的解法
HubSpot 在 pre-call planning 提醒業務先了解 current processes 與 likely responses，因為沒有現況脈絡，後面再完整的建議也很容易失真。對台灣 SME 來說，現況可能是老闆自己回 LINE、客服用共享信箱、業務靠 Excel 排進度，這些都會直接影響你能不能提出可落地的建議。
真正實用的需求訪談，不是問完就直接推一套理想做法，而是先知道現有流程哪裡能接、哪裡會卡，這樣後面的 demo 才不會變成功能觀光。
4. 問時程，不是為了催單，而是為了判斷是否該現在推進
HubSpot 在 discovery call questions 中把 timeline 放在 qualifying 與 disqualifying 問題裡，Salesforce 的 BANT 也把 timeline 列為四大判斷軸之一。若對方半年後才可能啟動，你現在硬塞報價與簡報，多半只會讓案件提前失焦。來源：Salesforce: What Is BANT?。
時程問清楚後，你才能決定是現在報價、先排短會議、改走 nurture，還是先提供案例與比較內容。這比只看對方有沒有興趣，更接近真實的商機判斷。
5. 問誰會一起參與評估，避免只和窗口談完
Salesforce 將 authority 放進 BANT，不是要你只找頭銜最高的人，而是要確認真正會影響購買的人有沒有進到對話裡。很多台灣 SME 的第一個窗口可能是行銷、營運或行政，但預算、流程或工具最終拍板的人未必是他。來源：Salesforce: What Is Lead Qualification and How Does It Work?。
只要這一題沒問清楚，後面很容易出現你以為談得很完整，結果真正決策者只在最後收到一份冷冰冰報價單，完全沒參與前面的問題定義。
6. 問如果這次不做，最可能卡在哪裡，才能判斷是不是值得繼續追
這題不是要製造壓力，而是用來判斷這是不是當前真的有購買動機的案子。HubSpot 近年的 discovery 與 sales questions 內容都反覆回到同一個核心：你要理解 not just what prospects need, but why it matters and what happens if the problem remains unsolved。
如果對方講不出任何後果，常見情況是還在蒐集資訊、需求還沒成形，或內部還沒有優先順序。這時候先補內容、案例或比較頁，通常比急著報價更有效。
哪些情況適合繼續排 demo，哪些應該先補資料或暫緩報價
需求訪談問完後，不是每一筆都該直接進 demo。真正健康的流程，是根據問題清晰度、時程、決策參與者與現況成熟度來分流，而不是誰有填表就先排會。
| 訪談結果 | 較適合的下一步 | 原因 |
|---|---|---|
| 問題明確、時程近、決策人會參與 | 直接排 demo 或需求會議 | 已具備進一步評估條件 |
| 問題明確，但時程遠或內部還在研究 | 先提供案例、比較內容或短諮詢 | 太早排完整 demo 容易浪費雙方時間 |
| 窗口不清楚現況，也說不出成功標準 | 先補資料與現況盤點 | 報價基礎還不夠穩 |
| 只問價格，無法說明需求與使用情境 | 先做需求澄清再決定是否報價 | 避免報出沒有判斷基礎的價格 |
| 案件明顯超出可服務範圍或預算 | 婉拒或調整合作邊界 | 越早 disqualify，越能保住團隊時間 |
Salesforce 對 lead qualification 的定義很直接：先判斷對方是不是 fit、能不能負擔、值不值得投入後續時間。這提醒我們，需求訪談不是只有 qualification，還包含必要的 disqualification。該停的案子越早停，後面真正適合的案件才有資源往前走。
需求訪談紀錄表怎麼做：先把 7 個欄位記起來
對台灣 SME 來說，需求訪談最常失敗的地方不是不會問，而是問完沒有留下可交接的紀錄。只要客服、行銷、業務不是同一個人處理，第一次訪談就應該留下最少七個欄位。
- 詢問來源：官網、LINE、Email、轉介紹或廣告。
- 主要問題：對方自己怎麼描述卡點。
- 目前做法：現在用什麼流程、工具或人工方式處理。
- 影響程度：卡在營收、排程、回覆速度、客戶體驗還是人力負擔。
- 目標時程：想在什麼時間內改善或上線。
- 參與角色：窗口、決策者、使用者各是誰。
- 下一步：排 demo、補資料、報價、給案例，或暫不追。
只要這七個欄位持續記，後面就比較容易看出哪些案件常卡在同一關，也比較能把行銷帶來的詢問正確交給業務，而不是每次都從頭再問一次。
誰適用、誰不適用這套需求訪談順序
這套問法最適合高單價服務、需要導入評估、多人參與決策，或產品本身有流程改造成分的台灣 SME，例如顧問服務、B2B 軟體、客製專案、內容營運服務與需要跨部門配合的行銷流程案。
若你的產品是低單價、標準化、購買決策很快的商品型服務，這套需求訪談就不一定要問這麼深。那類情況反而更重視價格透明、下單速度與 FAQ，而不是一開始就安排完整 discovery call。
7 天校正 SOP：從第一次訪談修正到更準的交接與報價
第 1 到 2 天：回看最近 10 筆詢問，找出最常漏問的一題
先不要急著改整套流程，先回看最近十筆第一次訪談，檢查哪一題最常沒問到。很多團隊真正缺的不是整套銷售方法，而只是每次都少問了時程、決策人或現況。
第 3 到 4 天：把 6 題改成固定欄位，不要再靠個人記憶
只要同一家公司裡不是永遠同一個人接案，需求訪談就不該只存在聊天紀錄裡。把六題改成表單、CRM 欄位或共享紀錄，比寫一份很長的話術更有用。
第 5 到 7 天：對照後續結果，看哪一種訪談最容易帶來錯誤分流
最後不要只看訪談有沒有做，而要看做完後是不是排到對的下一步。若某一類詢問總是太早進 demo，或報價後總是沒下文，通常不是 closing 技巧問題，而是前面的需求訪談問題還問得不夠準。
資料更新與來源
本文最後檢查日期為 2026 年 6 月 30 日。SERP 與 benchmark 訊號主要用來觀察目前「discovery call / 需求訪談 / qualification」題型的標題承諾、問題順序與下一步設計；涉及需求訪談、qualification 與 BANT 架構時，本文優先依據 HubSpot 與 Salesforce 的公開教學內容整理。
重要來源包括 HubSpot: 28 Questions to Ask on a Discovery Call During the Sales Process、HubSpot: Pre-call planning、HubSpot: The 3 Layers of Sales Questions and How to Use Them。
Salesforce 相關來源則包括 Salesforce: What Is BANT? 與 Salesforce: What Is Lead Qualification and How Does It Work?。
中文查詢結果裡也能看到需求訪談多半落在系統分析或軟體專案語境，顯示目前繁中 SERP 對「台灣 SME 業務需求訪談」的直接內容仍有缺口。本文因此刻意補上報價前、demo 前與交接分流的在地營運情境，但具體欄位與時程仍應依你的服務複雜度與團隊 SLA 調整。
結論
需求訪談問題真正該完成的，不是把產品先講完，而是先把問題、影響、現況、時程、參與角色與不作為成本問清楚。當你把第一次訪談從聊天感覺，改成能支撐交接、報價與 demo 分流的 6 題結構，很多原本越談越亂的詢問，才會開始往正確的下一步走。
FAQ
需求訪談一定要開完整會議嗎？
不一定。若詢問內容已經很清楚，短電話或文字往返也能先完成初步 qualification；但只要涉及多人決策、導入流程或高單價服務，通常還是值得安排一段有結構的訪談。
第一次需求訪談可以先問預算嗎？
可以問，但不建議把預算放在第一題。若還沒先問清楚問題、現況與時程，就算拿到預算數字，也很難判斷該怎麼報價或給什麼方案。
什麼情況不適合直接排 demo？
當對方還講不清楚要解決什麼、誰會參與決策、何時要動，或只想先蒐集資訊時，通常更適合先補資料、提供案例或做短諮詢，而不是直接排完整 demo。
需求訪談和 lead qualification 有什麼差別？
需求訪談偏向把問題、現況與目標問清楚；lead qualification 則更進一步判斷這筆案子是不是 fit、能不能負擔、值不值得投入後續時間。兩者通常連在一起，但不是完全同一件事。
台灣中小企業沒有 CRM，也能做好需求訪談嗎？
可以。先用共享表單或試算表固定記下來源、問題、現況、影響、時程、參與角色與下一步，就已經能大幅降低重問、漏接與錯誤交接。