IOSOR Wissen
Undelivered vs rejected vs expired: Statuswörterbuch für Produkt und Billing
Hört auf, um Screenshots zu streiten: richtet Produkt, Support und Prepaid-Billing auf undelivered, rejected und expired aus — und auf die Aktionen, die jeder Status wirklich zulässt.
Wenn die Zustellbarkeit sinkt, beschuldigt Produkt die Pipe, Support klebt Screenshots, und Finance fragt, warum die Prepaid-Wallet bewegt wurde. Viel Hitze ist ein Vokabular-Versagen. Undelivered, rejected und expired sind keine Synonyme — sie in einen „failed“-Eimer zu werfen erfindet falsche Retries, falsche Refunds und falsche Incident-Severity.
IOSOR will, dass B2B-Teams Messaging als White-Label-Prepaid betreiben: einmal fondsieren, dauerhafte Status-Events lesen, brand-sichere Fehlersprache halten. Dieses Wörterbuch ist der Operating Contract zwischen Produkt-UX, Ops und Ledger.
Warum Statusworte mehr Incidents verursachen als Outages
| Klasse | Beispiele | Produkt sollte… |
|---|---|---|
| Intermediate | queued, submitted, sent | Fortschritt zeigen; keinen Handset-Erfolg feiern |
| Terminal success | delivered | Nächstes UX freischalten; Auto-Resend stoppen |
| Terminal fail | undelivered, rejected, expired (wenn terminal) | Lizenzierte Aktion wählen; nie Endlos-Retry |
Das Statuswörterbuch: Definitionen, auf die Produkt und Billing sich einigen
Undelivered heißt meist: der Job ist in den Live-Messaging-Pfad eingetreten, aber ein Downstream-Signal sagt, das Handset hat keinen Erfolg erhalten. Typische Treiber: Handset aus, volles Inbox, temporäre Korridor-Congestion, unerreichbarer Subscriber.
Lizenzierte Aktionen:
Undelivered vs rejected: andere Failure-Klassen, andere Fixes
Rejected ist Policy- oder Admission-Fail: Content-Filter, Sender-Identität, Compliance-Gate, malformed Destination, unzureichende Funds, oder Catalog-not-live für diese Capability. Der Job hat nie eine faire Chance auf Handset-Delivery verdient.
Lizenzierte Aktionen:
Expired: TTL, Queues und OTP-Zeitfenster
Expired heißt: das Gültigkeitsfenster schloss vor einem terminalen Erfolg. Häufig bei OTP (TTL), Queued Jobs past SLA, oder Netz-Validity-Fenstern. Produkt muss user expired (User hängt) von network expired (Pipe lieferte nicht rechtzeitig) trennen.
Lizenzierte Aktionen:
Billing-Implikationen: was belastet, gutgeschrieben oder bestritten wird
| Status | UX-Copy-Haltung | Typische Prepaid-Haltung | Ops nächster Schritt |
|---|---|---|---|
| Undelivered | Transient / Handset-Unsicherheit | Veröffentlichten Debit-/Refund-Policy folgen | Korridor-Slice + Evidence-Pack |
| Reject |
Starten Sie mit IOSOR
Ordnen Sie Ihre Statusrückmeldungen in der IOSOR Konsole so zu, dass Ihre Abrechnungsintegration frühe Ablehnungen klar von nachgelagerten, nicht zugestellten Ereignissen und Warteschlangenabläufen trennt. Überprüfen Sie Ihre aktiven Webhooks, um sicherzustellen, dass finale DLR Statuscodes explizite Fehlerklassen an Ihr internes Hauptbuch übergeben, statt eines pauschalen Fehlerstatus.
- Erkennung von OTP-Zustellungsverschlechterungen vor sinkenden Konversionsraten
- Ursache der SMS-Latenz
- Wenn das Endgerät UCS-2 erzwingt, muss die Abrechnung der Wahrheit entsprechen
IOSOR Fazit
Dieser Leitfaden hat gezeigt, dass Statusunklarheiten eher ein Produktgestaltungs und Buchhaltungsproblem als ein einfacher Netzwerkfehler sind. Die Unterscheidung zwischen Netzbetreiberablehnungen, nachgelagerten Zustellungsfehlern und dem Ablauf der Lebensdauer sorgt für finanzielle Nachvollziehbarkeit und hindert Supportteams daran, nach Phantomfehlern im Anwendungscode zu suchen.
War dieser Leitfaden hilfreich?
Verwandte Leitfäden
- Vergleich der Zustellbarkeitsmetriken über Short-Code- und Toll-Free-Routen
Analysieren Sie Carrier-Filterverhalten, DLR-Metriken und Durchsatzprofile für Short Codes und gebührenfreie Rufnummern auf Ihrer White-Label-CPaaS-Konsole.
- Ermittlung von Basis-Zustellbarkeitsmetriken bei neuen Routen-Piloten
Führen Sie stringente Testsuiten aus, analysieren Sie die Netzbetreiberleistung und etablieren Sie grundlegende Nachrichtenmetriken vor der Skalierung Ihres White-Label-Traffics auf neuen Routen.
- Überprüfung von Zustellraten und Bereinigung von Warteschlangen nach Netzwerkwartung
Schritt-für-Schritt-Technischer Leitfaden für Plattformmanager zur Überprüfung der Routengesundheit und sicheren Bereinigung verzögerter DLR-Warteschlangen nach Telekommunikations-Wartungsfenstern.