IOSOR Ghiduri

Suprimări în campanii: omis nu înseamnă eșuat în registrul contabil

Aflați cum platformele CPaaS prepaid procesează suprimările pre-flight fără a afecta rezervările de sold, metricile de livrare sau reconcilierea contabilă.

Suprimări în campanii: omis nu înseamnă eșuat în registrul contabil.

Înțelegerea suprimărilor pre-flight în campaniile SMS

Când executați campanii SMS către mulți destinatari din liste dinamice de clienți, gestionarea dezabonărilor este o necesitate operatională și o cerință legală. Când un destinatart trimite cuvântul cheie STOP, numărul său în format E.164 este adăugat în baza de date locală de suprimare. În timpul trimiterilor ulterioare, platforma evaluează fiecare destinație comparativ cu această listă înainte de a trimite datele către rutele operatorilor. Această evaluare pre-flight previne traficul neconform și economisește costuri inutile.

Diferențierea între SKIPPED și FAILED în registrul contabil

O sursă frecventă de confuzie în reconcilierea campaniilor este gruparea mesajelor omise (SKIPPED) împreună cu eșecurile de livrare din rețea (FAILED). O eroare de rețea are loc după ce mesajul a fost transmis către rutele operatorului, în timp ce statusul de omis are loc înainte de orice interacțiune cu rețeaua. Când un mesaj eșuează din cauza aglomerării rețelei sau a rutării nevalide, o confirmare de livrare (DLR) Raportează un cod de eroare, iar rezervarea temporară se transformă în taxare permanentă sau rambursare parțială conform contractului.

Rezervările de sold prepaid și executarea în timp real

Pentru platformele care funcționează pe o arhitectură prepaid, lansarea campaniilor inițiază o rezervare temporară de autorizare pe soldul contului. Când un lot conține 10,000 de destinații, motorul calculează rezervarea estimată pe baza destinațiilor valide și nesuprimate. Dacă 1,000 de destinații sunt marcate ca suprimate, sistemul le exclude imediat din calculul rezervării de sold.

Piste de audit și observabilitate pe platforme

La monitorizarea trimiterilor prin webhook-uri sau panouri de control în timp real, administratorii platformei trebuie să alinieze codurile de stare între vizualizările de produs și cele financiare. Urmărirea detaliată a stării asigură posibilitatea echipelor operaționale de a diferenția între respingerile tăcute ale operatorilor — cum ar fi cele descrise în trimis nu este inbox — și omisiunile administrative.

Exportul datelor operaționale curate pentru finanțe

Echipa financiară care reconciliază rapoartele lunare de facturare necesită o separare clară între taxele de rutare și excluderile pre-flight. Includerea înregistrărilor omise în liniile de factură umflă artificial numărul total de mesaje și creează discrepanțe între jurnalele sistemului și soldurile facturilor. Exporturile standardizate de date separă cererile brute, unitățile trimise cu succes, unitățile nelivrate și unitățile omise pre-flight în coloane contabile dedicate.

Începeți cu IOSOR

Accesează consola IOSOR pentru a verifica regulile de pre-lansare ale campaniilor și asigură-te că numerele blocate local sunt marcate drept SĂRITE înainte de calcularea reținerilor pentru autorizare. Verifică fluxurile web de ieșire și șabloanele de export pentru facturare, astfel încât înregistrările SĂRITE să fie asociate unor evenimente cu cost zero, în loc de date privind eșecurile de rețea.

Rezumat IOSOR

Blocajele de pre-lansare îți protejează bugetul și reputația de expeditor prin eliminarea înregistrărilor de dezabonare înainte de expedierea în rețea. Marcarea acestor înregistrări drept SĂRITE în registrul contabil menține clare metricile privind volumul de mesaje, demonstrând că nu a avut loc nicio încercare de rutare în rețea și că nu s-a aplicat nicio reținere pentru autorizarea portofelului.

A fost util acest ghid?

Ghiduri conexe