AO2 GUIDE 25 · 內容行銷
詢問表單需兼顧客戶填寫與業務判讀。從必要資料、錯誤提示、成功訊息到後續分派核對，減少重複補問並保留需求脈絡。
這篇以企業官網的產品與服務詢問為情境，整理欄位、標籤、錯誤提示、成功狀態與後續交接。文中的欄位與流程都是設計示例，正式安排應依企業實際評估需求與資料處理方式確認。
詢問表單：先定義這張表單要啟動什麼工作
請業務與服務團隊先回答：收到詢問後，第一個人要做什麼判斷、需要哪些資料、可能交給誰，以及什麼情況需要追問。若這些問題沒有答案，表單往往只是在蒐集資訊，卻沒有支持明確的下一步。
不同入口也可能有不同任務。一般合作詢問、特定產品核對與既有客戶支援，不一定需要完全相同欄位。可以先找出共同資料，再依情境提供適合說明，避免客戶選了一個產品，進入表單後又被要求重新描述全部背景。
表單與前面的內容要一致。如果頁面邀請的是初步討論，就不應突然要求尚未評估的人填入完整技術規格。相關採購任務可參考 B2B SEO 與內容路徑，讓詢問建立在讀者已理解的範圍上。
每一個欄位，都應說得出收集理由
把候選欄位列出來，再問它會影響哪個判斷。若資料只是覺得以後可能用到，卻沒有明確用途，就先評估是否需要在第一次詢問取得。初次接觸所需資訊，與後續技術評估所需資訊，可以分階段整理。
例如聯絡方式協助回覆，主要需求協助分派，產品或應用背景則可能影響評估。某些資訊可以選填，或讓使用者表示尚不確定。不要把所有欄位都設成必填，最後迫使人輸入沒有意義的內容才能送出。
也要由實際接手人確認欄位是否足夠。若業務每次都需要詢問現場條件，可能應在表單或前面的說明加入提示；若某欄位長期沒有人使用，就回查保留的必要性。讓欄位跟著工作調整，而不是一直累積。
標籤與提示，要讓人知道該填什麼
W3C 的表單指引強調，控制項需要適合的標籤。網站實作時，不應只靠輸入框裡會消失的提示文字，讓使用者填寫後忘記欄位用途。標籤、必填狀態與必要格式，都應能被辨認與理解。
| 欄位任務 | 較清楚的說明方式 | 避免的情況 |
|---|---|---|
| 描述需求 | 請說明想改善的問題與目前情況 | 只有「內容」兩字 |
| 提供條件 | 已知的產品、環境或系統資訊 | 強迫填入尚未確認的規格 |
| 安排回覆 | 提供適合的聯絡方式 | 不說明哪種方式會被使用 |
| 補充附件 | 說明需要的文件與可接受範圍 | 讓人猜測能上傳什麼 |
提示可以提供例子，但不要把例子變成唯一可接受答案。例如「可先描述目前卡住的工作」，比要求客戶使用內部專業術語更容易開始。若使用下拉選單，也要確認選項涵蓋合理需求，並保留適合的未知或補充方式。
必填與選填，要配合讀者當下知道的資訊
初次了解服務的人，可能知道問題，卻不知道完整解法；技術人員可能有規格，採購者則可能只有需求背景。表單應允許不同成熟度的人開始對話，而不是把某一種角色的知識當成所有人的共同前提。
可以把第一次判斷必須知道的資料留下，較深的條件放到後續評估。若某欄位確實影響分派，就說明為什麼需要，並提供可理解的選項。必填的目的應是支持工作，不是讓資料看起來比較完整。
FAQ 可以幫助讀者先確認準備方式，但不能要求他讀完所有內容才有資格詢問。可接著看 FAQ 內容策略，把常見疑慮與表單提示連起來，減少同樣問題在不同位置各自解釋。
錯誤提示要指出位置與修正方式
使用者輸入不符合格式時，請讓他知道是哪一欄、目前問題是什麼，以及如何修改。只顯示「發生錯誤」通常不足以完成任務，也不應在送出失敗後清空已經填好的有效內容，讓人必須重新開始。
錯誤不能只靠顏色提示，文字也應明確。手機上還要檢查提示是否出現在可看見的位置、鍵盤是否遮住欄位，以及返回修改後能否繼續。表單驗收應包含錯誤情境，而不只是測一次全部正確的資料。
若附件或其他步驟需要等待，提供清楚的狀態回饋。也要考慮網路中斷與重複點擊時會發生什麼，避免使用者不知道是否成功，就反覆送出相同需求。這些情況應與後端交接一起處理。
成功畫面應如實反映送出狀態
按下按鈕、資料通過檢查、成功建立紀錄與業務完成分派，是不同階段。對使用者顯示的成功訊息，應對應實際已確認的狀態，不能只因為點了按鈕，就宣告詢問已經被妥善接手。
成功後可以說明接下來的處理方式，以及需要補充時如何提供資訊。若企業沒有確認固定回覆時程，就不要為了讓畫面完整而自行承諾。訊息應與團隊真正在做的工作一致，避免客戶對等待與責任產生誤解。
內部則保留適合的識別與狀態，讓同事能找到同一筆需求。後續安排可參考 網站詢問與 CRM 交接，把接收、分派、追問與回寫整理成能核對的流程。
手機與鍵盤操作，要在真實任務中檢查
請用手機實際填寫長段文字、選擇選項、查看錯誤與返回修改，確認欄位寬度、字級與按鈕都能使用。桌面看起來簡潔的兩欄排列，在窄螢幕可能需要重新安排，避免標籤與輸入位置失去對應。
鍵盤操作也應有合理順序與清楚焦點，讓使用者知道目前在哪個欄位。自訂下拉或日期元件若很難操作，應評估是否需要更複雜的形式。設計選擇應支持填寫，而不是只讓表單看起來不同。
還要確認固定選單、聊天元件或浮動按鈕，不會擋住送出與提示。相關網站問題可依 網站效能與體驗指南 一起驗收，尤其追蹤或第三方工具更新後，表單是否仍能正常回應。
量測要分清楚行為，不把聯絡內容當分析資料
可以分別觀察表單入口、開始填寫、錯誤與成功狀態，但每個事件都要有清楚定義。不要把按鈕點擊直接當成有效詢問，也不要在沒有確認接收紀錄前，就認定送出率代表業務已收到需求。
分析工具的事件與參數，也不應隨意攜帶客戶姓名、信箱或完整詢問內容。網站行為量測與聯絡資料處理，是不同用途，應依工具規範與企業安排分開設計。可參考 GA4 量測實作 建立可核對的成功條件。
報告中也要把數量與品質分開。成功送出增加，可能只是需求變多，也可能出現重複或不適合的詢問。請由業務回饋資料是否足夠、是否在服務範圍，以及哪些欄位仍需要改善，再決定下一輪調整。
測試應包含接收端與例外情境
網站顯示成功，不代表內部流程一定正常。驗收時應依企業安排使用清楚標記的測試資料，核對接收、通知、分派與狀態，不讓測試需求混入正式工作。也要知道測試完成後由誰確認與整理紀錄。
至少涵蓋資料不完整、格式錯誤、網路問題、重複送出與附件失敗等適合情境。每一種都記錄預期結果與實際反應，若需要人工接手，就確認負責人與可追蹤方式。這樣才能知道流程在哪裡停下。
如果表單與網站由不同團隊維護，請明確分工。欄位變更可能影響接收端的資料對應，不能只改前台文字就完成。需要整合時，可了解 WordPress 網站服務 與 自動化流程整合。
讓表單跟著產品與服務持續回查
服務範圍、產品名稱與分派窗口會變，表單也需要更新。請指定負責人，保存欄位用途、資料對應與成功狀態定義，讓新同事知道哪些設定會影響後續流程，而不是只知道哪個按鈕可以編輯。
定期回查實際收到的需求，確認是否有不清楚的選項、無法使用的附件或反覆缺漏的資料。調整時先提出問題，再修改欄位與提示，不要因為一次特殊需求，就讓所有人多填一個不必要的必填項。
好的表單不會一次完成所有評估，但應讓客戶容易開始，也讓團隊拿到足以接手的資訊。當前面的內容、表單與後續分派一致，網站詢問才更容易成為一段可持續的商業對話。
常見問題
表單越短，轉換一定越好嗎？
不一定。先定義第一次判斷需要哪些資料，把必要欄位與後續可補項分開。對未知的規格提供合理選項或補充方式，避免迫使客戶亂填。驗收不只看點擊與送出率，也看後端接收、業務是否能判斷下一步及重問原因。改版前後使用相同範圍比較，不能因表單變短帶來更多無法處理的提交，就直接宣稱轉換改善。
可以把產品規格全部設成必填嗎？
不宜一律必填。先確認初次接觸者是否能取得該規格，以及缺少它是否真的無法安排下一步。可先收用途、產品方向與聯絡方式，複雜配置再於評估階段補齊；未知項應可明確表達。以電子或 IoT 選型為例，供電與環境可能重要，但仍需引導取得資料，不讓猜測值混入正式需求。測試錯誤提示與手機填寫，確保使用者知道如何修正。
只測網站顯示成功，是否足夠？
不夠。驗收需從送出畫面一路核對後端收到、通知、分派、CRM 狀態與必要分析事件，各階段都有明確完成定義。測試正常、欄位錯誤、重複、逾時與通知失敗，使用可辨認的測試資料並按流程清理。畫面成功但後端無紀錄應視為缺陷；CRM 已建單但回應遺失則需先查核，不能盲目重送。確認負責人真的能接手才算完成流程驗收。
參考資料
本文為 AO2 獨立編寫的企業實作指南。工作情境與清單為方法示例；平台功能與技術規範請以所列官方文件為準。
