IOSOR

IOSOR 知识库

未送达 vs 拒收 vs 过期：产品与计费共用的状态词典

别再为截图争吵：让产品、支持与预付费计费对齐 undelivered、rejected、expired——以及每个状态真正允许的动作。

投递率下滑时，产品怪管道，支持贴截图，财务问预付费钱包为何变动。多半是词汇失败。Undelivered、rejected 与 expired 不是同义词；打成一个「失败」桶会发明错误重试、错误退款与错误事件严重级别。

IOSOR 希望 B2B 团队把消息当作白标预付费运营：一次充值、读取持久状态事件、保持品牌安全的错误文案。本词典是产品 UX、运维与账本之间的操作契约。

为什么状态用词比宕机制造更多事故

类别 示例 产品应…
Intermediate queued, submitted, sent 显示进度；勿庆祝已到手持机
Terminal success delivered 解锁下一步 UX；停止自动重发
Terminal fail undelivered, rejected, expired（若定义为终态） 选择许可动作；永不无限重试

若 UI 把一切压成红叉，凌晨两点无人能正确行动。

状态词典：产品与计费可共识的定义

Undelivered 通常表示任务已进入实时消息路径，但下游信号称手持机未获成功结果。常见驱动：手机关机、收件箱满、走廊短暂拥塞、订户不可达。

许可动作：

  1. 仅在策略与走廊证据支持时做有界自动重试
  2. 对用户显示「稍后再试」，勿暗示欺诈
  3. 按已公布借记/退款规则处理钱包——勿在闲聊线程里发明静默退款

勿把每次 undelivered 当成「平台宕机」。先按走廊切片，再决定是否全域告警。

Undelivered vs rejected：不同失败类，不同修复

Rejected 是策略或准入失败：内容过滤、发件身份、合规门、畸形目的地、余额不足，或该能力目录未 live。任务从未获得公平的手持机投递机会。

许可动作：

  • 修好门（模板、注册、余额、目录诚实）
  • 向运营展示可用、品牌安全的原因码
  • 永不对相同载荷重试指望换个宇宙

Rejected 风暴首先是合规与目录问题——不是「加吞吐」问题。

Expired：TTL、队列与 OTP 时间窗

Expired 表示在终端成功之前有效期窗口已关闭。常见于 OTP（TTL）、超过 SLA 的排队任务，或运营商有效期。产品须区分 user expired（用户停滞）与 network expired（管道未及时送达）。

许可动作：

  • 提供带冷却的可控重发
  • 在 Verify 流程中作废先前验证码
  • 新尝试再次借记时清晰归因花费

无冷却自动重发的过期 OTP 是欺诈与花费放大器。

状态 UX 文案姿态 典型预付费姿态 运维下一步
Undelivered 短暂 / 手持机不确定 遵循已公布借记/退款策略 走廊切片 + 证据包
Rejected 可行动的门失败 通常无成功投递尝试 修门；停止相同重试
Expired 时间窗关闭 按策略为已消耗尝试借记 重发冷却；新关联 ID

接近每月 USD 1,000+ 平台用量时，状态语言错配会变成商业纠纷——不是支持趣闻。试点仍可先在两条走廊验证词典。

  1. 产品、支持与财务共享的书面词典
  2. 带持久 ID 的 Webhook 或可轮询事件
  3. 保持白标安全的可区分原因码
  4. 与每个终态失败类配对的重试/重发策略
  5. 财务可按状态结果对账的钱包导出
  6. 目录诚实，使「rejected: not live」可以说出口

危险信号

  • 只有「failed」一种状态
  • 截图是唯一状态系统
  • 对 rejected 自动重试风暴
  • 钱包变动无状态轨迹
  • 面向客户的失败原因出现外来品牌文案

从 IOSOR 开始

在控制台中映射状态回调，让计费集成能够清晰地将早期拒收与后续未送达事件及队列过期区分开来。审查您启用的网络钩子，确保终端投递报告状态码向内部账本传递明确的错误类别，而非通用的失败状态。随后，调整发送网关参数，在遇到硬拒收时立即抑制重试，同时针对一次性密码短信优化生存时间限制。

IOSOR 要点

本指南表明，状态模糊本质上是一个产品设计与会计问题，而非单纯的网络故障。明确区分运营商拒收、后续未送达状态以及生存时间过期，能够厘清财务责任，并防止支持团队在应用代码中排查虚假错误。

请将下游投递报告网络钩子状态直接镜像到计费账本中，以确保账单核对的透明度。切勿将所有投递失败合并为简单的二元已发送或失败状态，这会掩盖消息究竟是因为格式错误、网络过滤还是时间窗口过期而失败。

这篇指南有帮助吗？

相关指南