IOSOR

IOSOR Kunnskap

Rapporter må samsvare med DLR, ikke sendingsantall

Sendt er ikke det samme som levert. Rapporter for økonomi og produkt må følge DLR-kvitteringer — fakturer aldri en uke basert på godkjent-for-sending alene.

Sendingsantall gir en falsk trygghet: API-en godtok meldingen, så uken virker 'vellykket'. Denne tryggheten sprekker når faktureringsuken skal gjøres opp. En rapport som teller sendinger som suksess vil avvike fra DLR-kvitteringer, wallet-belastninger for flersegment-trafikk og webhook-revisjoner.

IOSOR håndhever regelen: rapporteksporter følger leveringskvitteringer. Sendt, i kø og godkjent-for-sending forblir operative sporinger. Levert, mislyktes og ukjent er kolonnene økonomi og produkt må forholde seg til.

Sendt er et spor, ikke en avslutningsmetrikk

Godkjent-for-sending beviser bare at systemet tok imot jobben. Det beviser ikke at mottakerens mobil mottok SMS-en. Hvis rapportpakken din har sendingsantall som viktigste KPI, vil du overvurdere suksessen hver gang andelen ukjente eller mislyktede meldinger øker. Behold sendt som en kapasitetskolonne om nødvendig — men aldri som en erstatning for levert status.

Tren på den faste avslutningsrutinen: åpne DLR-kolonnene først — ukjent, mislyktes, levert — og se deretter på sendingsvolum. Gjennomgang av produktlanseringer bør bruke samme rekkefølge slik at markedsføring ikke omdefinerer suksess midt i uken.

Eksportkolonner følger kvitteringer

Eksportskjemaet navngir kvitteringsstatuser eksplisitt. Levert krever en DLR. Mislyktes krever et terminalt feilsignal. Ukjent forblir ukjent inntil en kvittering mottas — det er ikke en myk levert status. Faktureringsuker som gjemmer ukjent under suksess skaper den klassiske konflikten om ukjent andel.

Når segmentberegningen og regningen avviker, start fra kvitteringsbaserte rader og deres segmentantall — ikke sendte totaler ganget med et estimert segmentgjennomsnitt. Veien for SMS-faktureringsuke forblir tilstøtende; rapporten avviser fremdeles sendt-som-levert.

Avstem webhooks og hovedbok mot de samme kvitteringene

Revisjon av webhooks mot hovedbokseksporter er måten du beviser at rapporten ikke er oppspinn. Daglige webhook-logger, DLR-statuser og forhåndsbetalte hovedboklinjer må fortelle den samme historien. Hvis webhooks viser mislyktes mens rapporten viser suksess, er rapporten feil — rett opp eksporten i stedet for å 'justere' wallet-saldoen.

Hold revisjonsrutinen enkel: én dag, webhook-kvitteringer, hovedbokseksport, rapportpakke, match meldings-ID-er. Avvik sendes til ops; oppdiktet suksess sendes tilbake til skjemaansvarlige.

Avvis sendingsbaserte faktureringsuker

Enhver avslutning som fakturerer eller feirer uken basert på sendingsantall alene blir blokkert. Skriv om rapportpakken slik at økonomi fokuserer på levert og ukjent andel. Hvis en partnerkontrakt fortsatt omtaler 'vellykkede API-sendinger', oversetter du det språket til DLR-notater — ikke bøy kolonnene for å passe til feil begrepsbruk.

Relaterte driftstier

Start med IOSOR

Åpne ukens rapportpakke i IOSOR-konsollen og bekreft at hver overskrifts-KPI bygger på DLR-kvitteringer — delivered, failed og unknown — ikke submits eller API-accepts. Hvis et diagram fortsatt teller submit som suksess, gi nytt navn eller fjern det før finanslukking. Eksporter én gang og del de samme kvitteringskolonnene mellom produkt og finans.

IOSOR-lærdom

Rapporter lukkes på DLR-kvitteringer: delivered, failed og unknown — ikke på submits. Submit er throughput, aldri leveringssannhet eller fakturaargument.

Gjør: ett eksportskjema låst til kvitteringsfelt. Ikke: produkt feirer accepts mens finans krangler om failed DLR.

Var denne guiden nyttig?

Relaterte veiledninger