IOSOR Ghiduri
Undelivered vs rejected vs expired: dicționar de statusuri pentru produs și billing
Nu vă mai certați pe screenshot-uri: aliniați produsul, supportul și billingul prepaid pe undelivered, rejected și expired — plus acțiunile pe care fiecare status le permite cu adevărat.
Când livrabilitatea scade, produsul învinovățește pipe-ul, supportul lipește screenshot-uri, iar finance întreabă de ce s-a mișcat walletul prepaid. Mare parte din căldură este un eșec de vocabular. Undelivered, rejected și expired nu sunt sinonime — a le baga într-un singur găleată „failed” inventează retry-uri greșite, refund-uri greșite și severitate de incident greșită.
IOSOR vrea ca echipele B2B să opereze messaging ca white-label prepaid: finanțați o dată, citiți evenimente de status durabile, păstrați limbaj de eroare brand-safe. Acest dicționar este contractul operațional dintre UX de produs, ops și ledger.
De ce cuvintele de status cauzează mai multe incidente decât outages
| Clasă | Exemple | Produsul ar trebui…
Dicționarul de statusuri: definiții pe care produsul și billingul le pot împărtăși
Undelivered înseamnă de obicei că jobul a intrat pe calea messaging live, dar un semnal downstream spune că handsetul nu a primit succes. Drivere tipice: handset oprit, inbox plin, congestie temporară pe coridor, abonat inaccesibil.
Acțiuni licențiate:
Undelivered vs rejected: clase de eșec diferite, fix-uri diferite
Rejected este eșec de politică sau admitere: filtru de conținut, identitate expeditor, poartă de compliance, destinație malformed, fonduri insuficiente, sau catalog-not-live pentru acea capability. Jobul nu a câștigat niciodată o șansă corectă de livrare pe handset.
Acțiuni licențiate:
Expired: TTL, cozi și ferestre de timing OTP
Expired înseamnă că fereastra de validitate s-a închis înainte de succesul terminal. Comun în OTP (TTL), joburi în coadă past SLA, sau ferestre de validitate de rețea. Produsul trebuie să separe user expired (utilizator blocat) de network expired (pipe-ul nu a livrat la timp).
Acțiuni licențiate:
Implicații billing: ce se debitează, creditează sau contestă
| Status | Postură copy UX | Postură prepaid tipică | Următorul pas ops |
|---|---|---|---|
| Undelivered | Transient / incertitudine handset | Urmați politica publicată d |
Începeți cu IOSOR
Mapează-ți apelurile inverse de stare în consola IOSOR, astfel încât integrarea ta de facturare să separe clar respingerile timpurii de evenimentele nelivrate din aval și expirările din coadă. Auditează-ți webhookurile active pentru a te asigura că codurile de stare DLR terminale transmit clase de eroare explicite către registrul tău intern, în loc de o stare de eșec generică.
- Detectarea degradării livrării OTP înainte ca ratele de conversie să scadă
- cauza de bază a latenței SMS
- Când dispozitivul impune UCS-2, factura trebuie să reflecte adevărul
Rezumat IOSOR
Acest ghid a demonstrat că ambiguitatea stărilor este o problemă de design de produs și contabilitate, mai degrabă decât o simplă eroare de rețea. Distincția între respingerile operatorului, stările nelivrate din aval și expirările TTL clarifică responsabilitatea financiară și împiedică echipele de suport să vâneze erori fantomă în codul aplicației.
A fost util acest ghid?
Ghiduri conexe
- Compararea metricilor de livrare între rutele cu cod scurt și numere gratuite
Analizați metricile de livrare SMS între codurile scurte și numerele gratuite pentru clienții CPaaS white-label, detaliind filtrarea și urmărirea DLR.
- Stabilirea metricilor de bază pentru livrabilitate în timpul pilotării noilor rute
Rulați suite riguroase de testare, analizați performanța operatorilor și stabiliți metrici de bază înainte de a scala traficul white-label.
- Auditarea ratelor de livrare și curățarea cozilor după întreținerea rețelei
Ghid tehnic pas cu pas pentru administratorii de platformă în vederea verificării stării rutelor și golirii în siguranță a cozilor DLR întârziate după fereastra de întreținere.