IOSOR

IOSOR Guide

SMS quando cala la deliverability: leggere gli stati e agire senza panico

Playbook B2B per OTP e alert quando scende delivered: classificare stati, isolare corridoi, proteggere il wallet prepaid e correggere la causa prima della tempesta di retry.

Un crollo improvviso di SMS consegnati sembra un’interruzione. Per team B2B prepaid di solito è un mix di lettura stati, stress di corridoio, igiene liste e gate di compliance — non un motivo per martellare il reinvio. Questo playbook tiene prodotto, ops e finance in una sequenza calma.

IOSOR impacchetta la messaging white-label prepaid: ricarichi il wallet, usi capacità live e leggi gli esiti nel tuo account e nei callback — senza vivere nel portale di terze parti di un altro brand.

Cosa significano davvero gli stati

Stato Significato Errore in modalità panico
Accepted / queued La piattaforma ha preso il job Incolpare il percorso troppo presto
Sent / submitted Consegnato al path live Trattare “inviato” come prova sul handset
Delivered Segnale di successo terminale Ignorare i picchi di latenza
Failed Fallimento terminale con causa usabile Retry infiniti sulla stessa causa

Chiedete webhook o eventi interrogabili verificabili. Gli screenshot non sono un modello operativo alle 02:00.

Agire senza panico — playbook ordinato

  1. Congelare retry fuori controllo — tetto ai retry di sistema; separare il resend utente dai loop automatici.
  2. Affettare per corridoio — paese / classe di route / tipo mittente. La media globale nasconde la slice rotta.
  3. Separare UX dal pipe — template cattivi o TTL OTP scaduto sembrano “deliverability” nel supporto.
  4. Verificare l’onestà del catalogo — un mercato ancora in setup non è promessa live di delivered.
  5. Proteggere il wallet prepaid — destinazioni morte e tempeste di retry bruciano saldo prima della root cause.
  6. Escalation con evidenza — ID di correlazione, finestre temporali, codici di fail brand-safe e usabili.

Vicino a 1.000 USD+ di usage mensile piattaforma, i trend di stato diventano evidenza commerciale per rivedere tariffe e path; i pilot possono partire più piccoli.

Checklist acquirente

  1. Linguaggio chiaro delivered vs sent vs failed in prodotto ed eventi.
  2. Webhook inbound firmati o autenticati con guida all’idempotenza.
  3. Correlazione invio → stato → riga di ledger.
  4. Policy di retry e resend comprese da prodotto e finance.
  5. Nessun abbonamento obbligatorio alla piattaforma solo per tenere vivo l’account.
  6. Errori client usabili — senza dump di testo di brand altrui.

Bandiere rosse

  • Esiste solo “inviato”; nessuna distinzione delivered
  • Callback “più tardi”
  • Tempeste di retry senza visibilità wallet
  • Corridoi mock presentati come prova di produzione
  • Ops che spinge il team in un portale di terze parti a ogni incidente

Valutazione di una settimana

Scegliete due corridoi, finanziate un piccolo buffer prepaid, definite il dizionario stati con owner, fate traffico intenzionale e registrate un drill incidente end-to-end. Ampliate il volume solo quando prodotto e finance condividono gli stessi numeri.

Inizia con IOSOR

Apri la console IOSOR e inserisci immediatamente un blocco temporaneo sulle code di invio automatico per le rotte in errore, così da evitare tempeste di messaggi. Verifica gli endpoint dei webhook DLR per confermare che gli stati finali come Consegnato siano distinti correttamente dagli eventi intermedi di Invio.

Sintesi IOSOR

Un calo improvviso nella consegna degli SMS richiede un triage sistematico degli stati anziché cicli di invio guidati dal panico. Considerare l'invio come prova di arrivo sul dispositivo nasconde i blocchi a valle degli operatori e brucia budget senza recapitare i messaggi agli utenti finali.

Questa guida ti è stata utile?

Guide correlate