IOSOR

IOSOR Guides

Envoyé n’est pas la boîte : filtres de contenu SMS, réputation et retries qui empirent

Comment les équipes B2B traitent sent/submitted comme une passation, pas une boîte — filtres de contenu, réputation d’expéditeur, preuves par corridor, et pourquoi le même texte brûle le prépayé.

« Sent » et « submitted » sont des états de passation. La plateforme a pris le travail et l’a remis à un corridor live — ce n’est pas la preuve qu’un humain a vu le SMS. OTP et alertes échouent en silence quand le produit prend un envoi vert pour une preuve de boîte alors que le handset reste derrière un filtre de contenu ou une réputation blessée.

IOSOR exploite une messagerie prépayée white-label : statuts, DLR et lignes portefeuille vivent dans votre compte.

Envoyé et soumis ne sont pas la boîte

État Ce qu’il prouve Ce qu’il ne prouve pas
Accepted / queued La plateforme a pris le job Livraison ou boîte
Sent / submitted Remis à la route live Handset, boîte ou conversion
Delivered DLR positif / succès terminal Lecture à temps
Failed / filtered Blocage terminal ou politique Qu’un retry répare

Filtres de contenu et réputation d’expéditeur

Les filtres regardent le texte, l’identité d’expéditeur, l’historique du corridor et la densité de plaintes — pas votre intention. Formules phishing, raccourcisseurs, pics de volume et templates OTP glissés vers le marketing lèvent le même mur. La réputation a la forme d’un corridor. Gardez les templates transactionnels courts. Séparez la classe marketing de l’OTP.

Filtres en forme de corridor, pas de moyennes mondiales

Un taux mondial « envoyé » cache un marché filtré. Tranchez par classe de destination, type d’expéditeur et famille de template. Hebdo : top corridors filtre/échec, temps submitted → delivered vs SLA de conversion, part encore non terminale après SLA, libellé catalogue vs envoi réel. Le produit doit connaître le corridor filtré avant que les utilisateurs inventent des contournements.

Ne réessayez pas le même filtre

Renvoyer le même texte dans le même filtre brûle le prépayé et apprend au filtre que vous êtes une tempête. Plafonnez les retries automatiques. Changez la cause — template, classe d’expéditeur, hygiène de liste — avant la deuxième tentative. Le renvoi utilisateur n’est pas un retry système.

Signaux d’alerte

  • Seul « envoyé » existe ; pas de delivered/filtered
  • Même texte retried vers le même code
  • Moyennes globales qui cachent un corridor filtré
  • Catalogue live sans owner du filtre
  • Erreurs qui déversent des marques étrangères
  • Corridors mock présentés comme preuve de boîte
  • Fiction d’un stock d’expéditeurs à substituer la nuit

Commencez avec IOSOR

Ouvrez la console IOSOR et inspectez vos flux de charges utiles webhook DLR pour isoler les statuts soumis des confirmations de livraison finales. Mettez en place un gel d'exécution immédiat sur toute politique de nouvelle tentative automatisée qui réinjecte un contenu identique dans des codes d'erreur non définitifs ou filtrés par les opérateurs.

À retenir — IOSOR

Un statut DLR envoyé ou soumis prouve seulement que le message a quitté la plateforme, et non qu'il a atteint le combiné ou la boîte de réception du destinataire. Les filtres de contenu agissent discrètement au niveau des couloirs, en évaluant les raccourcisseurs de liens, la dérive des modèles et les hausses soudaines de volume par rapport à l'historique de réputation localisé.

Ce guide vous a-t-il aidé ?

Guides associés