AO2 FIELD GUIDE · N109 · 行銷自動化與工具整合
自動化流程 Brief 先寫清楚觸發事件、資料輸入、負責人與完成狀態。附流程工作表，整理人工核准、錯誤與交接的驗收條件。
- 觸發事件、必要輸入與不應啟動的條件。
- 成功、部分成功、失敗與待人工確認的狀態。
- 誰處理例外、如何重試，以及怎麼證明工作完成。
自動化流程 Brief：先描述現在怎麼做，再決定要加速哪一步
用一次電子產品詢問還原現況：客戶送表單，行銷收到通知，再把資料轉給業務；業務發現缺少應用環境，回頭補問；PM 判斷規格後，再補進 CRM。若只自動轉寄第一封信，可能減少一次複製貼上，後面的等待與資料缺口仍然存在。
先記錄每個步驟的輸入、動作、輸出、等待原因與責任人。把客戶描述不清楚、規格需要判斷、系統寫入失敗分開，避免把所有延遲都稱為「流程太慢」。Microsoft 的流程管理說明也從現況理解與流程設計開始；本文把這個方向具體化為跨工具的 Brief。[1]
一頁流程 Brief：先填八個欄位
| 欄位 | 需要寫到哪個程度 |
|---|---|
| 目的 | 例如每筆有效提交都有可追查紀錄與明確接手人 |
| 範圍 | 包含哪些表單、產品線、市場；排除哪些個案 |
| 觸發 | 後端確認提交成功，而不是只按下按鈕 |
| 輸入 | 欄位名稱、型態、必要性、來源與未知值處理 |
| 輸出 | CRM 紀錄、分派任務、通知與執行結果 |
| 完成條件 | 哪些結果必須存在，如何核對 |
| 例外與重試 | 資料不足、工具失敗、重送與部分成功怎麼處理 |
| 責任與紀錄 | 誰維護、誰接手、保存哪些必要的追查資訊 |
「完成條件」應能被另一位同事驗證。像「已自動化」沒有判斷方法；「每筆已接受的提交都有來源 ID、CRM ID、當前狀態與負責人，失敗會留下可處理紀錄」才有驗收對象。這不是保證所有工具都能做到，而是需求設計時要先確定的目標。
把資料契約寫清楚，不讓空白偷偷變成答案
示意欄位可以包含 request_id、received_at、product_interest、market、application_context 與 handling_status。產品興趣可能只是初步選項，不能直接當成已確認型號；市場未知時應標記待確認，不能默認為某個地區。時間欄位也要指定時區與來源。
欄位對照至少記下來源欄位、目標欄位、轉換規則、缺值處理與錯誤訊息。若 CRM 只接受固定選項，表單自由文字要如何保留？超長內容是否會截斷？這些問題應在測試階段出現，而不是等到業務發現需求不見了才處理。
用狀態表描述工作，而非只畫成功路線
| 狀態 | 情境示例 | 下一步 |
|---|---|---|
| 待驗證 | 資料已收，但必要欄位不完整 | 保留紀錄，進入補問或人工確認 |
| 待寫入 | 輸入合格，尚未建立目標紀錄 | 依規則執行寫入 |
| 待分派 | CRM 已建立，但責任人仍未知 | 交指定佇列，不默默結案 |
| 待補送 | CRM 已建立，通知失敗 | 只補送通知，避免再建一次商機 |
| 已完成 | 必要紀錄、責任與通知結果均可核對 | 進入後續業務流程 |
狀態名稱可依企業調整，重點是狀態對應可確認的事實。不要讓一個「成功」同時表示 API 回應成功、資料已完整寫入、業務已閱讀與需求已合格，這些是不同事件。
三個容易漏掉的例外：重複、部分成功與人工退回
重複提交：以穩定 request_id 或適合的去重規則辨識同一次處理。若只以信箱去重，可能把同一人的不同專案誤合併。去重規則要保留業務語意，並測試合理重送的情況。
部分成功：目標系統已建單，但後續動作逾時。重試前先核對前一步結果，避免把整條流程再跑一次。追查紀錄需要能看出哪一步完成、哪一步待處理。
人工退回：審核人發現型號或資料不正確時，要能回到補資料狀態，保留原始提交與修改原因。人工確認不是流程外的補丁，而是正式分支。
用完整情境驗收，不只測一筆正常資料
- 正常提交：核對來源 ID、目標紀錄、欄位內容、接手人與通知。
- 缺值提交：確認不會自行補成假資料，並能進入待確認狀態。
- 重複送出：確認同一次處理不會產生非預期重複紀錄。
- 目標系統失敗：保留必要輸入與錯誤狀態，讓負責人能處理。
- 部分成功後重試：核對已完成的動作不會重複執行。
- 人工退回：確認修改、核准與重新處理都有紀錄。
每個情境留下輸入樣本、預期結果、實際結果、證據位置與缺口。使用去識別測試資料，並指定測試紀錄的保存範圍。驗收目的，是讓下一位維護者能重現問題，不是產生更多沒人看的系統日誌。
作者觀點：工具之間的連接，需要保留決策脈絡
Johnny Wu 的公開文章將 Content、SEO/GEO、CRM、Data 與 Sales Enablement 放在同一套工作系統中討論。本文把這個觀點轉成流程要求：交出去的不只是一筆資料，也要包含下一位同事需要的問題、狀態與責任。若資料傳得很快，接手者仍不知道為何收到、需要確認什麼，流程只是加速搬運。[2]
已填流程卡：網站詢問到業務接手
| 規格 | 示意填寫 |
|---|---|
| 觸發 | 表單後端確認接受一筆提交 |
| 輸入 | 需求 ID、提交時間、產品興趣與應用描述；聯絡資料依系統規則處理 |
| 狀態分支 | 缺資料→待補問；寫入失敗→待處理；已寫入但未分派→待分派 |
| 完成條件 | 目標紀錄可查、必要欄位正確、接手角色明確 |
| 重試規則 | 先核對前次結果，只執行尚未完成的動作 |
| 人工接手 | 指定維護角色取得錯誤摘要與必要追查資訊 |
接著故意設計一個部分失敗：CRM 已建立紀錄，通知工具卻逾時。預期結果應是保留 CRM ID，補送通知，而不是再建立一次。若目前工具無法查詢前次結果，就把這個限制列入實作風險，不能在 Brief 裡假裝去重已經存在。
再測一次人工退回：業務發現產品興趣只是初步猜測，應能保留原始提交，修改內部判定並留下原因。這也說明原始輸入與核准欄位不宜混用；否則後續無法判斷客戶原本說了什麼、團隊又做了什麼解讀。
常見問題
先挑工具，再回頭寫流程會不會更快？
可以先探索工具，但 Brief 至少先說清觸發、輸入、處理規則、完成條件與接手責任。用一筆正常需求走完流程，再列缺值、重複與外部失敗時怎麼辦。選工具時核對是否能保存穩定 ID、查狀態與重試，而不是只看有多少現成節點。若工具限制改變原設計，就把取捨寫回 Brief，避免團隊以為原本需求都已被滿足。
小流程也需要錯誤狀態嗎？
需要，但記錄可以精簡。至少能分辨未開始、處理中、成功、明確失敗與結果不明，指定誰查看和如何重試。例如外部系統逾時不能直接等同未執行，應先查核結果。驗收時關掉一個依賴或提供不完整輸入，確認流程不會只顯示完成卻漏資料。小流程若影響客戶回覆或商務承諾，同樣要有追蹤紀錄與人工復原路徑。
所有判斷都自動化，才算導入成功嗎？
不必。把流程分成規則穩定、需要補問及需要專業裁決三類，先自動化前者，讓其他部分有清楚交接。成功標準可以是資料完整、責任明確、失敗可追查與重複處理受控，而非人工步驟歸零。每次擴大前用正常與例外情境驗收。若自動分類讓案件更難修正，應先縮小範圍並改善來源，不用更複雜的工具掩蓋判斷不清。
相關閱讀與下一步
了解對應 AO2 服務，或帶著目前的資料與工作問題，先確認適合開始的範圍。
參考資料與查核範圍
資料查核日期：2026 年 10 月 21 日。官方文件支援文中對應的平台規則；工作表、決策流程與虛構示例為本文整理。Johnny Wu 的公開分享作為作者工作觀點來源，未以此推定客戶成果或產品資格。
