Rapporter måste matcha DLR, inte antalet skickade

Antalet skickade meddelanden skapar en falsk trygghet: API:et tog emot meddelandet, så veckan verkar lyckad. Men den tryggheten spricker vid ekonomisk avstämning. En rapport som räknar mottagna anrop som framgång kommer att strida mot DLR-kvitton, plånboksavdrag för flersegmentstrafik och webhook-revisioner.

IOSOR tillämpar en strikt regel: rapportexporter följer alltid leveranskvitton (DLR). Statusarna skickad, köad och accepterad för sändning förblir operativa spår. Levererad, misslyckad och okänd är de enda kolumner som ekonomi- och produktteam baserar sina beslut på.

Skickat är ett operativt spår, inte ett stängningsmått

Att ett meddelande accepteras för sändning bevisar bara att systemet har tagit emot uppgiften. Det bevisar inte att mottagarens enhet har tagit emot SMS:et. Om den viktigaste KPI:n i ditt rapportpaket är antalet skickade meddelanden kommer du att överskatta framgången så snart andelen misslyckade eller okända statusar ökar. Behåll skickat som en kapacitetskolumn om det behövs — men använd det aldrig som en ersättning för levererade meddelanden. Etablera en korrekt stängningsrutin: öppna DLR-kolumnerna först — okänd, misslyckad, levererad — och titta först därefter på antalet skickade för att bedöma volymen.

Exportkolumner följer leveranskvitton

Exportstrukturen namnger kvittostatusar explicit. Levererad kräver ett bekräftat DLR. Misslyckad kräver en slutgiltig felsignal. Okänd förblir okänd tills ett kvitto inkommer — det är inte en mjuk leverans. Fakturaveckor som döljer okänd status inom kategorin framgång skapar de klassiska tvisterna om den verkliga leveransandelen. När segmentmatematiken och fakturan inte stämmer överens ska du utgå från rader med DLR-bekräftelse och deras exakta segmentantal — inte från totalt skickat multiplicerat med ett uppskattat genomsnitt.

Stäm av webhooks och huvudbok mot samma kvitton

Avstämning av webhook-revisioner mot huvudboksexporten är sättet du bevisar att rapporten stämmer med verkligheten. Dagliga webhook-loggar, DLR-statusar och förbetalda huvudboksrader måste berätta exakt samma historia. Om webhooks visar misslyckats medan rapporten visar framgång är rapporten felaktig — korrigera exporten och justera inte plånbokssaldot manuellt.

Håll auditrutinen enkel: välj en dag, jämför webhook-kvitton, huvudboksexport och rapportpaket utifrån meddelande-ID. Avvikelser skickas till driftteamet; felaktiga framgångssiffror skickas tillbaka till rapportansvariga.

Vägra fakturaveckor baserade på skickade meddelanden

Varje veckostängning som fakturerar eller firar framgång enbart baserat på antalet skickade meddelanden måste stoppas. Skriv om rapportpaketet så att ekonomiavdelningen fokuserar på andelen levererade och okända meddelanden. Om ett partneravtal fortfarande talar om lyckade API-sändningar, översätt det språket till DLR-anteckningar istället för att ändra rapportkolumnerna.

Relaterade driftsvägar

• Faktura vecka DLR: okänd andel levereras inte
• Avstämning av dagliga webhook-loggar mot förbetalda saldon
• SMS-fakturans vecka: när segmentmatematik och faktura inte matchar

Börja med IOSOR

Öppna veckans rapportpaket i IOSOR-konsolen och bekräfta att varje rubrik-KPI bygger på DLR-kvitton — delivered, failed och unknown — inte submits eller API-accepts. Om ett diagram fortfarande räknar submit som framgång, byt namn eller ta bort det före finansstängning. Exportera en gång och dela samma kvittokolumner mellan produkt och finans.

IOSOR sammanfattning

Rapporter stängs på DLR-kvitton: delivered, failed och unknown — inte på submits. Submit är throughput, aldrig leveranssanning eller fakturaargument.

Gör: ett exportschema låst till kvittfält. Gör inte: produkt firar accepts medan finans bråkar om failed DLR.