IOSOR

IOSOR Znalosti

Undelivered vs rejected vs expired: slovník stavů pro produkt a billing

Přestaňte se hádat o screenshoty: sladťe produkt, support a prepaid billing na undelivered, rejected a expired — plus akce, které každý stav skutečně dovoluje.

Když klesá doručitelnost, produkt viní pipe, support lepí screenshoty a finance ptá, proč se pohnula prepaid peněženka. Většina vedra je selhání slovníku. Undelivered, rejected a expired nejsou synonyma — naházet je do jednoho kbelíku „failed“ vymýšlí špatné retry, špatné refundy a špatnou severity incidentu.

IOSOR chce, aby B2B týmy provozovaly messaging jako white-label prepaid: dobijte jednou, čtěte trvalé status eventy, držte brand-safe chybový jazyk. Tento slovník je provozní smlouva mezi UX produktu, ops a ledgerem.

Proč statusová slova způsobují více incidentů než výpadky

Třída Příklady Produkt by měl…
Intermediate queued, submitted, sent Ukázat progress; neslavit úspěch na handsetu
Terminal success delivered Odemknout další UX; zastavit auto-resend
Terminal fail undelivered, rejected, expired (pokud terminal) Zvolit licencovanou akci; nikdy nekonečný retry

Slovník statusů: definice, na kterých se produkt a billing shodnou

Undelivered obvykle znamená, že job vstoupil do live messaging cesty, ale downstream signál říká, že handset nedostal úspěch. Typické drivry: handset vypnutý, plná schránka, dočasná congestace koridoru, nedosažitelný participant.

Licencované akce:

Undelivered vs rejected: různé třídy selhání, různé opravy

Rejected je selhání politiky nebo přijetí: filtr obsahu, identita odesílatele, compliance gate, malformed destination, nedostatečné prostředky, nebo catalog-not-live pro danou capability. Job nikdy nezískal férovou šanci na doručení na handset.

Licencované akce:

Expired: TTL, fronty a časová okna OTP

Expired znamená, že okno platnosti se zavřelo před terminálním úspěchem. Běžné u OTP (TTL), frontových jobů past SLA, nebo síťových oken platnosti. Produkt musí oddělit user expired (uživatel uvízl) od network expired (pipe nedoručila včas).

Dopady billingu: co se účtuje, připisuje nebo sporní

Stav Postoj UX copy Typický prepaid postoj Ops další krok
Undelivered Transient / nejistota handsetu Dle publikované debit/refund politiky Slice koridoru + balíček evidence
Rejected Actionable fail brány Obvykle žádný úspěšný delivery pokus Opravit bránu; stop identických retry
Expired Časové okno zavřeno Debit

Začněte s IOSOR

Mapujte své stavové zpětné volání v konzoli IOSOR tak, aby vaše fakturační integrace čistě oddělila včasná odmítnutí od následně nedoručených událostí a vypršení platnosti fronty. Zkontrolujte své aktivní webhooky, abyste zajistili, že koncové stavové kódy DLR předávají do vašeho interního účetnictví explicitní chybové třídy namísto obecného chybového stavu.

Shrnutí IOSOR

Tento průvodce ukázal, že nejednoznačnost stavů je spíše problémem produktového designu a účetnictví než prostým výpadkem sítě. Rozlišování mezi odmítnutím operátorem, stavy nedoručení a vypršením TTL objasňuje finanční odpovědnost a brání týmům podpory v hledání neexistujících chyb v kódu aplikace.

Byl tento průvodce užitečný?

Související průvodci