Una fattura o ricevuta fa parte di una transazione commerciale, non semplicemente di una conversione di campagna. Un processo affidabile deve mostrare se il documento è stato generato, quale destinazione autorizzata è stata selezionata e cosa è successo al messaggio corrispondente. L'autenticazione aiuta a stabilire l'identità del mittente, ma non può dimostrare che un cliente abbia ricevuto o agito sul documento.
Unisci l'evento aziendale all'evento di posta
Assegnare un identificatore di evento aziendale stabile e un identificatore di tentativo di messaggio separato. Registra la versione del modello, l'origine del destinatario autorizzato, il percorso di invio e il risultato finale. Mantieni il contenuto delle fatture e i dettagli finanziari fuori dai registri operativi generali. L'assistenza clienti di solito necessita di un riferimento allo stato e alla correlazione, non di un accesso illimitato a ogni allegato.
Distinguere la generazione di documenti, l'invio al ESP, accettazione del server ricevente e riconoscimento del cliente. SMTP definisce la responsabilità del trasferimento; non certifica che una fattura sia stata letta o notificata legalmente. RFC 5321. Gli obblighi di fatturazione e notifica applicabili richiedono una propria revisione.
Proteggi il percorso transazionale
Controlla il mittente effettivo, la busta e DKIM identità di firma sui modelli di fatture e ricevute. La schermata di configurazione generica di un fornitore non può dimostrare che una particolare integrazione utilizza il dominio previsto. Conserva un campione finale controllato e i risultati dell'autenticazione attendibile del sistema ricevente.
Evita che l'elaborazione critica delle transazioni venga compromessa dalle code delle campagne. Le indicazioni di Google per Gmail personale consigliano di separare le categorie di messaggi negli indirizzi Da e di escludere le promozioni dalle ricevute. Si tratta di raccomandazioni pratiche di invio, non di una garanzia di reputazione isolata o capacità della coda. Linee guida per il mittente di Google.
Riconciliare un lotto realistico
Considera un ipotetico batch di 1.000 eventi di ricezione univoci, con un tentativo iniziale per evento. Al primo cut-off, 970 hanno confermato l'accettazione del ricevitore, 20 sono temporaneamente rinviati e dieci hanno fallimenti finali. Supponiamo che ogni evento rinviato riceva un tentativo aggiuntivo consentito. Alla seconda scadenza, 15 di questi raggiungono l'accettazione e cinque rimangono in sospeso. Gli stati degli eventi cumulativi sono 985 accettati, cinque in sospeso e dieci non riusciti, per un totale degli stessi 1.000 eventi.
Ci sono stati 1.020 tentativi perché tutti i 20 eventi rinviati sono stati tentati ancora una volta. Segnalazione accettata 985 su 1.020 tentativi in quanto il tasso di consegna di eventi aziendali mischierebbe le unità. La frazione di accettazione dell'evento è del 98,5%, mentre i restanti risultati necessitano di una gestione separata. L'accettazione non è ancora una prova del posizionamento della casella di posta.
Si tratta di conteggi di eventi ipotetici elaborati manualmente, non di una riconciliazione eseguita o di un test di invio esterno. Un limite contrassegna la finestra di reporting, non la scadenza del documento di ricevuta. Un confronto reale dovrebbe preservare la stessa popolazione di eventi e la stessa soglia limite e rivelare le modifiche al modello, alla destinazione o al fornitore. Le richiamate mancanti dovrebbero rimanere sconosciute fino alla riconciliazione; l'assenza di un errore non costituisce un risultato positivo della consegna.
Gestisci le eccezioni senza modificare la transazione
Per guasti permanenti, identificare il motivo del reso e consultare il processo di correzione dei contatti approvato. Non reindirizzare una fattura a un indirizzo non verificato solo perché qualcuno lo richiede. Per invii incerti, riconciliare il record del fornitore prima di riprodurre una transazione. Il nuovo invio di una ricevuta non dovrebbe creare una nuova fattura o addebito.
Utilizzare un portale clienti autenticato o un altro canale di continuità autorizzato quando il processo aziendale lo supporta. Non allegare documenti sensibili a un messaggio di fallback improvvisato senza verificare il destinatario e l'autorizzazione. Mantenere un record di cui il tentativo di consegna si riferisce all'evento commerciale originale.
Il report di chiusura dovrebbe mostrare eventi irrisolti, proprietari e azioni successive, non solo una percentuale di consegna verde aggregata. Un cliente in attesa di una ricevuta mancante è importante anche quando il tasso di accettazione complessivo è elevato.
Assegna un proprietario agli eventi irrisolti
Per ogni evento in sospeso o non riuscito, registra la successiva azione consentita e il suo proprietario. Un evento accettato non necessita di un nuovo rinvio cieco semplicemente per creare un rapporto aggregato più verde. Qualsiasi canale di continuità deve mantenere l'identità della transazione originale e il destinatario verificato.