Izvješća moraju odgovarati DLR-u, a ne broju slanja

Brojki slanja pružaju lažan osjećaj sigurnosti: API je prihvatio poruku, pa je tjedan 'uspio'. Taj se osjećaj raspada tijekom tjedna fakturiranja. Izvješće koje broji slanja kao uspjeh bit će u suprotnosti s potvrdnicama DLR-a, terećenjima novčanika za višesegmentni promet i revizijama webhooka.

IOSOR primjenjuje pravilo: izvozi izvješća slijede potvrdnice isporuke. Poslano, na čekanju i prihvaćeno za slanje ostaju operativni tragovi. Isporučeno, neuspjelo i nepoznato stupci su o kojima raspravljaju financije i proizvod.

Poslano je trag, a tidak metrika zatvaranja

Prihvaćanje za slanje samo dokazuje da je sustav preuzeo zadatak. Ne dokazuje da je primateljev uređaj primio SMS. Ako je glavni KPI vašeg paketa izvješća broj slanja, precijenit ćete uspjeh svaki put kada se poveća udio nepoznatih ili neuspjelih poruka. Zadržite poslano kao stupac kapaciteta ako je korisno — ali nikada kao zamjenu za isporučeno.

Uvježbajte rutinu zatvaranja: najprije otvorite stupce DLR-a — nepoznato, neuspjelo, isporučeno — a zatim pogledajte ukupna slanja radi volumena. Pregledi lansiranja proizvoda trebaju koristiti isti redoslijed kako marketinške prezentacije ne bi redefinirale uspjeh sredinom tjedna.

Stupci izvoza slijede potvrdnice

Shema izvoza eksplicitno imenuje stanja potvrdnica. Isporučeno zahtijeva DLR. Neuspjelo zahtijeva konačni signal pogreške. Nepoznato ostaje nepoznato dok ne stigne potvrdnica — to nije blago isporučeno stanje. Tjedni fakturiranja koji skrivaju nepoznato unutar uspjeha stvaraju klasični spor oko neisporučenog udjela.

Kada se matematika segmenata i račun ne podudaraju, krenite od redaka potkrijepljenih potvrdnicama i njihovog broja segmenata — a ne od ukupnog broja slanja pomnoženog s procijenjenim prosjekom segmenata. Put tjedna SMS fakturiranja ostaje povezan; izvješće i dalje odbija tretirati poslano kao isporučeno.

Uskladite webhooke i glavnu knjigu prema istim potvrdnicama

Usklađivanje revizije webhooka s izvozom glavne knjige način je na koji dokazujete da izvješće nije fikcija. Dnevni zapisi webhooka, stanja DLR-a i retci pretplaćene glavne knjige moraju pričati istu priču. Ako webhooki prikazuju neuspjeh dok izvješće prikazuje uspjeh, izvješće je pogrešno — ispravite izvoz, nemojte 'prilagođavati' novčanik.

Održavajte rutinu revizije predvidljivom: jedan dan, potvrdnice webhooka, izvoz glavne knjige, paket izvješća, podudaranje ID-ova poruka. Odstupanja idu operativnom timu; izmišljeni uspjeh vraća se vlasnicima sheme.

Odbijte tjedne fakturiranja temeljene na slanju

Svako zatvaranje koje fakturira ili slavi uspjeh samo na temelju broja slanja se blokira. Prepišite paket tako da se financije usmjere na udio isporučenih i nepoznatih poruka. Ako ugovor s partnerom i dalje navodi 'uspješna slanja API-ja', prevedite taj jezik u bilješke DLR-a — nemojte prilagođavati stupce lošim formulacijama.

Povezani operativni putovi

• Tjedan fakturiranja: nepoznati udio DLR-a nije isporučen
• Usklađivanje dnevnih zapisa webhooka s pretplaćenim stanjima
• Tjedan SMS fakturiranja: kada se matematika segmenata i račun ne podudaraju

Započnite s IOSOR-om

Otvorite tjedni paket izvještaja u konzoli IOSOR i potvrdite da svaki naslovni KPI stoji na DLR potvrdama — delivered, failed i unknown — ne na submitima ni API acceptima. Ako grafikon još tretira submit kao uspjeh, preimenujte ili uklonite prije financijskog zatvaranja. Izvezite jednom i dijelite iste stupce potvrda između proizvoda i financija.

Sažetak IOSOR

Izvještaji se zatvaraju na DLR potvrdama: delivered, failed i unknown — ne na submitima. Submit je samo throughput, nikad istina isporuke ni argument računa.

Radite: jednu shemu izvoza na polja potvrda. Ne radite: proizvod slavi accepte dok financije raspravljaju failed DLR.