I report devono corrispondere ai DLR, non ai conteggi di invio

I conteggi degli invii offrono un falso senso di sicurezza: l'API ha accettato il messaggio, quindi la settimana sembra essere andata bene. Questa illusione rovina le settimane di fatturazione. Un report che calcola gli invii come un successo non concorderà con le ricevute DLR, con gli addebiti del portafoglio per il traffico multi-segmento o con gli audit dei webhook.

IOSOR applica una regola ferrea: le esportazioni dei report seguono le ricevute di consegna. Gli stati inviato, in coda e accettato per l'invio rimangono semplici tracce operative. Consegnato, fallito e sconosciuto sono le uniche colonne su cui i team finanziari e di prodotto devono confrontarsi.

L'invio è una traccia, non una metrica di chiusura

L'accettazione per l'invio dimostra soltanto che la piattaforma ha preso in carico il lavoro. Non prova che il destinatario abbia ricevuto l'SMS. Se il KPI principale del tuo pacchetto di report è rappresentato dagli invii, sovrastimerai il successo ogni volta che la quota di messaggi falliti o sconosciuti aumenta. Mantieni il dato di invio come colonna di capacità se utile, ma mai come sostituto della consegna effettiva.

Le colonne di esportazione seguono le ricevute

Lo schema di esportazione definisce esplicitamente gli stati delle ricevute. Il valore consegnato richiede un DLR formale. Il valore fallito richiede un segnale di errore definitivo. Lo stato sconosciuto rimane tale fino all'arrivo di una ricevuta e non deve mai essere trattato come una consegna implicita. Le settimane di fatturazione che nascondono lo stato sconosciuto all'interno dei successi generano le classiche controversie sulla quota non consegnata.

Riconciliare i webhook e il mastro con le stesse ricevute

La riconciliazione degli audit dei webhook con le esportazioni del mastro è il modo unico per dimostrare che il report corrisponde alla realtà. I log giornalieri dei webhook, gli stati DLR e le voci del mastro prepagato devono raccontare la stessa identica storia. Se i webhook mostrano un errore mentre il report indica un successo, il report è errato: correggi l'esportazione anziché rettificare il saldo del portafoglio.

Rifiutare le settimane di fatturazione basate sugli invii

Qualsiasi chiusura contabile che fatturi o celebri i risultati basandosi solo sui conteggi di invio deve essere bloccata. Riscrivi la struttura del report in modo che la finanza analizzi solo le quote di consegne effettive e di messaggi sconosciuti. Se il contratto con un partner parla ancora di 'invii API con successo', traduci quel concetto in note DLR, senza piegare le colonne delle metriche a terminologie errate.

Percorsi operativi correlati

• Settimana di fatturazione DLR: la quota sconosciuta non viene consegnata
• Riconciliazione dei log Webhook giornalieri con i saldi prepagati
• Settimana di fatturazione SMS: quando il calcolo dei segmenti e la bolletta n…

Inizia con IOSOR

Apri il pacchetto report di questa settimana nella console IOSOR e verifica che ogni KPI in evidenza usi ricevute DLR — delivered, failed e unknown — non submit né accept API. Se un grafico tratta ancora il submit come successo, rinominalo o toglilo prima della chiusura finance. Esporta una volta e condividi le stesse colonne di ricevuta tra prodotto e finance.

Sintesi IOSOR

I report chiudono sulle ricevute DLR: delivered, failed e unknown — non sui submit. Il submit è throughput, mai verità di consegna né argomento di fattura.

Fare: uno schema di export ancorato ai campi ricevuta. Non fare: il prodotto celebra gli accept mentre finance discute un failed DLR.