Rapoartele trebuie să se potrivească cu DLR, nu cu numărul de trimiteri

Numărul de trimiteri oferă un confort fals: API-ul a acceptat mesajul, deci săptămâna a fost 'reușită'. Acest confort se destramă în săptămâna de facturare. Un raport care contorizează trimiterile drept succes va fi în contradicție cu confirmările DLR, debitările din portofel pentru traficul multi-segment și auditurile webhook.

IOSOR impune regula: exporturile de rapoarte urmează confirmările de livrare. Stările trimis, în coadă și acceptat pentru trimitere rămân repere operaționale. Livrat, eșuat și necunoscut sunt coloanele despre care discută departamentele financiar și de produs.

Trimis este un reper, nu o metrică de închidere

Acceptarea pentru trimitere dovedește doar că sistemul a preluat sarcina. Nu dovedește că telefonul destinatarului a primit SMS-ul. Dacă principalul KPI al pachetului dvs. de rapoarte este numărul de trimiteri, veți supraestima succesul de fiecare dată când ponderea mesajelor necunoscute sau eșuate crește. Păstrați starea trimis ca o coloană de capacitate dacă este utilă — niciodată ca un substitut pentru livrat.

Coloanele de export urmează confirmările

Schema de export denumește explicit stările confirmărilor. Starea livrat necesită un DLR. Starea eșuat necesită un semnal de eroare terminal. Starea necunoscut rămâne necunoscută până la sosirea unei confirmări — nu este o stare de livrat implicită. Săptămânile de facturare care ascund starea necunoscut în cadrul succesului creează disputa clasică privind cota nelivrată.

Reconciliați webhook-urile și registrul pe baza acelorași confirmări

Reconcilierea auditului webhook cu exportul registrului este modul prin care dovediți că raportul nu este o ficțiune. Jurnalele zilnice webhook, stările DLR și liniile din registrul preplătit trebuie să spună aceeași poveste. Dacă webhook-urile arată eșuat în timp ce raportul arată succes, raportul este greșit — corectați exportul, nu 'ajustați' soldul portofelului.

Refuzați săptămânile de facturare bazate pe trimiteri

Orice închidere care facturează sau sărbătorește doar pe baza numărului de trimiteri este blocată. Rescrieți pachetul astfel încât financiarul să pivoteze pe cota de livrate și necunoscute. Dacă un contract cu un partener menționează încă 'trimiteri API reușite', traduceți acel limbaj în note DLR — nu adaptați coloanele pentru a se potrivi cu o formulare incorectă.

Căi operaționale conexe

• Săptămâna facturării: cota necunoscută DLR nu este livrată
• Reconcilierea jurnalelor zilnice webhook cu soldurile preplătite
• Săptămâna facturării SMS: când matematica segmentelor și factura nu se potrivesc

Începeți cu IOSOR

Deschideți pachetul de rapoarte al săptămânii în consola IOSOR și confirmați că fiecare KPI din antet se bazează pe chitanțe DLR — delivered, failed și unknown — nu pe submit-uri sau accept-uri API. Dacă un grafic încă tratează submit-ul ca succes, redenumiți-l sau eliminați-l înainte de închiderea financiară. Exportați o dată și partajați aceleași coloane de chitanță între produs și finanțe.

Rezumat IOSOR

Rapoartele se închid pe chitanțe DLR: delivered, failed și unknown — nu pe submit-uri. Submit-ul e doar throughput, niciodată adevărul livrării sau argument de factură.

Faceți: o schemă de export ancorată pe câmpuri de chitanță. Nu: produsul sărbătorește accept-uri în timp ce finanțele se ceartă pe failed DLR.