請求書または領収書は、単なるキャンペーンの変換ではなく、ビジネストランザクションの一部です。信頼できるプロセスでは、ドキュメントが生成されたかどうか、承認された宛先が選択されたか、対応するメッセージに何が起こったかを示す必要があります。認証は送信者の身元を証明するのに役立ちますが、顧客が文書を受信したこと、または文書に基づいて行動したことを証明することはできません。
ビジネスイベントにメールイベントに参加する
安定したビジネス イベント ID と別のメッセージ試行 ID を割り当てます。テンプレートのバージョン、承認された受信者のソース、送信ルート、および最終結果を記録します。請求書の内容と財務詳細を広範な運用ログに記録しないでください。通常、カスタマー サポートには、すべての添付ファイルへの無制限のアクセスではなく、ステータスと相関関係の参照が必要です。
文書の作成、提出を区別する ESP、受信サーバーの受け入れと顧客の確認。 SMTP転送責任を定義します。請求書が読まれたこと、または合法的に送達されたことを証明するものではありません。 RFC 5321。適用される請求書発行および通知義務については、独自のレビューが必要です。
トランザクションルートを保護する
実際の From、エンベロープ、および DKIM 請求書と領収書のテンプレートに署名する。ベンダーの一般的な設定画面では、特定の統合が目的のドメインを使用していることを示すことができません。管理された最終サンプルと受信システムの信頼できる認証結果を保存します。
重要なトランザクション処理がキャンペーン キューによって枯渇するのを防ぎます。個人用Gmailに関する Google のガイダンスでは、差出人アドレスでメッセージ カテゴリを分離し、受信メールにプロモーションを含めないようにすることを推奨しています。これらは送信方法に関する推奨事項であり、分離された評判やキュー容量を保証するものではありません。 Google 送信者のガイドライン.
現実的なバッチを調整する
イベントごとに最初の試行が 1 回ある、1,000 個の一意の受信イベントの仮想バッチを考えてみましょう。最初のカットオフでは、970 件が受信機の受け入れを確認し、20 件が一時的に延期され、10 件が最終的に失敗しました。各遅延イベントが許可された追加の試行を 1 つ受け取ると仮定します。 2 回目の締め切り時点では、そのうち 15 件が承認に達し、5 件は保留中のままです。累積イベント状態は、985 が受け入れられ、5 が保留中、10 が失敗し、合計は同じ 1,000 イベントになります。
20 個の遅延イベントすべてがもう一度試行されたため、試行回数は 1,020 回でした。ビジネス イベントの配信率によってユニットが混在するため、レポートでは 1,020 件の試行のうち 985 件が受け入れられました。イベントの受け入れ率は 98.5% ですが、残りの結果は個別に処理する必要があります。受け入れられたとしても、受信トレイに配置されたことの証明にはなりません。
これらは手動で作成された仮想のイベント数であり、実行された調整や外部送信テストではありません。カットオフは、受領文書の有効期限ではなく、レポート期間をマークします。実際の比較では、同じイベント数とカットオフを保持し、テンプレート、宛先、またはプロバイダーの変更を明らかにする必要があります。不足しているコールバックは、調整されるまで不明のままにする必要があります。エラーがないことは、肯定的な配信結果ではありません。
トランザクションを変更せずに例外を処理する
永続的な障害の場合は、返品された理由を特定し、承認された接触修正プロセスを参照してください。誰かが要求したからといって、請求書を未確認のアドレスにリダイレクトしないでください。送信内容が不確かな場合は、トランザクションを再実行する前にプロバイダー レコードを調整します。領収書を再送信しても、新しい請求書や料金は作成されません。
ビジネス プロセスがサポートしている場合は、認証されたカスタマー ポータルまたは別の承認された継続チャネルを使用します。受信者と許可を確認せずに、即興のフォールバック メッセージに機密文書を添付しないでください。保つ 記録 その配信試行は元のビジネス イベントに関連しています。
終了レポートには、単にグリーンデリバリの合計パーセンテージだけでなく、未解決のイベント、所有者、次のアクションも表示される必要があります。全体的な受領率が高くても、顧客が 1 枚の受領書が欠けているのを待っていることは重要です。
未解決のイベントに所有者を与える
保留中のイベントまたは失敗したイベントごとに、次に許可されるアクションとその所有者を記録します。受け入れられたイベントは、単に送信するためだけにブラインド再送信する必要はありません。 集計レポート より緑に。継続性チャネルはすべて、元のトランザクション ID と検証された受信者を保持する必要があります。