Uma fatura ou recibo faz parte de uma transação comercial e não apenas de uma conversão de campanha. Um processo confiável deve mostrar se o documento foi gerado, qual destino autorizado foi selecionado e o que aconteceu com a mensagem correspondente. A autenticação ajuda a estabelecer a identidade do remetente, mas não pode provar que um cliente recebeu ou agiu de acordo com o documento.
Junte-se ao evento de negócios ao evento de correio
Atribua um identificador de evento de negócios estável e um identificador de tentativa de mensagem separado. Versão do modelo de registro, origem do destinatário autorizado, rota de envio e resultado final. Mantenha o conteúdo das faturas e os detalhes financeiros fora dos amplos registros operacionais. O suporte ao cliente geralmente precisa de uma referência de status e correlação, e não de acesso irrestrito a todos os anexos.
Distinguir geração de documentos, submissão ao ESP, aceitação do servidor receptor e reconhecimento do cliente. SMTP define responsabilidade de transferência; não certifica que uma fatura foi lida ou entregue legalmente. RFC 5321. As obrigações aplicáveis de faturamento e notificação exigem sua própria revisão.
Proteja a rota transacional
Verifique o De, envelope e DKIM assinar identidades em modelos de faturas e recibos. A tela de configuração genérica de um fornecedor não pode demonstrar que uma integração específica usa o domínio pretendido. Preserve uma amostra final controlada e os resultados de autenticação confiável do sistema receptor.
Evite que o processamento de transações críticas seja prejudicado por filas de campanha. A orientação do Google para Gmail pessoal recomenda separar categorias de mensagens em seus endereços De e manter as promoções fora dos recibos. Estas são recomendações de práticas de envio e não uma garantia de reputação isolada ou capacidade de fila. Diretrizes para remetentes do Google.
Reconcilie um lote realista
Considere um lote hipotético de 1.000 eventos de recebimento exclusivos, com uma tentativa inicial por evento. No primeiro ponto de corte, 970 confirmaram a aceitação do receptor, 20 estão temporariamente adiados e dez apresentam falhas finais. Suponha que cada evento adiado receba uma tentativa adicional permitida. No segundo ponto de corte, 15 deles são aceitos e cinco permanecem pendentes. Os estados de eventos cumulativos são 985 aceitos, cinco pendentes e dez com falha, totalizando os mesmos 1.000 eventos.
Houve 1.020 tentativas porque todos os 20 eventos adiados foram tentados mais uma vez. Relatando 985 tentativas aceitas em 1.020, pois a taxa de entrega de eventos de negócios misturaria unidades. A fração de aceitação do evento é de 98,5%, enquanto os resultados restantes precisam de tratamento separado. A aceitação ainda não é prova de colocação na caixa de entrada.
Estas são contagens de eventos hipotéticos feitas à mão, não uma reconciliação executada ou um teste de envio externo. Um corte marca a janela do relatório, e não a expiração do documento de recebimento. Uma comparação real deve preservar a mesma população e limite de eventos e divulgar alterações de modelo, destino ou fornecedor. Os retornos de chamada ausentes devem permanecer desconhecidos até serem reconciliados; a ausência de erro não é um resultado de entrega positivo.
Lidar com exceções sem alterar a transação
Para falhas permanentes, identifique o motivo retornado e consulte o processo aprovado de correção de contato. Não redirecione uma fatura para um endereço não verificado apenas porque alguém a solicitou. Para envios incertos, reconcilie o registro do provedor antes de reproduzir uma transação. O reenvio de um recibo não deve criar uma nova fatura ou cobrança.
Use um portal de cliente autenticado ou outro canal de continuidade autorizado quando o processo de negócios oferecer suporte. Não anexe documentos confidenciais a uma mensagem substituta improvisada sem verificar o destinatário e a permissão. Manter um recorde cuja tentativa de entrega se refere ao evento comercial original.
O relatório de encerramento deve mostrar eventos não resolvidos, proprietários e próximas ações, e não apenas uma percentagem agregada de entrega verde. Um cliente que espera por um recibo perdido é importante mesmo quando a taxa geral de aceitação é alta.
Dê um proprietário aos eventos não resolvidos
Para cada evento pendente ou com falha, registre a próxima ação permitida e seu proprietário. Um evento aceito não precisa de reenvio cego simplesmente para fazer uma relatório agregado mais verde. Qualquer canal de continuidade deve manter a identidade da transação original e o destinatário verificado.