訂單或預約電郵退回時，企業應如何跟進

發送請求不等於已送達

訂單平台顯示電郵已發送，可能只代表供應商接受了 API 請求，並不能證明收件伺服器已接收，更不能證明顧客已閱讀。Amazon SES 文件把發送、送達、延遲、退信及投訴分作不同事件。實際設計應按企業所用供應商提供的事件類型，把供應商訊息識別碼連回訂單或預約紀錄。客服人員應能直接查看簡明的投遞狀態，而毋須搜尋原始郵件紀錄。通知失敗不應令業務事件消失：收據退回後訂單仍須存在，預約也不應只靠一封電郵作唯一紀錄。

採取行動前先分類。SES 把硬退信描述為持續性失敗，例如郵箱不存在；軟退信則是暫時問題，例如郵箱已滿或連線一時失敗。SES 會自行重試軟退信，並在停止重試後通知寄件者；應用程式不可因暫時未見送達事件，就另行無限重寄同一封信。投訴表示收件人把訊息標為不想收到，與退信不同；投遞延遲亦未等於最終失敗。不同供應商的事件名稱和重試政策各異，流程要把供應商事件明確對應至業務狀態，不能只靠一個欄位猜測。

在業務層保存逐項事件歷史：請求發送、供應商接受、延遲、送達、退回、投訴或停止發送，並附發生時間及安全的供應商事件參照。事件可能在結帳頁回應後才到達，介面不可即時暗示已最終送達。若供應商重複發送通知，應按事件身分去重，再更新目前狀態，同時保留原始歷史供排查。收件地址改變時，應視為同一訂單的新聯絡決定，不應覆寫先前失敗的嘗試。一般日誌不要放訂單詳情、登入連結或完整客戶資料，才能在保留證據之餘避免新的外洩風險。

按影響與原因處理

重要訂單確認電郵若出現永久退信，應停止向該地址自動發送，並安排企業已有身分核實程序的其他聯絡方式。顧客登入後的帳戶頁可顯示訂單編號及狀態；合適時職員可使用已驗證的電話渠道。不能因來電者說出某電郵地址就透露訂單內容。請顧客透過已登入帳戶或其他既有核身程序改正地址，然後只補發必要通知。目標是恢復顧客取得重要資訊的途徑，同時避免打字錯誤演變成無限重寄或冒認風險。

若只是暫時延遲，應把業務狀態與電郵狀態分開。預約已確定時，在產品內顯示確認資料並說明電郵延遲，同時監察供應商最終事件。企業可訂出未解決通知何時交由職員跟進，但時限應按訊息急迫程度及供應商重試方式決定，不能憑空套用一個通用數字。即日預約提醒比每月例行結單更需即時處理。供應商最終報告退信時，改用已驗證的聯絡途徑；成功送達時，以真實事件及時間結案，而非靠職員猜測。

假設顧客完成預約時把電郵地址一個字母打錯。系統先保存預約並在畫面顯示參考編號；郵件供應商接受訊息後，回報硬退信。流程把該事件連到預約，阻止向同一錯誤地址再次自動寄送，並在預約團隊的工作清單建立聯絡任務。顧客其後登入、修正地址及要求新確認信，職員就能同時看到原先失敗的嘗試與新一次的投遞結果。這是設計情境，並非聲稱某企業已有相關成效數據；其重點是在通知可補救的同時，保持預約紀錄完整。

企業要掌握停止發送決定

SES 可在設定後使用帳戶級停止發送名單，自動記錄硬退信及投訴。名單按 AWS 帳戶及區域適用，而設定也可能因配置集或租戶而不同。不能假設供應商的全球停止發送名單就是企業完整的客戶聯絡資料庫，也不能因發送 API 回應成功，就認定被停止發送的地址收到訊息。應檢查實際供應商設定，並讓應用程式識別受限制的聯絡資料。若收據與推廣活動使用不同工具，須決定硬退信及投訴如何在工具間傳遞，同時保留交易必要通知與市場推廣偏好的分別。本文處理投遞失敗；同意與取消訂閱另有獨立規則。

不要為了讓重要電郵顯示已發送，就隨意清除停止發送紀錄。先查明失敗原因，與顧客核實修正或確認後的地址，再檢查供應商是否需要明確移除步驟。SES 指帳戶級名單的地址一般會保留至移除，但有文件列明的例外。SES 也指出，Gmail 不會透過這條途徑提供投訴資料；沒有投訴事件，不能證明所有收件人都歡迎訊息。客服說明應指出訂單仍可在帳戶查看，並提供安全的修正途徑，不可保證電郵必達。任何覆蓋停止發送設定的操作，都應記錄人員、原因及證據。

正式依賴此流程前，用受控地址或供應商測試設施測試整條路徑。確認硬退信只建立一項任務、重複通知不會重複建任務，而暫時延遲不會立即把有效地址列入停止發送。檢查職員能在不閱讀敏感郵件內容的情況下找到訂單，修正地址會產生可追蹤的新嘗試，未解決的重要通知會在業務期限前顯示。把接受、送達、退回及停止發送的數量與供應商報告核對，同時留意不同供應商事件覆蓋及到達時間可能有差異。驗收應證明顧客行動有可用的補救途徑，而非在分母不可靠時展示漂亮的送達率。

工作清單應按顧客的業務期限安排，而不是按供應商儀表板排序。與明日預約相關的投遞問題，今日就要讓有能力聯絡顧客的團隊看見；退回的存檔副本則可按另一時程檢查。向職員顯示訂單參考、聯絡資料核實狀態、事件原因及下一個獲准行動。查看失敗的權限，應與修改聯絡地址或解除停止發送的權限分開，否則善意職員也可能把確認信轉到未驗證的郵箱。讓顧客登入後自行查閱最新訂單或預約，避免訊息延誤時只能向客服查詢交易是否存在。測試時可刻意中斷事件接收，確認監察機制能發現停滯工作清單；若供應商通知根本沒有進來，退信處理器寫得再好也無用。營運驗收要證明有人負責、時限清楚且可補救，而不只是能解析事件。

聯絡政策要按訊息類型制定。收據、重設密碼、預約提醒及推廣活動的用途、期限和可用補救方式各不相同。重設連結退回時，不能把連結複製到客服聊天回覆；顧客修正地址後應安全地重新提出請求。預約提醒因時效高，可較早產生職員任務；收據則可在登入帳戶後重新取得。投遞失敗與顧客偏好也要分清：硬退信代表地址失敗，不等於顧客撤回推廣同意；取消訂閱涉及同意，不等於郵箱無效。即使不同工具共用聯絡資料庫，也應分別保存兩項事實，避免單一自動標記悄悄決定所有日後通訊。