接案詢問表單怎麼設計？先篩出有合作可能的需求

先確認表單的任務

接案詢問表單的主要任務是確認客戶目前遇到什麼問題、是否符合你的服務範圍，以及雙方下一步如何聯繫。表單不是考試，也不應要求客戶在第一次詢問時就交出完整企劃。

如果你提供固定價格的標準服務，表單可能只需要稱呼、電子郵件與服務選擇。若承接高度客製化的網站、設計或顧問專案，才需要補充需求描述與預計時程。

第一個問題：目前想解決什麼問題？

不要只問「需要什麼服務」。可以請對方簡單描述目前情況、希望改善的問題與期待成果。例如「已有三項顧問服務，希望網站能清楚介紹服務並方便訪客詢問」，就比「想做網站」更有助於初步判斷。

讓客戶用自己的話回答即可，不必要求他使用專業術語。也不要在表單階段就要求提交完整需求規格。

第二個問題：需要哪一類協助？

可依實際服務提供網站規劃、內容撰寫、設計製作、顧問服務與其他等選項。選項要對應你確實能交付的工作，不要為了看起來完整而列出沒有提供的服務。

保留「還不確定，想先討論」，讓不熟悉專業流程的客戶也能提出詢問。若不同服務需要不同資料，可以用條件式欄位，只顯示相關問題。

第三個問題：目前準備到哪個階段？

網站專案可以詢問是否已有品牌素材、服務內容、圖片與網域；簡報專案可以詢問是否已有講稿或草稿。準備程度會影響工作範圍、時程與估價。

建議使用「已準備完成」「部分完成」「尚未開始」「不確定」等簡單選項。不要要求客戶在初次詢問就上傳包含個資、密碼或機密資料的檔案。

第四個問題：希望何時完成？

時程是評估接案可行性的重要資訊。可以讓客戶選擇一個月內、一至三個月、三個月以上或尚未確定，也可以詢問是否有活動、上線或內部審核的關鍵日期。

急件不代表一定值得承接。若需求、資料與決策流程尚未確認，應先判斷能否合理完成，而不是為了成交直接承諾期限。

第五個問題：是否已有預算規劃？

預算能協助判斷工作範圍，但不一定要設成必填。可提供合理的預算區間，並保留「尚未確定，想先了解費用」選項。

若已有固定方案與公開價格，應讓客戶直接查看價格和內容；客製化專案則可以說明費用會依需求評估。不要用表單刻意隱藏應該公開的價格資訊。

第六個問題：誰會參與確認合作？

企業案件可能涉及承辦窗口、主管、採購或資訊部門。初步可以詢問「這次合作是否需要其他人共同確認」，不必要求填寫所有決策者的個人資料。

個人客戶通常不需要這個問題。表單應依客群調整，而不是所有人都使用同一套企業採購流程。

第七個問題：如何聯絡最方便？

電子郵件通常足以進行初步回覆。若需要電話溝通，可以提供電話欄位，但應先確認是否真的需要設為必填。

應清楚說明你會透過什麼方式回覆，以及資料將如何使用。不要因為有人填寫專案詢問，就自動將他加入不相關的行銷名單。

把七個問題縮成一份容易填的表單

七個面向不代表必須設計七道必填題。你可以把需求類型與問題描述放在一起，把準備進度和時程設成選項，再依服務需要增加選填欄位。

一份適合初次詢問的表單，可以先保留稱呼、電子郵件、需求類型、問題描述與預計時程。預算和決策流程可設為選填。若服務簡單、價格固定，甚至可以再精簡。

用手機實際填寫一次，看看是否需要不斷捲動、選項是否容易點選、錯誤訊息是否清楚。設計表單時應以客戶能否理解為主，而不是後台資料欄位越完整越好。

網站設計服務的詢問表單範例

網站設計師可以先問：網站主要用途是什麼？預計需要哪些頁面或功能？是否已有文字、圖片與品牌素材？希望何時完成？最後留下適當聯絡方式。

如果客戶不知道需要幾頁，可以讓他描述希望訪客在網站上完成的事情，例如了解服務、預約或購買。這樣比要求他直接選擇專業功能規格更容易。

不要在詢問階段要求提供網站後台帳號、主機密碼或其他敏感存取資料。若後續需要檢查，應先確認授權與安全的資料交換方式。

文案服務的詢問表單範例

文案工作者可以詢問內容用途、主要讀者、希望撰寫的內容類型、目前是否有資料，以及預計交付時間。若對方還不知道篇數，不必強迫他先填精確數量。

例如客戶想改善服務頁，可能需要先整理定位和內容架構，而不只是把現有文字修得更漂亮。表單應允許客戶描述問題，讓你在正式洽談時判斷工作範圍。

如果內容涉及尚未公開的商品資訊或企業內部策略，不要要求對方直接貼進公開或不適當的表單欄位。

企業講師與顧問的詢問表單範例

企業講師可以詢問活動目標、參與對象、預計日期、形式及希望協助的主題。顧問服務則可詢問目前困難、預計改善方向與是否已有相關窗口。

不要要求客戶在第一封詢問就提供員工個人資料、完整營收或內部報告。初步判斷是否適合後，再依實際需要與授權安排資料交換。

如果活動日期尚未確認，可以保留「規劃中」的選項，避免把仍在評估階段的合適客戶擋在門外。

送出表單後，客戶應該看到什麼？

表單送出成功後，頁面應清楚顯示資料已收到，並說明接下來會如何處理。不要讓客戶誤以為送出詢問就代表已完成預約、付款或正式合作。

若你有自動回覆信，應確認寄件資訊、主旨與內容正確。不要承諾無法保證的回覆時間，也不要把表單提交成功訊息寫成已經接案成功。

表單出錯時，應指出需要修正的欄位，並盡量保留已填資料。若錯誤提示不明確，客戶可能以為已送出，實際上卻沒有收到任何通知。

收到詢問後，先分成三種處理情況

第一種是需求明確且符合服務範圍，可以安排需求確認或進一步報價。第二種是需要補充資訊，先追問最重要的兩三個問題，不必立刻安排長時間會議。

第三種是明顯超出服務範圍，例如你只提供網站內容規劃，對方卻希望你負責整套企業資訊系統。這時可以禮貌說明目前無法承接。

這樣的分類是工作流程安排，不是對客戶的評價。填得簡短不代表沒有預算，填得詳細也不保證一定會合作。

不要讓表單變成沒有必要的個資收集

初步詢問通常不需要身分證字號、住家地址、帳號密碼或完整公司機密。蒐集資料前先問自己：沒有這個欄位，是否真的無法判斷合作可能性？

在表單附近提供清楚的資料使用說明，包含聯絡目的與必要的處理方式。若另有電子報或行銷訊息，應與專案詢問分開處理，尊重使用者的選擇。

後台也要控制存取權限，避免不需要處理客戶資料的人可以任意查看。資料保存時間與方式應依實際業務需求及適用規範安排。

常見錯誤：把詢問表單當成銷售壓力測試

要求客戶填寫十幾道問題、先揭露完整預算或回答專業術語測驗，不一定能找到更好的客戶，反而可能讓忙碌的企業窗口不願意開始。

另一個錯誤是使用帶有判斷意味的選項，例如「只想問問，不認真合作」。這種寫法容易讓人不舒服，也無法準確判斷需求。

較好的方式是用中性選項描述階段，例如「正在蒐集資訊」「預計近期啟動」「已有明確工作範圍」。讓客戶能如實回答，你才有可用的資訊。

上線前要做哪些測試？

用桌機與手機各送出一次測試資料，確認欄位、必填提示、送出按鈕與成功訊息正常。測試通知信是否收到，並查看垃圾郵件資料夾。

若表單串接客戶管理系統，確認欄位對應、標籤與通知規則正確，避免把專案詢問誤認成訂閱電子報。若有條件式欄位，應分別測試不同選項。

最後請一位不熟悉你服務的人試填，觀察他是否理解每個問題。外掛或網站更新後，也應定期檢查表單是否仍能正常運作。

如何判斷表單改版是否有效？

不要只看表單送出次數。可以記錄完成率、實際收到的有效詢問、是否符合服務範圍，以及從詢問到正式洽談需要補問多少資訊。

若表單縮短後送出數增加，但大多與服務無關，未必是改善；若送出數略少，卻更容易進入具體討論，也可能值得保留。

觀察時要注意流量來源是否同時改變，避免把所有差異都歸因於表單設計。資料量少時，不必急著宣稱某個版本一定比較好。

常見問題：詢問表單越短越好嗎？

不一定。太短可能讓你完全無法判斷需求，太長則增加填寫負擔。應以初步合作判斷需要的最少資訊為原則，依服務複雜度調整。

常見問題：預算一定要必填嗎？

不一定。若有固定方案與公開價格，可能不需要再問。客製化專案可提供預算區間，並允許選擇尚未確定。

常見問題：沒有網站也能用詢問表單嗎？

可以使用適當的表單工具蒐集初步需求，但仍應注意隱私告知、資料安全與回覆流程。若有品牌網站，則可以把服務介紹、案例與詢問入口集中呈現。

表單完成後，如何連接網站內容與案例？

詢問表單不應孤立存在。若客戶從網站文章進來，可以先閱讀服務範圍、案例與合作方式，再決定是否提出詢問。這樣填表單時，對方已經知道你大致能協助什麼。

例如網站設計服務頁可以先說明適合的客戶、常見工作項目、需要客戶準備的資料與報價方式，再提供簡單詢問入口。若有人只想了解基本概念，也可以先閱讀相關文章，不必強迫所有訪客都填表單。

你也可以在確認信中附上服務說明連結，讓客戶等待回覆時自行了解合作流程。但不要在沒有取得適當同意的情況下，把一次性詢問變成持續行銷訊息。

表單問題如何隨服務成熟度調整？

剛開始接案時，最重要的是收集足以判斷需求的資訊。當你累積更多案件後，可能會發現某些問題反覆造成誤解，例如客戶以為包含文案、維護或不限次數修改。

這時可以把常見誤解改寫成清楚的服務說明，或加入一個簡短選項，而不是不斷堆疊新欄位。每增加一題，都應能說明它協助你做出哪一個判斷。

定期檢查實際詢問與後續合作，移除已經沒有用的問題，讓表單保持簡單而有效。

結語：讓合適的客戶更容易開始對話

好的接案詢問表單不是用來證明誰有資格成為客戶，而是讓雙方在投入正式洽談前交換必要資訊。先問清楚問題、服務類型、時程與聯絡方式，再依服務需要增加選填欄位。

當表單容易理解、資料用途清楚、送出後有明確下一步，客戶比較知道如何提出需求，你也更容易把時間留給真正有合作可能的案件。

參考資料

W3C WAI｜Forms Tutorial｜2026年查閱
W3C WAI｜Labeling Controls｜2026年查閱
W3C WAI｜User Notifications｜2026年查閱