发票或收据是业务交易的一部分，而不仅仅是营销活动转换。可靠的流程必须显示文档是否已生成、选择了哪个授权目的地以及相应的消息发生了什么。身份验证有助于确定发件人身份，但无法证明客户已收到文档或对文档进行了操作。
加入商务活动到邮件活动
分配稳定的业务事件标识符和单独的消息尝试标识符。记录模板版本、授权接收来源、发送路径和最终结果。将发票内容和财务详细信息排除在广泛的操作日志之外。客户支持通常需要状态和相关参考，而不是无限制地访问每个附件。
区分文档生成、提交 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%，其余结果需要单独处理。接受仍然不能证明收件箱已放置。
这些是手工假设的事件计数，而不是执行的协调或外部发送测试。截止标记的是报告窗口，而不是收据文档到期时间。真正的比较应该保留相同的事件群体和截止时间，并披露模板、目的地或提供商的变化。在协调之前，丢失的回调应该保持未知状态；没有错误并不是积极的交付结果。
处理异常而不改变交易
对于永久性故障，请确定退回原因并咨询批准的接触纠正流程。不要仅仅因为有人要求将发票重定向到未经验证的地址。对于不确定的提交，请在重播交易之前协调提供商记录。重新发送收据不应创建新的发票或费用。
当业务流程支持时，使用经过身份验证的客户门户或其他授权的连续性渠道。在未验证收件人和权限的情况下，请勿将敏感文档附加到临时后备消息中。保持 一个记录 其中交付尝试与原始业务事件相关。
结案报告应显示未解决的事件、所有者和下一步行动，而不仅仅是绿色交付总量百分比。即使总体接受率很高，等待一张丢失收据的客户也很重要。
为未解决的事件指定所有者
对于每个待处理或失败的事件，记录下一个允许的操作及其所有者。已接受的事件不需要盲目地重新发送，只是为了使 汇总报告 更环保。任何连续性通道都必须保留原始交易身份和经过验证的接收者。