IOSOR

IOSOR Guide

Inviato non è inbox: filtri contenuto SMS, reputazione e perché i retry peggiorano

Come i team B2B trattano sent/submitted come passaggio, non come inbox — filtri contenuto, reputazione mittente, evidenza per corridoio e perché lo stesso testo brucia il prepagato.

«Sent» e «submitted» sono stati di passaggio. La piattaforma ha preso il lavoro e lo ha passato a un corridoio live — non prova che un umano abbia visto l’SMS. OTP e alert falliscono in silenzio quando product prende un invio verde come prova di inbox mentre il handset resta dietro un filtro contenuto o una reputazione ferita.

IOSOR opera messaging prepagato white-label: stati, DLR e righe wallet vivono nel tuo account. Vicino a USD 1,000+ di uso mensile, hit di filtro, p95 corridoio e addebiti retry diventano materia di revisione commerciale. Prima evidenza, poi scala.

Inviato e submitted non sono inbox

Stato Cosa prova Cosa non prova
Accepted / queued La piattaforma ha preso il job Consegna o inbox
Sent / submitted Passato alla rotta live Handset, inbox o conversione
Delivered DLR positivo / successo terminale Che l’utente ha letto in tempo
Failed / filtered Blocco terminale o di policy Che un retry sistema

Filtri contenuto e reputazione mittente

I filtri guardano testo, identità mittente, storia del corridoio e densità reclami — non la tua intenzione. Frasi phishing, shortener, picchi di volume e template OTP scivolati nel marketing alzano lo stesso muro. La reputazione ha forma di corridoio. Tieni i template transazionali corti. Separa la classe marketing da OTP. Se il catalogo è ancora in setup, un invio di lab non è reputazione di produzione.

Filtri a forma di corridoio, non medie mondiali

Un tasso mondiale «inviato» nasconde un mercato filtrato. Taglia per classe destinazione, tipo mittente e famiglia template. Settimanale: top corridoi per filtro/fallimento, tempo submitted → delivered vs SLA di conversione, quota ancora non terminale dopo SLA, etichetta catalogo vs invio reale. Product deve sapere del corridoio filtrato prima che gli utenti inventino workaround.

Non ritentare lo stesso filtro

Reinviare lo stesso testo nello stesso filtro brucia il prepagato e addestra il filtro a vederti come una tempesta. Metti un cap ai retry automatici. Cambia la causa — template, classe mittente, igiene lista — prima del secondo tentativo. Il reinvio utente non è un retry di sistema. Destinazioni morte e loop di filtro sembrano «crescita» sul wallet finché finance chiede perché delivered non si è mosso.

Segnali di allarme

  • Solo «inviato»; nessuna distinzione delivered/filtered
  • Stesso testo ritentato sullo stesso codice
  • Medie globali che nascondono un corridoio filtrato
  • Catalogo live senza owner del filtro
  • Errori che riversano brand esterni
  • Corridoi mock come prova di inbox
  • Finzione di scorta mittenti da sostituire di notte

Inizia con IOSOR

Apri la console di IOSOR e analizza i flussi di payload dei webhook DLR per separare gli stati inviati dalle conferme di consegna finali. Blocca immediatamente qualsiasi criterio di invio automatico che ripeta lo stesso testo su errori temporanei o filtrati dai gestori.

Sintesi IOSOR

Uno stato DLR inviato o inoltrato dimostra solamente che il messaggio ha lasciato la piattaforma, non che sia effettivamente arrivato sul dispositivo o nella casella del destinatario. I filtri di contenuto agiscono in modo silenzioso analizzando scorciatoie di link, variazioni dei modelli e aumenti improvvisi di traffico rispetto allo storico della reputazione locale.

Questa guida ti è stata utile?

Guide correlate