AO2 GUIDE 32 · 內容行銷
網站詢問分派需保留需求脈絡、負責人與處理狀態。從表單、通知到 CRM 回寫安排交接，核對失敗、重送與業務接手的完成條件。
本篇從企業網站的需求接收出發，整理表單、分派、追問與 CRM 回寫的工作方法。文中的狀態與流程是設計示例，實際安排應依團隊分工、系統與服務範圍確認，不代表某項工具已具備全部功能。
網站詢問分派：先畫出一筆詢問會經過哪些人與狀態
請從客戶送出開始，列出接收、初步確認、分派、追問、評估與結束等實際工作。每一步寫出輸入、負責人、需要的資料與完成條件。流程圖可以簡單，但不能只畫工具之間的箭頭，卻不知道人何時需要處理。
例如「已通知」不等於「已接手」，「已分派」也不等於「已回覆」。如果不同團隊使用相同名稱卻代表不同工作，就容易在交接中遺漏。請先建立共同定義，再決定由哪個系統顯示與保存狀態。
前台資料可依 詢問表單指南 整理，讓第一次收到的資訊足以支持初步判斷。流程不應要求客戶重複提供網站已經取得的內容，也不能期待一張表單完成所有技術評估。
必要資料應支持分派，不只讓表格看起來完整
第一次接收可以確認主要需求、相關產品或服務、適合聯絡方式與必要背景。哪些欄位必填，應由實際接手工作決定；較深的規格可以後續補充。若客戶尚未確認某項條件，應有適合的未知狀態，不要迫使他填入猜測。
也要保留來源與時間等適合紀錄，讓同事知道這筆需求從哪個入口進來。但不是每個系統都需要保存全部原始內容，資料使用應依企業規則與工具安排確認。不要為了方便，就把所有聯絡資訊複製到每個通知與分析欄位。
W3C 的表單說明指引可以支持前台提示設計，後續則要讓欄位與接收端有清楚對照。若網站改了選項名稱，內部分類也應回查，避免前台寫產品詢問，接收端卻被當成另一種服務。
每個狀態，都要有負責人與下一步
狀態不是只供報表上色，而應反映目前由誰處理、還缺什麼，以及什麼情況可以往下走。可以先採用少數清楚狀態，等工作成熟再擴充，避免一開始出現很多名稱相近、沒有人知道差別的欄位。
| 狀態示例 | 代表的工作 | 必須知道的下一步 |
|---|---|---|
| 已接收 | 系統已建立可辨認紀錄 | 由誰做初步確認 |
| 待分派 | 需要判斷服務與窗口 | 分派依據與負責人 |
| 待補資料 | 缺少必要背景 | 要追問什麼、由誰處理 |
| 評估中 | 已進入適合的業務或技術工作 | 目前責任與後續紀錄 |
| 已結束 | 依團隊定義完成處理 | 結束原因與可回查資訊 |
這些名稱只是示例，重點是定義一致。不能把所有沒有後續紀錄的需求都算成無效，也不能因為一封通知寄出，就直接進入已完成。狀態應由可確認的工作推進，而不是只靠經過多少時間自動變色。
分派規則要明確，也要能處理不符合規則的需求
可以依產品、服務、市場或其他真正影響工作的條件分派，但每條規則都要有來源與維護人。若分類無法確認，應進入適合的人工處理，而不是任意丟給某個窗口，讓人以為已完成交接。
規則也要考慮人員異動與服務範圍變化。某位同事離開或產品線調整後，誰負責更新對應，應事先清楚。不能讓流程長期依賴某個人記得轉信，卻沒有其他可見紀錄。
若多語詢問需要不同窗口，請確認語言與市場的實際接手能力。網站版本規劃可參考 多語網站指南，讓公開入口與內部責任一致，不只是把表單翻譯成另一種語言。
同一筆需求重送時，要知道是更新還是新工作
客戶可能因為網路、沒有看到成功訊息，或想補充資料而再次送出。系統需要有適合的辨認與處理方式，但不能只靠同一個信箱，就把所有內容自動合併。相同聯絡人也可能有不同產品或專案需求。
可以保留穩定的需求識別、時間與關聯，讓同事判斷重複、補充或新問題。若工具重試同一項工作，也應避免無意間建立多筆相同任務。實際辨認方法由系統與團隊確認，不能只在流程圖上寫「去重」就當成完成。
前台成功與等待訊息也要清楚，讓使用者知道目前狀態與適合補充方式。這些設計能減少不必要的重送，但仍需要接收端處理例外，而不是把全部責任留給客戶。
通知、接手與回寫，應各有可核對的結果
通知只是提醒，接手代表有人確認責任，回寫則讓其他人知道工作進度。三者應分開定義，也要避免通知很多卻沒有人負責。重要的是需求能持續往下走，不是每個工具都亮起一個成功訊息。
CRM 或其他紀錄系統可以保存適合狀態與後續資訊，但欄位應配合實際工作。若業務回覆只留在私人對話，其他人就可能持續追問同一件事。請確認哪些結果需要回寫，以及如何在不增加過多重工的情況下完成。
若希望同步不同系統，可了解 自動化流程整合。交付應包含資料對照、失敗處理、紀錄與人工接手，而不是只展示一筆資料可以成功傳過去。
例外情境需要被設計，不是等失敗後臨時補救
資料不完整、附件無法使用、工具中斷、窗口不存在與重複需求，都應有適合處理方式。每種情況寫清楚會停在哪裡、由誰確認，以及是否可以重試。避免流程失敗後，只在某個人看不到的角落留下訊息。
如果需要人工修正資料，也應保留改動原因與責任。不要讓人為了讓流程繼續，就直接補上未確認的產品條件或商務承諾。缺少資料時可以追問，無法確認時則保留待處理，這比讓系統看似全部完成更可靠。
AI 可以協助分類與整理，但重要邊界應能驗證。若用途不明或資料不足，就轉交適合的人；若接上問答系統，可依 企業 AI 問答與 RAG 確認來源、範圍與未知問題處理。
用完整任務驗收，不只測單一工具有反應
依企業安排使用清楚標記的測試資料，從網站入口走到接收、分派、追問與回寫。每一個步驟核對預期結果與實際紀錄，不讓測試詢問混入正式業務工作。必要時，也要確認測試完成後的整理責任。
至少抽查正常需求、未知分類、資料不足、重複送出與工具失敗等適合情境。若某一步顯示成功，下一步卻沒有紀錄，就回查資料與狀態對應。流程驗收的單位是一筆需求的完整旅程，不只是某個連線測試通過。
網站與接收端若由不同人維護，請在同一張工作單記錄分工。表單、模板或工具更新時，也要重新確認重要情境。可以搭配 WordPress 網站整合 把前台與後續流程一起安排。
量測區分處理效率、需求品質與商業結果
流程可以觀察等待、缺漏、重複與未接手情況，但每個指標都要有清楚定義。處理速度變快，不代表需求更合適；詢問數量增加，也不等於後續商機已經增加。不同層次應分開看，再討論彼此關係。
網站行為可依 GA4 企業量測 核對成功狀態，業務端則確認需求範圍與後續進展。兩邊不必使用完全相同指標，但需要知道如何對照同一段工作，避免一筆需求在不同報告裡有不同意思。
若資料不足，就保留觀察限制與需要補的紀錄。不要為了呈現自動化價值，直接把所有節省時間換算成確定營收。可以先說清楚哪些重工減少、哪些等待更容易被發現，再持續回查商業結果。
為流程指定維護人，讓規則能隨工作更新
每項重要規則、欄位與系統對應，都應有負責人與變更紀錄。人員、產品與服務範圍改變時，就回查分派與接收。不要讓一次成功上線的流程，長期使用已不適合的名單與條件。
也要保留回復與交接方式。工具或串接停止時，團隊需要知道如何暫時人工接手，以及哪些需求仍待處理。資料與流程文件可以依 企業知識交接指南 整理，不只存在於建置者的記憶裡。
比較穩定的起點，是先完成一個入口與一種需求的完整循環，再決定擴充。當資料、責任與例外都清楚，網站詢問才更容易被接住，自動化也才有明確可以支持的工作。
常見問題
一定要先導入完整 CRM，才能整理流程嗎？
不一定。先用可維護的方式記錄需求 ID、來源、必要欄位、負責人、狀態與下一步，讓一次詢問從收到到回覆可被追查。用測試資料走過分派、補問、關閉與失敗交接；當資料量、多人協作或串接需求增加，再選 CRM。沒有共同狀態定義時，換系統也可能繼續漏接；工具可逐步升級，但案件識別與責任不能一直留白。
通知已寄出，就可以算業務已接手嗎？
不能直接算。通知送出只代表提醒動作完成，接手需有明確負責人與確認狀態。可將已收到、已通知、已接單、待補資料與已回覆分開，為無人接單設定提醒及替代窗口。驗收時模擬通知成功但無人回應，確認案件仍會被追查；通知失敗也不能讓需求消失。報表應分開呈現各階段，避免把寄信數當成已處理商機。
哪些工作適合先自動化？
先選輸入穩定、規則清楚、錯誤可發現並能復原的步驟，例如依已確認產品 ID 分派、提醒未接手案件或同步已核准欄位。選型、未知需求分類與商務承諾則保留相應判斷。每一步先寫完成與失敗條件，再測缺值、重複、逾時與外部成功但回應遺失等情境。若無法查核結果，就先限制自動重試，而不是只追求流程不中斷。
參考資料
本文為 AO2 獨立編寫的企業實作指南。工作情境與清單為方法示例；平台功能與技術規範請以所列官方文件為準。
