IOSOR Guides
Undelivered vs rejected vs expired : dictionnaire de statuts pour produit et billing
Arrêtez de vous battre avec des captures : alignez produit, support et billing prépayé sur undelivered, rejected et expired — et sur les actions que chaque statut autorise vraiment.
Quand la délivrabilité chute, le produit accuse le pipe, le support colle des captures, et la finance demande pourquoi le portefeuille prépayé a bougé. Une grande partie de la chaleur est un échec de vocabulaire. Undelivered, rejected et expired ne sont pas des synonymes — les traiter comme un seul seau « failed » invente de mauvais retries, de mauvais remboursements et une mauvaise sévérité d’incident.
IOSOR veut que les équipes B2B opèrent le messaging en white-label prépayé : financer une fois, lire des événements de statut durables, et garder un langage d’erreur brand-safe. Ce dictionnaire est le contrat opérationnel entre UX produit, ops et ledger.
Pourquoi les mots de statut causent plus d’incidents que les outages
| Classe | Exemples | Le produit doit…
Le dictionnaire de statuts : définitions que produit et billing peuvent partager
Undelivered signifie en général que le job a entré le path messaging live, mais un signal downstream dit que le handset n’a pas obtenu de succès. Drivers typiques : handset éteint, boîte pleine, congestion temporaire du corridor, abonné injoignable.
Actions licenciées :
Undelivered vs rejected : classes d’échec différentes, fixes différents
Rejected est un échec de politique ou d’admission : filtre contenu, identité d’expéditeur, porte de conformité, destination malformée, fonds insuffisants, ou catalogue-not-live pour cette capacité. Le job n’a jamais mérité une chance équitable de livraison handset.
Actions licenciées :
Expired : TTL, files et fenêtres de timing OTP
Expired signifie que la fenêtre de validité s’est fermée avant un succès terminal. Fréquent en OTP (TTL), jobs en file past SLA, ou fenêtres de validité réseau. Le produit doit séparer user expired (utilisateur bloqué) de network expired (le pipe n’a pas livré à temps).
Actions licenciées :
Implications billing : ce qui est débité, crédité ou contesté
| Statut | Posture copy UX | Posture prépayée typique | Prochaine étape ops |
|---|
Commencez avec IOSOR
Mappez vos rappels de statut dans la console IOSOR afin que votre intégration de facturation sépare clairement les rejets anticipés des événements non livrés en aval et des expirations de file d'attente. Auditez vos webhooks actifs pour garantir que les codes de statut DLR terminaux transmettent des classes d'erreur explicites à votre grand livre interne au lieu d'un état d'échec générique.
- Détecter la dégradation de la livraison des OTP avant la chute des conversions
- cause racine de la latence SMS
- Lorsque le mobile impose le UCS-2, la facture doit refléter la réalité
À retenir — IOSOR
Ce guide a démontré que l'ambiguïté des statuts relève de la conception de produits et de la comptabilité plutôt que d'une simple panne réseau. Distinguer les rejets d'opérateur, les états non livrés en aval et les expirations de durée de vie clarifie la responsabilité financière et évite aux équipes de support de traquer des bugs fantômes dans le code applicatif.
Ce guide vous a-t-il aidé ?
Guides associés
- Comparaison des métriques de délivrabilité entre numéros courts et numéros gratuits
Analysez les comportements des filtres d'opérateurs, les métriques DLR et les profils de débit pour les numéros courts et gratuits sur votre console CPaaS en marque blanche.
- Établissement des métriques de délivrabilité de base lors des pilotes de nouvelles routes
Exécutez des séries de tests de livraison rigoureuses, analysez les performances des opérateurs et établissez des métriques de messagerie de base avant de faire passer à l'échelle votre trafic en marque blanche sur de nouvelles routes.
- Audit des taux de livraison et nettoyage des files après maintenance
Guide technique étape par étape pour les gestionnaires de plateformes afin de vérifier l'état des routes et purger les files DLR en toute sécurité.