短信可达性下降时：读懂状态并冷静处置

短信送達率突然下滑常被誤判為系統宕機，但對預付費 B2B 團隊而言，這通常是狀態解讀、特定走廊壓力、名單衛生或合規門檻的綜合反饋，絕非狂點重發 OTP SMS 的理由。本手冊旨在引導產品、運營與財務團隊通過 DLR 與 webhook 數據冷靜排查，避免在 10DLC 或國際線路中盲目消耗 USD 餘額。IOSOR 採用白標 prepaid 模式，讓您直接在賬戶 ledger 中掌控實時能力，無需跳轉第三方門戶即可完成 JIT 決策與故障修復。

状态究竟表示什么

必须能核验 webhook 或可轮询事件。凌晨两点的截图不是运营模型。

不恐慌——按序处置

1. 冻结失控重试 — 限制系统重试；区分用户重发与自动循环。在 IOSOR 控制台，可临时挂起自动重试队列，防止消息风暴。需配置硬性上限，避免无休止的循环。
2. 按走廊切片 — 国家 / 路由类别 / 发件类型。全球平均值会藏住坏切片。在 IOSOR 控制台，可按国家通道和发送方类型对交付指标进行切片，隔离根本原因。
3. 区分体验与通道 — 差模板或过期 OTP TTL 在工单里会伪装成「可达性问题」。检查 OTP 的 TTL 设置，确保其在用户接收前有效。
4. 核对目录诚实 — 仍在配置中的市场，不能当作 live 送达承诺。确保所有发送目标市场均已完成合规检查和配置。
5. 守护预付费钱包 — 死号与重试风暴会在根因命名前烧掉余额。监控预付费钱包余额，防止因意外重试导致透支。
6. 带着证据升级 — 关联 ID、时间窗、品牌安全且可用的失败码。确保 DLR 回调包含所有必要信息，如关联 ID、时间戳和具体的失败原因码。

接近每月 1,000 美元平台用量时，状态趋势成为费率与路径复盘的商业证据；试点可更小起步。把状态字典写进事故演练：产品、运营与财务用同一套定义，避免三套「成功」并存，钱包与客服指标也会更早对齐。周复盘只看走廊切片，不看全球平均数；能点名失败原因与负责人，比再加一轮盲目重试更值钱。

采购检查清单

1. 产品内与事件中区分 delivered / sent / failed。IOSOR 的 DLR 回调应明确区分这些终态与中间状态。
2. 入站 webhook 签名或鉴权，并有幂等指引。确保 webhook 请求的安全性与可靠性，防止数据篡改或重复处理。
3. 从发送请求 → 状态 → 账本行的关联。IOSOR 提供完整的追踪链，从发送请求到最终账单明细。
4. 产品与财务都能理解的重试与重发策略。清晰定义自动重试的次数、间隔以及用户触发重发的机制。
5. 无仅为账号存活而设的强制平台订阅。IOSOR 的预付费模式按量计费，无强制订阅。
6. 客户端错误可读可用——不倾倒外部品牌原文。IOSOR 提供清晰的错误码和解释，便于快速排查。

危险信号

• 只有「已发送」，没有 delivered 区分。IOSOR 明确区分 Sent 和 Delivered 状态。
• 回调「以后再说」。IOSOR 的 webhook 机制确保实时通知。
• 重试风暴却看不见钱包。IOSOR 的预付费钱包余额直观可见，并与重试行为关联。
• 把模拟走廊当生产证明。IOSOR 强调真实流量下的数据分析。
• 每次事故都强迫团队进入第三方门户。IOSOR 提供一体化控制台。

一周评估

选两条走廊，准备小额预付费缓冲，与负责人定义状态词典，跑可控流量，并完成一次端到端事故演练。只有产品和财务看同一组数字后再放量。演练记录应能回答：哪条走廊、哪个状态、谁负责、钱包多烧了多少。

从 IOSOR 开始

請立即登入 IOSOR 控制台，針對異常路由下達暫停指令，將自動重試佇列凍結以避免引發二次簡訊風暴。同時請檢查系統的 DLR webhook 設定，確保接收端能精確辨識終態（如 Delivered）與中間狀態（如 Sent）的差異，切勿將未完成的事件誤判為成功投遞。隨後請依據特定國家代碼與發送者類型，匯出 UTC 時間軸的發送日誌進行交叉比對，全面排查可能導致到達率下降的節點。

• 安全重試失敗的短信營銷項，避免重複投遞
• 短信流量審查：當預預付費試點不再夠用時
• 10DLC 營銷活動激活：上線前嚴禁生產級 A2P 流量

相關: 10DLC 营销活动激活：上线前严禁生产级 A2P 流量 · 安全重试失败的短信营销项，避免重复投递 · 短信流量审查：当预付费试点不再够用时

IOSOR 要点

面對簡訊可達性驟降，最忌諱未經排查就開啟無上限的系統自動重試，這不僅會快速耗盡 USD 餘額，還可能引發電信商的二次封鎖。在 IOSOR 分析架構下，「系統已提交」絕不等同於「用戶已收到」，維運人員應冷靜檢視 DLR 回傳數據。請立即前往控制台匯出 UTC 時間戳記的完整日誌，並依據特定 corridor、route class 與發送者類型進行維度拆解，迅速定位是特定網關中斷還是路由品質惡化。若確認某條路徑觸發高失敗率，應即刻執行 JIT 熔斷機制並標記 Needs_swap，將流量安全切換至備用通道，同時透過 webhook 實時追蹤狀態變化。對於頻繁失敗的 OTP 業務，請務必參閱 /learn/sms-status-codes 釐清底層拒絕原因，並對照 /learn/global-compliance-guide 檢視簡訊內文是否因敏感字眼遭當地業者過濾。唯有透過精準的日誌交叉比對與路由調控，才能在不浪費成本的前提下恢復高可達性。