詢價表單越完整越好？用欄位必要性矩陣保留真正需要的資料

假設你負責重做企業內訓詢價表。業務希望一次拿到統編、地址、參訓名單與預算，方便準備報價；但第一次來詢問的人，可能連人數都還沒確定。你要怎麼決定哪些必填、哪些晚點再問？

這篇用一份虛構表單，示範如何逐欄判斷：少了這項資訊，現在就無法回覆或理解需求嗎？讀完後，你可以和業務一起整理首輪必要欄位，再把詳細需求留到後續對話；文內的三個必填、一個選填是情境示例，不是所有網站的通用答案。

建議先將問題分成「第一次聯繫必需」、「可延後到需求訪談」、「此流程不應蒐集」。英國 GOV.UK 設計系統建議知道每題為何而問，只要求真正需要的資訊；英國國會設計系統同樣提醒，不應因為未來也許會使用某資料，就提早收進表單。S01 S02 這些是設計原則，不是任何台灣網站必須只有 4 格的法律規定，也不是表單縮短一定提升成交率的實證。

本文以虛構的 B2B 內訓詢價表示範欄位取捨，提供可下載矩陣與一份離線靜態 HTML 原型。原型不會傳送、儲存或蒐集資料，後續上線須交由工程與資料管理者驗證。

從「公司想知道」改成「此刻要做什麼」

先說明流程目的：這不是付款、開立發票或受規範的身分驗證，而是讓窗口判斷需求是否屬於企業內訓，並在適當管道進行後續聯繫。因此首輪只需要足以識別詢問來源、回覆對方及大致理解工作問題的欄位。報價所需的詳細資料，可以留在雙方已建立聯繫後，視案件再請求。

以一份原本想要 11 個欄位的教學草案來看，逐欄問四句：「這是當下必要決策嗎？誰會使用？可否由後續對話取得？若沒有會產生什麼實際障礙？」

這張矩陣是編輯根據明確的假設業務目的做的設計，不是直接照搬任何政府網站的強制欄位。若業務有嚴格准入、資格審查、無障礙協助或法律要求，首輪欄位會不同；要先由責任人確認要求，再決定是否、何時蒐集。

依照上表的目的逐欄取捨後，這份示範會留下什麼？把它放進一個看得見的表單，就更容易和業務討論。

首輪原型：三個必填，加一個選填

這份示範表單先保留三個必填：公司／組織名稱、可回覆的電子郵件、想解決的工作問題；「偏好的上課方式」則為選填，可選實體、線上或尚未決定。其餘七個欄位先不在這一輪要求填寫。下載原型中的英文欄位名稱，是交給製作人員對照用的，不需要讓詢問者閱讀。

工作問題可以這樣提示：「目前最希望改善哪項工作？例如每週報表需要兩天人工整併。」這也是虛構的填寫示例，不要求提供真實客戶、合約或員工資料。

讀者可下載 離線原型 ZIP，解壓後以瀏覽器開啟其中的 inquiry_form_static_demo.html：各欄位都有可見標籤，電子郵件採 type=email，選項有「尚未決定」。W3C 的表單教學指出標籤須清楚對應控制項、必要資訊與格式要讓使用者知道，且 placeholder 不能取代 label。S03 S04

這份 HTML 是可由設計與業務討論的靜態原型，沒有後端、身分驗證、同意及保存機制，按鈕不會送出訊息。請勿因畫面看起來完整，就直接放到正式網站當成可收集需求的表單。正式上線要補上伺服器端驗證、防濫用、權限、保留規則、錯誤訊息與隱私資訊，並依服務所在地適用規範檢查。

不是砍到最少，而是讓每一輪能完成一個決策

過度縮短也可能傷害業務處理品質。例如只留下 Email，卻不知道對方希望採購什麼，業務仍需花時間反問。比較穩妥的設計是採依不同階段蒐集必要資訊：

1. 第一輪：能否聯繫、能否初判？ 收基本公司、聯絡方式與工作問題；不要求超出目的的個資。
2. 第二輪：是否值得安排需求訪談？ 由業務確認預期參訓角色、工作成果、時程、決策人與交付限制。
3. 第三輪：是否能精確報價？ 在需求範圍確認後，視需要索取人數、地點、期程與採購流程；財務資料只交給必要角色。

每輪都要有退出、修正、未知與人工協助的路徑。如果訪客不知道人數，就先記「待定」，不要用空白自動解讀為 0 人；若 Email 格式錯誤，錯誤訊息應指出可修正方法，而不僅在欄位顯示紅框。

欄位安排好後，還要確認它是否讓詢問者填得完，也讓業務接得下去。因此，驗收不能只看表單變短了多少。

怎麼驗收是否真的比較好？

不要只比表單送出數。設計一份前後版本的觀察計畫：

先確保同一時段、流量來源與接案規則可比，才能討論表單設計的可能效果。若本來就沒有「開始填寫」事件，完成率就應標未量測，不能偷用頁面瀏覽數或假定每個人都看見表單；若成功動畫沒有對應到資料庫保存，也不能算成功提交。

下載 field_decision_matrix.csv 可供業務、產品、資訊與法遵依實際目的逐欄重新判斷；另外有 form_validation_cases.csv 供團隊驗證必填、未知、格式錯誤與錯誤後修正。這些都是可修改的工作底稿，而不是既有網站改版或轉換率實測。

與舊文詢價表 Vibe coding 上線驗收的分工不同：舊文檢查做好的表單是否能保存、處理錯誤與維運；本篇是寫程式前先決定哪些資料值得詢問。若表單內容涉及 AI 工具輸入，還可延伸閱讀資料遮罩與輸出複核。本題不硬推課程，先把範本提供讀者自行採用。