Rapporter skal matche DLR, ikke afsendte antal

Afsendte antal kan virke beroligende: API'en accepterede beskeden, så ugen var en succes. Men denne tryghed holder ikke, når faktureringsugen skal gøres op. En rapport, der tæller afsendelser som succes, vil være uenig med DLR-kvitteringer, wallet-debiteringer for flersegment-trafik og webhook-audits.

IOSOR håndhæver reglen: rapporteksport følger leveringskvitteringer. Afsendt, sat i kø og accepteret til afsendelse forbliver operationelle spor. Leveret, fejlet og ukendt er de kolonner, som finans og produkt skal forholde sig til.

Afsendt er et spor, ikke en afslutningsmetrik

Accepteret til afsendelse beviser blot, at systemet modtog opgaven. Det beviser ikke, at modtagerens telefon modtog SMS'en. Hvis din rapportpakkes vigtigste KPI er afsendelser, vil du overvurdere succesen, hver gang andelen af ukendte eller fejlede beskeder stiger. Behold afsendt som en kapacitetskolonne, hvis det er nyttigt — men aldrig som en erstatning for leveret.

Indøv den faste afslutningsrutine: åbn DLR-kolonnerne først — ukendt, fejlet, leveret — og kig derefter på afsendelser for at se volumen. Produktlanceringsgennemgange bør bruge samme rækkefølge, så marketingslides ikke omdefinerer succes midt i ugen.

Eksportkolonner følger kvitteringer

Eksportschemaet navngiver kvitteringsstatustyperne eksplicit. Leveret kræver en DLR. Fejlet kræver et terminalt fejlsignal. Ukendt forbliver ukendt, indtil en kvittering modtages — det er ikke en blød leveret status. Faktureringsuger, der gemmer ukendt under succes, skaber den klassiske konflikt om ukendt andel.

Når segmentberegningen og regningen uoverensstemmer, skal du starte fra kvitteringsbaserede rækker og deres segmentantal — ikke afsendte totaler ganget med et gæt på gennemsnitlige segmenter. Den SMS-faktureringsuge-segmentsti forbliver tilstødende; rapporten afviser stadig afsendt som leveret.

Afstem webhooks og hovedbog mod de samme kvitteringer

Afstemning af webhook-audits mod hovedbogseksport er måden, hvorpå du beviser, at rapporten passer med virkeligheden. Daglige webhook-logs, DLR-statusser og forudbetalte hovedbogslinjer skal fortælle den samme historie. Hvis webhooks viser fejlet, mens rapporten viser succes, er rapporten forkert — ret eksporten i stedet for at 'justere' walleten.

Hold auditrutinen forudsigelig: én dag, webhook-kvitteringer, hovedbogseksport, rapportpakke, match besked-id'er. Afvigelser sendes til ops; opdigtet succes sendes tilbage til schema-ejerne.

Afvis afsendelsesbaserede faktureringsuger

Enhver afslutning, der fakturerer eller fejrer ugen baseret på afsendte antal alene, blokeres. Omskriv pakken, så finans drejer sig om leveret og ukendt andel. Hvis en partnerkontrakt stadig omtaler 'succesfulde API-afsendelser', skal du oversætte det sprog til DLR-noter — undlad at bøje kolonnerne for at passe til uklar formulering.

Relaterede driftstier

• Faktureringsuge for DLR: ukendt andel leveres ikke
• Afstemning af daglige webhook-logs mod forudbetalte saldi
• Første store SMS-faktura uge: når segmentregnestykket og regningen ikke stemmer

Start med IOSOR

Åbn ugens rapportpakke i IOSOR-konsollen og bekræft, at hver overskrifts-KPI bygger på DLR-kvitteringer — delivered, failed og unknown — ikke submits eller API-accepts. Hvis et diagram stadig tæller submit som succes, omdøb eller fjern det før finansluk. Eksportér én gang og del de samme kvitteringskolonner mellem produkt og finans.

IOSOR-pointe

Rapporter lukker på DLR-kvitteringer: delivered, failed og unknown — ikke på submits. Submit er throughput, aldrig leveringssandhed eller fakturaargument.

Gør: ét eksportskema låst til kvitteringsfelter. Gør ikke: produkt fejrer accepts, mens finans skændes om failed DLR.