發票或收據是業務交易的一部分，而不僅僅是行銷活動轉換。可靠的流程必須顯示文件是否已產生、選擇了哪個授權目的地以及相應的訊息發生了什麼。身份驗證有助於確定寄件者身份，但無法證明客戶已收到文件或對文件進行了操作。
加入商務活動到郵件活動
分配穩定的業務事件識別碼和單獨的訊息嘗試標識符。記錄範本版本、授權接收來源、發送路徑和最終結果。將發票內容和財務詳細資訊排除在廣泛的操作日誌之外。客戶支援通常需要狀態和相關參考，而不是無限制地存取每個附件。
區分文檔生成、提交 ESP、接收伺服器驗收和客戶確認。 SMTP定義傳輸責任；它並未證明發票已被閱讀或合法送達。 RFC 5321。適用的發票和通知義務需要自行審查。
保護交易路徑
檢查實際的寄件者、信封和 DKIM 在發票和收據範本上簽署身分。供應商的通用設定畫面無法證明特定整合使用了預期的網域。保留受控的最終樣本和接收系統的可信身份驗證結果。
防止關鍵事務處理因活動佇列而陷入飢餓狀態。 Google 針對個人Gmail指南建議將寄件者地址中的郵件類別分開，並將促銷訊息排除在收據之外。這些是發送實踐建議，並不是孤立聲譽或隊列容量的保證。 Google 寄件者指南.
協調實際批次
假設有一批 1,000 個唯一的接收事件，每個事件都有一次初始嘗試。在第一次截止時，970 人已確認接受者接受，20 人暫時推遲，10 人最終失敗。假設每個延遲事件收到一次允許的額外嘗試。在第二次截止時，其中 15 項已獲得接受，另外 5 項仍待批准。累計事件狀態為 985 個已接受、5 個待處理和 10 個失敗，總共有 1,000 個事件。
總共有 1,020 次嘗試，因為所有 20 個推遲的事件都被再次嘗試。報告 1,020 次嘗試中有 985 次被接受，因為業務活動交付率會混合單位。事件接受率為98.5%，其餘結果需個別處理。接受仍然不能證明收件匣已放置。
這些是手動假設的事件計數，而不是執行的協調或外部發送測試。截止標記的是報告窗口，而不是收據文件到期時間。真正的比較應該保留相同的事件群體和截止時間，並揭露模板、目的地或提供者的變化。在協調之前，遺失的回調應該保持未知狀態；沒有錯誤並不是積極的交付結果。
處理異常而不改變交易
對於永久性故障，請確定退回原因並諮詢已核准的接觸糾正流程。不要僅僅因為有人要求將發票重定向到未經驗證的地址。對於不確定的提交，請在重播交易之前協調提供者記錄。重新發送收據不應建立新的發票或費用。
當業務流程支援時，使用經過驗證的客戶入口網站或其他授權的連續性管道。在未驗證收件者和權限的情況下，請勿將敏感文件附加到臨時後備訊息中。保持 一個記錄 其中交付嘗試與原始業務事件相關。
結案報告應顯示未解決的事件、所有者和下一步行動，而不僅僅是綠色交付總量百分比。即使整體接受率很高，等待一張遺失收據的客戶也很重要。
為未解決的事件指定所有者
對於每個待處理或失敗的事件，記錄下一個允許的操作及其擁有者。已接受的事件不需要盲目地重新發送，只是為了使 總結報告 更環保。任何連續性通道都必須保留原始交易身分和經過驗證的接收者。