AO2 FIELD GUIDE · N114 · 行銷自動化與工具整合
表單重複提交需辨認同一次請求與不同需求，再設計去重鍵、唯一約束及重試狀態。附重複測試矩陣與資料契約，避免只關閉按鈕卻仍重複建單。
使用者連點、網路逾時與系統重送，都可能讓同一次詢問被處理兩遍。可靠流程應允許安全重試，同時保留真正不同的新需求；目標不是把所有相似資料刪掉，而是讓同一個邏輯提交不重複產生副作用。
表單重複提交：先決定什麼算同一次操作
同一位客戶同一天詢問兩款不同產品，可能是兩個真實需求；同一請求因沒有收到回應而重送，才可能需要沿用結果。若只用電子郵件去重，容易誤刪新商機；若每次重試都產生新識別碼，又無法辨認同一次操作。先寫清業務單位與系統單位，再設計去重規則。
Microsoft 的 冪等消費者模式說明，重複訊息可能出現，處理端需避免再次產生不必要副作用。本文把這個原則應用到網站詢問與 CRM；實際交易邊界、保存期間與接口能力，仍需由系統維護者確認，不能只抄一段流程圖就保證完全不重複。
| 欄位／規則 | 用途 | 需確認事項 |
|---|---|---|
| 邏輯操作 ID | 辨認同一次提交 | 重試沿用與新需求分開 |
| 內容核對 | 偵測同鍵不同資料 | 衝突時不得靜默覆蓋 |
| 處理狀態 | 區分進行中、成功及失敗 | 逾時如何查詢 |
| 外部紀錄 ID | 連回 CRM 及通知結果 | 目的端去重能力 |
| 保存與權限 | 管理去重歷史和查詢 | 識別碼不等於授權 |
把去重鍵與追蹤關聯碼分開
追蹤關聯碼可串起一次旅程的多個事件，去重鍵則應識別一個特定邏輯操作。一次旅程可能包含提交、補資料與不同產品需求，不能全部共用一個去重鍵。重試同一次提交時，應沿用可驗證的操作識別；資料改變但沿用原鍵時，系統要能辨認衝突並要求重新確認。
不要為了去重把個資直接放在鍵名、網址或分析參數。識別碼本身也不是授權憑證；取得一個案件 ID，不應讓任何人讀取案件內容。網站與 CRM 的權限仍需另外驗證。測試時使用明確的測試資料與環境，避免將重送實驗變成業務收到多筆假詢問。
並行請求不能只靠先查再新增
兩個請求同時到達時，都可能查到「尚未存在」，接著各自建立紀錄。應由系統人員以合適的唯一約束或原子操作，讓相同邏輯鍵不能同時取得建立資格，並明確處理進行中、成功與失敗狀態。前端暫停按鈕能改善體驗，但不能代替接收端保護。
| 情境 | 預期結果 | 核對範圍 |
|---|---|---|
| 同鍵同內容重送 | 沿用狀態或既有結果 | 網站及 CRM |
| 同鍵不同內容 | 明確衝突與重新確認 | 不覆蓋原需求 |
| 不同的新需求 | 保留獨立操作 | 不因同客戶誤合併 |
| 下游成功但逾時 | 先查結果再決定重試 | 外部識別碼及紀錄 |
| 通知後重新執行 | 不重複產生可避免副作用 | 郵件、待辦與分析 |
假想電子產品詢價：網站已接受資料，但回應在網路中中斷。使用者重試後，系統應能找到原請求狀態，回傳可理解的結果，而不是再建一筆。若原請求仍在處理，顯示待確認或查詢方式；不能在不知道是否成功時，直接告訴使用者「完全沒送出」。
CRM、通知與分析各自處理副作用
本地資料只建立一次，仍可能因通知重試而寄出兩封信，或因 CRM 回應逾時再次建立商機。列出每一步副作用及其外部識別碼，確認目的系統是否支援去重或結果查詢。不支援時，設計可核對的待處理狀態與人工調解，不能假設資料庫交易能涵蓋所有第三方動作。
需要補償或人工合併時，保留兩筆紀錄的來源、狀態與處理理由，不直接刪掉可能包含不同需求的資料。對已寄出的通知，也不能用刪除資料庫紀錄當成撤回。流程文件應讓接手人知道哪些步驟可重試、哪些需要先查結果，避免維護者按一次重跑就再次觸發全部動作。
以重試與部分成功驗收流程
測試連點、相同鍵重送、同鍵不同內容、真正的新需求、CRM 已建單但回應逾時，以及通知成功後系統重啟。每次核對網站紀錄、CRM、通知與分析筆數。只看前台顯示一次成功，不能證明所有下游都只處理一次。對無法自動判斷的案例，必須有具體的查核與接手流程。
保存去重狀態的時間，應符合重試路徑與業務需要，不能把任意範例天數當成通則。資料清理後的舊重送也要定義處理方式。上線紀錄寫明支援的接口、未涵蓋的副作用與告警責任；透過測試與監看逐步改善，而不是宣稱任何情況都能達到全系統恰好一次。
常見問題
停用送出按鈕就夠了嗎？
不夠。停用按鈕只能減少畫面上的連點，不能阻止網路重送或後端重試。接收端應以穩定的操作識別碼辨認同一次提交，重試沿用原碼；新需求另建識別碼。使用資料庫唯一約束或原子操作取得處理資格，保存進行中、成功、失敗與結果不明等狀態；同鍵但內容不同時應回報衝突。驗收至少涵蓋同鍵並行、成功後回應遺失再重送，以及同鍵不同內容，核對網站紀錄與 CRM 建單結果。外部 CRM 的副作用仍需另設去重或調解，不能僅憑網站資料庫就宣稱全流程只處理一次。
相同電子郵件能直接合併嗎？
不能只憑電子郵件合併。電子郵件主要協助辨認聯絡對象，本次操作識別碼才用來辨認提交；兩者用途不同。例如同一位電子產業採購先詢問 A 型號，之後又詢問不同交期的 B 型號，應保留兩筆需求，必要時關聯到同一聯絡人。同一操作因逾時重送，才依原識別碼與內容比對沿用處理結果。歷史資料若沒有操作識別碼，可用產品、需求內容、時間與既有紀錄列出疑似重複清單，由負責人確認；不要直接刪除。這是判斷示例，並非 AO2 客戶實績。
第三方接口不支援去重怎麼辦？
先區分「明確失敗」與「可能成功但回應遺失」。如果第三方已建單卻沒有傳回結果，直接重送可能再建一筆。呼叫前保存本次操作識別碼、送出內容與狀態；接口允許時，把可查詢的外部參考碼一併送入。逾時後先查第三方紀錄，找到既有單據就補回關聯；無法確認時標示結果不明，交由指定人員查核，而非自動當作失敗重送。如果對方既不能去重，也沒有可查詢或核對的紀錄，就必須明示此限制，採人工復原或限制自動重試，不能承諾完全消除重複。
來源與方法範圍
查核日期：2026 年 10 月 22 日。官方資料僅支持文中對應的平台或方法說明；工作表、決策步驟與核對方式為 AO2 編輯整理。產業情境依文中標示作假想示例，不作客戶實績、產品資格或效果背書。
