接案需求訪談是正式提案前確認目標、工作範圍、交付與驗收條件的對話。
需求訪談的核心
先了解客戶遇到的問題，再確認本次合作需要完成哪些工作。不要還沒釐清範圍就直接報價。
為什麼提案前要做需求訪談？
客戶說想做網站、品牌規劃或顧問服務，通常只描述想要的成果，還沒有說清楚工作內容。若接案者直接報價，後續容易出現新增需求、素材延遲或驗收標準不同的問題。
需求訪談的目的是把雙方理解整理成可執行的範圍。訪談不是為了問倒客戶，也不是保證每個細節都能一次確定，而是找出會影響費用與交付的重要條件。
先了解現況，不要急著推薦功能
可以先問目前最困擾的情況、已經嘗試哪些做法，以及哪些工作受到影響。若客戶說網站詢問少，不應立刻斷定要重做網站；可能還需要了解流量、內容與服務定位。
先聽完情境再整理問題，能避免把自己熟悉的工具當成所有客戶的答案。
確認合作目標與可驗收成果
詢問這次完成後，希望有哪些具體改變，以及哪些成果一定要交付。對網站專案而言，交付頁面、表單測試與操作說明，通常比保證一定增加收入更容易明確驗收。
若客戶提出無法由單一服務控制的結果，應區分可承諾的工作與其他影響因素，避免讓提案變成無法兌現的保證。
確認工作範圍與不包含的項目
可以請客戶列出必要、希望有與暫時不需要的項目。再逐項確認是否包含文案、圖片、頁面設計、功能設定、測試與交接。
不包含的項目也要寫清楚。例如攝影、長期維護、額外頁面與第三方服務費，若不在本次範圍，應在提案中說明。
確認素材、權限與客戶配合
詢問文字、圖片、商標與既有資料由誰提供，是否已經確認可使用。若需要登入網站或第三方系統，應說明權限取得方式與安全要求。
客戶提供資料的日期和審核回覆時間，也可能影響整體時程。不要把所有延遲責任都放在接案者身上，雙方責任應清楚記錄。
確認時程與優先順序
先了解是否有課程開課、活動或產品上市等固定日期，再評估可行的工作安排。若期限太近，可以討論先完成必要項目，其他功能留待下一階段。
不要只因為客戶希望趕快完成，就在尚未了解範圍時答應交付日期。
了解使用者與實際操作情境
如果客戶提出預約系統、會員功能或報名表單，不要只記下功能名稱。要問誰會使用、使用時要完成哪些事情、現在流程哪裡不方便。
例如預約服務可能涉及可預約時段、取消規則、通知方式與後台管理。這些條件會影響工作量，也能幫助判斷是否需要額外工具。
需求訪談可以用情境描述，不必要求客戶先學會專業術語。接案者應協助把日常語言轉成可以討論的工作內容。
釐清修改、確認與驗收方式
可以問哪些人會提出修改意見、由誰統整回覆、如何確認階段成果，以及最後由誰驗收。
若多人各自提出不同要求，可能造成反覆修改。可以建議客戶指定統一窗口，並在提案中寫明確認方式與修改範圍。
驗收不應只寫成「做到滿意」，而應盡可能列出雙方可以檢查的項目，例如指定頁面完成、功能測試通過與必要資料交付。
了解預算、決策者與採購程序
如果是固定價格服務，可以直接說明費用與包含內容。客製化專案則要先確認工作範圍，再討論預算是否已有規劃。
企業案件可能需要主管、採購或資訊部門確認。詢問誰參與決策，是為了準備合適的說明資料，不是要求客戶繞過既有程序。
如果對方尚未確定預算，應了解目前是蒐集資訊還是準備採購，不必直接把對方判定為無效客戶。
訪談時如何追問模糊的回答？
客戶說「希望網站更專業」，可以接著問目前哪些內容讓訪客看不懂，或有沒有特別希望改善的使用情境。
客戶說「要方便管理」，可以追問目前由誰操作、需要多久更新一次、最常修改哪些內容。
客戶說「盡快完成」，則要確認是否有不能延後的日期，以及哪些內容可以先上線。
追問的目的不是挑戰客戶，而是把抽象形容詞變成具體工作。
哪些問題不必在第一次訪談全部問完？
如果還在確認是否適合合作，不一定需要立即討論每個欄位、畫面細節或完整技術規格。
可以先釐清影響報價的關鍵條件，再安排後續規格確認。若需要大量研究、訪談或完整規劃，也可以把需求診斷列為正式付費服務。
讓訪談有清楚界線，既能保護接案者時間，也能避免客戶誤以為初談已包含完整企劃。
訪談後如何整理需求紀錄？
把內容分成目標、現況、必要項目、可選項目、排除項目、素材與權限、時程、決策流程、尚待確認事項。
每個欄位應區分已確認與待確認。不要把接案者的推測寫成客戶已同意的需求。
可以把摘要寄給客戶核對，確認沒有遺漏或誤解後再進入正式提案。
網站專案訪談的實際情境
假設一位講師想建立個人品牌網站，最初只說要介紹課程。你可以先問主要服務對象、目前如何接受詢問、課程資料是否已完成，以及希望訪客在網站上採取什麼行動。
若對方還希望有預約與付款功能，就要再確認各自的流程、是否需要第三方服務，以及誰負責日後管理。
接著整理第一階段必須完成的內容與可以延後的功能，避免把所有想到的項目一次塞進報價。
這是示意情境，實際工作範圍仍須依客戶需求與使用的系統確認。
顧問專案訪談的實際情境
假設一間公司希望改善內部工作流程，不能只問希望上幾堂課。還需要了解問題發生在哪個部門、誰負責推動、目前有哪些限制，以及希望產出什麼成果。
若要深入訪談員工、檢視內部資料或提出完整改善方案，應先確認保密要求、資料使用範圍與服務費用。
對方可能需要的是診斷、培訓或長期陪跑，不能只因為你擅長授課，就把所有問題都當成課程需求。
需求訪談與正式提案如何銜接？
提案不應只是把服務項目列成價格表，而應先回應訪談中確認的問題與目標，再說明建議的工作範圍。
可以依序整理專案背景、預期成果、交付內容、執行階段、雙方責任、費用、付款條件與驗收方式。
如果有尚未確認的條件，應明確標示假設與限制。等資訊補齊後，再決定是否需要調整報價。
需求改變時，如何避免無限追加？
客戶在討論過程中想到新功能很正常。重要的是先確認新增項目是否在原本約定範圍內。
若新增工作會影響費用或時程，應提出變更說明，讓雙方先確認後再執行。不要因為害怕客戶不高興，就口頭答應所有追加需求。
同時也不要把正常的細節確認都當成額外收費。是否屬於變更，應依原先約定的交付範圍判斷。
什麼情況應暫緩報價？
如果客戶還沒決定核心目標、必要功能或交付內容，直接提供固定總價可能造成很大落差。
可以先提供需要確認的事項，或提出分階段規劃的方式。若需要深入研究才能估價，也應清楚說明診斷服務的範圍與費用。
暫緩報價不是故意拖延，而是避免用不完整資訊做出雙方都難以遵守的承諾。
需求訪談常見的五個錯誤
第一，只問客戶想買什麼，沒有了解背後問題。第二，只記錄功能名稱，沒有確認實際使用情境。
第三，忽略素材、權限與客戶配合時間。第四，沒有確認誰負責審核與驗收。第五，把尚未確認的想法直接寫成固定交付承諾。
這些問題都可能在提案或執行階段造成反覆溝通。與其靠更複雜的表單解決，不如在訪談中確認真正重要的條件。
訪談前可以準備的簡單檢查表
會前先看客戶提供的資訊，確認專案類型與預計討論時間。準備幾個關鍵問題，不需要讓客戶事先填寫冗長問卷。
可以依序檢查：是否知道主要問題、是否知道希望完成的成果、是否知道工作範圍、是否知道素材由誰提供、是否知道時程與預算狀態。
如果有一兩項仍不清楚，可以列為訪談重點。這份檢查表是幫助整理，不是要求所有客戶都符合固定格式。
訪談中如何確認雙方理解一致？
每討論完一個重要主題，可以用簡短的話重述。例如：「所以這次最優先的是完成服務介紹與詢問流程，會員功能先不包含，這樣理解正確嗎？」
如果客戶修正你的理解，應立即更新紀錄。不要為了趕快結束會議，忽略明顯的分歧。
遇到無法當場決定的問題，可以記下負責確認的人與預計回覆方式，而不是隨便選一個答案。
如何把需求分成必要與可選？
必要項目是本次專案不完成就無法達成主要目的的工作；可選項目則可能增加便利性，但不一定要在第一階段完成。
例如品牌網站最初可能需要清楚的服務頁、聯絡方式與基本管理功能；其他自動化或會員功能是否必要，要看實際業務流程。
這種分類可以幫助客戶在預算與時程有限時做選擇，也讓報價更容易比較。
如果客戶想法與實際預算差距很大
不要直接批評客戶不懂行情，也不必用模糊承諾讓對方先簽約。可以說明不同工作項目如何影響費用，並協助辨識最優先的需求。
如果可用預算無法完成全部工作，可以討論縮小範圍、分階段執行，或暫時不合作。
調整預算時應同步調整交付內容，不應在相同承諾下無限制壓低報價。
常見問題：需求訪談一定要收費嗎？
沒有固定答案。初步確認合作範圍可以是免費溝通；若需要深入分析、研究與產出可直接執行的報告，則可以設計為正式付費服務。
重點是事先說明包含內容、時間與交付方式，避免雙方期待不同。
常見問題：客戶自己也不知道要什麼怎麼辦？
先讓客戶描述遇到的問題與日常情境，再一起整理最重要的需求。若仍無法確定，應先安排必要的診斷或規劃，不必急著做完整報價。
常見問題：需求訪談要不要錄音？
若確實需要錄音或逐字紀錄，應事先告知並取得適當同意，也要妥善處理保存與存取。若沒有必要，清楚的會議筆記與會後確認也可能足夠。
常見問題：客戶訪談後一直改需求怎麼辦？
先確認變更是否影響原先約定的工作範圍、費用與時程，再以書面整理新增內容供雙方確認。不要只靠口頭印象處理重要變更。
結語：讓報價建立在共同理解上
需求訪談不是把問題問得越多越好，而是確認哪些資訊會影響交付與合作。從現況、目標、範圍、素材、時程到驗收，都應留下清楚紀錄。
當雙方知道這次要做什麼、哪些項目不包含、誰負責提供資料，以及如何確認完成，提案才能真正回應客戶的問題，也比較不容易在執行後才發現範圍不清。
參考資料
Project Management Institute｜Requirements Gathering
Asana｜Project Scope
Atlassian｜Requirements