Reporty musí odpovídat DLR, nikoli počtům odeslání

Počty odeslání působí uklidňujícím dojmem: API zprávu přijalo, takže týden 'fungoval'. Tento pocit se však rozpadne při uzávěrce fakturačního týdne. Report, který započítává odeslání jako úspěch, bude v rozporu s potvrdkami DLR, odpisy z peněženky za vícesegmentový provoz a audity webhooků.

IOSOR prosazuje jasné pravidlo: exporty reportů se řídí doručenkami. Stavy odesláno, v frontě a přijato k odeslání zůstávají provozními stopami. Doručeno, selhalo a neznámé jsou sloupce, o kterých diskutuje finance a produkt.

Odesláno je pouze stopa, nikoli finální metrika

Přijetí k odeslání pouze dokazuje, že systém převzal úlohu. Nepotvrzuje, že mobilní zařízení SMS přijalo. Pokud je hlavním KPI vaší sestavy počet odeslání, přeceňujete úspěšnost vždy, když vzroste podíl neznámých nebo selhaných zpráv. Ponechte odesláno jako kapacitní sloupec, pokud je to užitečné — ale nikdy ne jako náhradu za doručeno.

Zaveďte pravidelný postup uzávěrky: nejprve otevřete sloupce DLR — neznámé, selhalo, doručeno — a až poté zkontrolujte celkové objemy odeslání. Zvláštní pozornost věnujte produktovým prezentacím, aby marketingové podklady neměnily definici úspěchu uprostřed týdne.

Exportní sloupce sledované podle doručenek

Schéma exportu definuje stavy doručenek explicitně. Doručeno vyžaduje DLR. Selhalo vyžaduje koncový chybový signál. Neznámé zůstává neznámým, dokud nedorazí doručenka — nejedná se o měkké doručení. Fakturační týdny, které skrývají neznámý stav do úspěchu, vytvářejí klasické spory o nedoručený podíl.

Pokud se matematika segmentů a vyúčtování rozcházejí, začněte od řádků podložených doručenkami a jejich počtu segmentů — nikoli od celkových odeslání vynásobených odhadovaným průměrem. Cesta pro fakturační týden SMS zůstává propojená; report stále odmítá uznat odeslání jako doručení.

Odsouhlasení webhooků a hlavní knihy podle stejných doručenek

Odsouhlasení auditů webhooků vůči exportu hlavní knihy je způsob, jak prokázat, že report odpovídá realitě. Denní protokoly webhooků, stavy DLR a řádky předplacené hlavní knihy musí vyprávět jediný příběh. Pokud webhooky ukazují selhání, zatímco report uvádí úspěch, report je chybný — opravte export, neupravujte zůstatek peněženky.

Udržujte auditní rutinu standardizovanou: jeden den, potvrdky webhooků, export hlavní knihy, sestava reportů a shoda ID zpráv. Odchylky řeší provozní tým; fiktivní úspěch se vrací správcům schématu.

Odmítněte fakturační týdny založené na odeslání

Jakákoli uzávěrka, která fakturuje nebo vykazuje úspěch pouze na základě počtu odeslání, je zablokována. Přepracujte sestavu tak, aby se finance soustředily na podíl doručených a neznámých zpráv. Pokud smlouva s partnerem stále obsahuje formulaci 'úspěšná API odeslání', přeložte tento jazyk do poznámek DLR — neupravujte sloupce tak, aby odpovídaly špatné definici.

Související provozní cesty

• Fakturační týden DLR: neznámý podíl není doručen
• Odsouhlasení denních protokolů webhooků s předplacenými zůstatky
• První náročný fakturační týden: když matematika segmentů nesouhlasí s účtem

Začněte s IOSOR

Otevřete týdenní balíček reportů v konzoli IOSOR a ověřte, že každý headline KPI stojí na DLR potvrzeních — delivered, failed a unknown — ne na submitech ani API acceptech. Pokud graf stále bere submit jako úspěch, přejmenujte nebo odstraňte ho před finančním uzavřením. Exportujte jednou a sdílejte stejné sloupce potvrzení mezi produktem a financemi.

Shrnutí IOSOR

Reporty se uzavírají na DLR potvrzeních: delivered, failed a unknown — ne na submitech. Submit je jen throughput, nikdy pravda doručení ani argument faktury.

Dělejte: jedno exportní schéma na pole potvrzení. Nedělejte: produkt slaví accepty, zatímco finance se hádají o failed DLR.