En faktura eller ett kvitto är en del av en affärstransaktion, inte bara en kampanjkonvertering. En tillförlitlig process måste visa om dokumentet genererades, vilken auktoriserad destination som valdes och vad som hände med motsvarande meddelande. Autentisering hjälper till att fastställa avsändarens identitet, men den kan inte bevisa att en kund tagit emot eller agerat på dokumentet.
Gå med i affärseventet till posthändelsen
Tilldela en stabil identifierare för affärshändelser och en separat identifierare för meddelandeförsök. Spela in mallversion, auktoriserad mottagarkälla, sändningsrutt och slutresultat. Håll fakturainnehåll och finansiella detaljer borta från breda driftsloggar. Kundsupport behöver vanligtvis en status- och korrelationsreferens, inte obegränsad tillgång till varje bilaga.
Särskilja dokumentgenerering, inlämnande till ESP, mottagningsserveracceptans och kundbekräftelse. SMTP definierar överföringsansvar; den intygar inte att en faktura har lästs eller lagligen delgivits. RFC 5321. Gällande fakturerings- och aviseringsskyldighet kräver egen granskning.
Skydda transaktionsvägen
Kontrollera själva Från, kuvert och DKIM signering av identiteter på faktura- och kvittomallar. En leverantörs generiska installationsskärm kan inte visa att en viss integration använder den avsedda domänen. Bevara ett kontrollerat slutprov och det mottagande systemets betrodda autentiseringsresultat.
Se till att kritisk transaktionsbearbetning inte svälts av kampanjköer. Googles vägledning för personlig Gmail rekommenderar att du separerar meddelandekategorier i deras Från-adresser och håller kampanjer borta från kvitton. Dessa är rekommendationer för sändningsövningar, inte en garanti för isolerat rykte eller kökapacitet. Googles riktlinjer för avsändare.
Förena en realistisk sats
Tänk på en hypotetisk grupp med 1 000 unika kvittohändelser, med ett första försök per händelse. Vid första cutoff har 970 bekräftat mottagaracceptans, 20 är tillfälligt uppskjutna och tio har slutliga misslyckanden. Antag att varje uppskjuten händelse får ett tillåtet ytterligare försök. Vid den andra gränsen uppnår 15 av dessa acceptans och fem förblir väntande. De kumulativa händelsetillstånden är 985 accepterade, fem väntande och tio misslyckade, totalt samma 1 000 händelser.
Det gjordes 1 020 försök eftersom alla 20 uppskjutna händelser prövades en gång till. Rapportering av 985 accepterade av 1 020 försök eftersom leveranshastigheten för affärshändelser skulle blanda enheter. Eventets acceptansandel är 98,5 %, medan de återstående resultaten behöver separat hantering. Acceptans är fortfarande inte bevis på placering i inkorgen.
Dessa är handarbetade hypotetiska händelseräkningar, inte ett utfört avstämnings- eller externt sändningstest. En cutoff markerar rapporteringsfönstret, inte kvittodokumentets utgång. En riktig jämförelse bör bevara samma händelsepopulation och cutoff, och avslöja mall, destination eller leverantörsändringar. Saknade återuppringningar bör förbli okända tills de avstämts; frånvaro av fel är inte ett positivt leveransresultat.
Hantera undantag utan att ändra transaktionen
För permanenta fel, identifiera den returnerade orsaken och konsultera den godkända kontaktkorrigeringsprocessen. Omdirigera inte en faktura till en overifierad adress bara för att någon begär det. För osäkra inlämningar, stämma av leverantörsposten innan du spelar om en transaktion. Att skicka om ett kvitto bör inte skapa en ny faktura eller debitering.
Använd en autentiserad kundportal eller annan auktoriserad kontinuitetskanal när affärsprocessen stödjer det. Bifoga inte känsliga dokument till ett improviserat reservmeddelande utan att verifiera mottagare och tillstånd. Hålla ett rekord varav leveransförsök hänför sig till den ursprungliga affärshändelsen.
Den avslutande rapporten bör visa olösta händelser, ägare och nästa åtgärder, inte bara en sammanlagd grön leveransprocent. En kund som väntar på ett saknat kvitto spelar roll även när den totala acceptansgraden är hög.
Ge olösta händelser en ägare
För varje väntande eller misslyckad händelse, registrera nästa tillåtna åtgärd och dess ägare. En accepterad händelse behöver ingen blind omsändning bara för att göra en samlad rapport grönare. Varje kontinuitetskanal måste behålla den ursprungliga transaktionsidentiteten och den verifierade mottagaren.