IOSOR

IOSOR Guides

SMS quand la délivrabilité chute: lire les statuts et agir sans panique

Playbook B2B pour OTP et alertes quand le delivered baisse: classer les statuts, isoler les corridors, protéger le portefeuille prépayé et corriger la cause avant la tempête de retries.

Une chute brutale de SMS délivrés ressemble à une panne. Pour les équipes B2B prépayées, c’est souvent un mélange d’interprétation des statuts, de stress de corridor, d’hygiène de listes et de portes de conformité — pas une raison de marteler « renvoyer ». Ce playbook aligne produit, ops et finance sur une séquence calme.

IOSOR emballe la messagerie en white-label prépayé: alimentez le portefeuille, appelez les capacités live, lisez les résultats dans votre compte et vos callbacks — sans vivre dans le portail tiers d’une autre marque.

Ce que les statuts signifient vraiment

État Signification Erreur en mode panique
Accepted / queued La plateforme a pris le job Accuser la route trop tôt
Sent / submitted Remis au chemin live Traiter « envoyé » comme preuve handset
Delivered Signal de succès terminal Ignorer les pics de latence
Failed Échec terminal avec cause utilisable Retries infinis sur la même cause

Exigez des webhooks ou des événements interrogeables vérifiables. Les captures d’écran ne sont pas un modèle d’exploitation à 02 h 00.

Agir sans panique — playbook ordonné

  1. Geler les retries incontrôlés — plafonner les retries système; séparer le renvoi utilisateur des boucles auto.
  2. Découper par corridor — pays / classe de route / type d’émetteur. La moyenne mondiale cache la tranche cassée.
  3. Séparer UX et pipe — mauvais template ou TTL OTP expiré ressemblent à de la « délivrabilité » au support.
  4. Vérifier l’honnêteté du catalogue — un marché encore in setup n’est pas une promesse live de delivered.
  5. Protéger le portefeuille prépayé — destinations mortes et tempêtes de retries brûlent le solde avant la cause racine.
  6. Escalader avec preuves — IDs de corrélation, fenêtres temporelles, codes d’échec brand-safe et utilisables.

Vers 1 000 USD+ d’usage mensuel plateforme, les tendances de statut deviennent une preuve commerciale pour revoir tarifs et chemins; un pilote peut démarrer plus petit.

Checklist acheteur

  1. Langage clair delivered vs sent vs failed dans le produit et les événements.
  2. Webhooks entrants signés ou authentifiés avec guide d’idempotence.
  3. Corrélation envoi → statut → ligne de ledger.
  4. Politiques de retry et resend comprises par produit et finance.
  5. Pas d’abonnement plateforme obligatoire juste pour garder le compte vivant.
  6. Erreurs client utilisables — sans dump de texte de marques étrangères.

Signaux d’alerte

  • Seul « envoyé » existe; pas de distinction delivered
  • Callbacks « plus tard »
  • Tempêtes de retries sans visibilité portefeuille
  • Corridors mock présentés comme preuve de production
  • Ops qui pousse l’équipe vers un portail tiers à chaque incident

Évaluation d’une semaine

Choisissez deux corridors, financez un petit buffer prépayé, définissez le dictionnaire de statuts avec owners, lancez un trafic intentionnel et consignez un drill d’incident de bout en bout. Augmentez le volume seulement quand produit et finance partagent les mêmes chiffres.

Commencez avec IOSOR

Ouvrez la console IOSOR et suspendez immédiatement les files d attente de nouvelles tentatives automatiques pour les itinéraires en échec afin d éviter toute tempête de messages. Vérifiez vos points de terminaison webhook DLR pour confirmer que les états finaux comme 'Livré' sont correctement distingués des événements intermédiaires 'Envoyé'.

À retenir — IOSOR

Une chute soudaine de la délivrabilité des SMS exige un tri systématique des statuts plutôt que des boucles de relance dictées par la panique.

Ce guide vous a-t-il aidé ?

Guides associés