IOSOR ガイド
未達 vs 拒否 vs 期限切れ：プロダクトと請求のステータス辞書
スクリーンショット喧嘩をやめ、プロダクト・サポート・前払い請求を undelivered / rejected / expired と各ステータスが許可するアクションで揃える。
メッセージが届かない際、プロダクト側がエンジニアリングを疑い、財務担当が未達分の請求に困惑するのは、ステータスの定義が曖昧だからです。Undelivered、Rejected、Expired の違いを正しく区別せずに「失敗」として一括りに扱うと、不必要なリトライや過剰な返金対応を招き、コスト管理を困難にします。IOSOR はホワイトラベルの prepaid モデルにおいて、ダッシュボード、webhook、そして ledger 上で共通の語彙を使用することで、運用と請求の不一致を解消します。
なぜステータス語が障害より多くのインシデントを生むのか
| 区分 | 例 | プロダクトは… |
|---|---|---|
| Intermediate | queued, submitted, sent | 進捗表示；端末成功を祝わない |
| Terminal success | delivered | 次UXを解放；自動再送を止める |
| Terminal fail | undelivered, rejected, expired（終端定義なら） | 許可アクションを選ぶ；無限リトライ禁止 |
UI がすべてを赤い X に潰すと、02:00 に正しく動ける人はいなくなります。
ステータス辞書：プロダクトと請求が合意できる定義
Undelivered は通常、ジョブがライブ・メッセージング経路に入ったが、下流信号が端末成功を否定した状態です。典型要因：端末オフ、受信箱満杯、回廊の一時混雑、到達不能加入者。
許可アクション：
- ポリシーと回廊証拠が支える場合のみ有界自動リトライ
- 詐欺を示唆せず「後で再試行」をユーザー表示
- 公開済みのデビット／返金ルールに従うウォレット処理——チャットスレで無言返金を発明しない
毎回の undelivered を「プラットフォーム障害」と見なさない。世界をページする前に回廊でスライスする。
Undelivered vs rejected：別の失敗クラス、別の修正
Rejected はポリシーまたは入場失敗です。コンテンツフィルタ、送信者身元、コンプライアンスゲート、不正宛先、残高不足、当該能力の catalog-not-live。ジョブは端末到達の公平な機会を得ていません。
許可アクション：
- ゲートを直す（テンプレ、登録、残高、カタログ誠実）
- 運用者に使えるブランド安全な理由コードを出す
- 同じペイロードを別宇宙を期待してリトライしない
Rejected 嵐はまずコンプライアンスとカタログの問題——「スループット増」ではない。
Expired：TTL・キュー・OTPタイミング窓
Expired は端末成功前に有効期限ウィンドウが閉じた状態です。OTP（TTL）、SLA 超過のキュー、ネットワーク有効期限でよく見ます。プロダクトは user expired（ユーザー停滞）と network expired（パイプが間に合わなかった）を分離します。
許可アクション：
- クールダウン付きの制御された再送
- Verify フローで前コードを無効化
- 新試行が再デビットするとき支出を明確に帰属
クールダウン無しの自動再送付き期限切れ OTP は詐欺と支出の増幅器です。
| ステータス | UXコピー姿勢 | 典型前払い姿勢 | 運用の次手 |
|---|---|---|---|
| Undelivered | 一時的／端末不確実 | 公開デビット／返金ポリシーに従う | 回廊スライス＋証拠パック |
| Rejected | 実行可能なゲート失敗 | 通常は成功配信試行なし | ゲート修復；同一リトライ停止 |
| Expired | 時間窓クローズ | ポリシーに従い消費試行をデビット | 再送クールダウン；新相関ID |
月間 USD 1,000+ のプラットフォーム利用近辺では、ステータス言語の不一致は商業紛争になります——サポートの好奇心ではない。パイロットはまず二回廊で辞書を検証できます。
- プロダクト・サポート・財務が共有する文書化辞書
- 永続ID付き Webhook またはポーリング可能イベント
- ホワイトラベル安全な区別可能な理由コード
- 各終端失敗クラスに紐づくリトライ／再送ポリシー
- 財務がステータス結果と突合できるウォレット出力
- 「rejected: not live」を声に出せるカタログ誠実
危険信号
- 「failed」しかない
- スクリーンショットが唯一のステータス系統
- rejected への自動リトライ嵐
- ステータストレイルのないウォレット移動
- クライアント向け失敗理由に外来ブランド文
IOSORで始める
IOSOR コンソールでステータス コールバックをマッピングし、課金連携において早期の拒否と、下流での未達イベントやキューの有効期限切れを明確に分離できるようにします。アクティブな Webhook を監査し、ターミナル DLR のステータス コードが汎用的な失敗状態ではなく、明示的なエラー クラスを内部元帳へ渡すようにします。その上で、配信ゲートのパラメータを調整し、ハード拒否に対する再試行を即座に抑制すると同時に、ワンタイム パスワード メッセージの TTL 制限を最適化してください。
IOSORの要点
本ガイドでは、ステータスの曖昧さが単なるネットワーク障害ではなく、プロダクト デザインと経理の問題であることを示しました。キャリアによる拒否、下流での未達状態、および TTL の期限切れを区別することで、財務上の責任が明確になり、サポート チームがアプリケーション コード内の幽霊バグを追跡する手間がなくなります。
下流の DLR Webhook の状態を課金元帳に直接反映させ、透明性のある請求書照合を確保してください。すべての配信ドロップオフを、フォーマット、ネットワーク フィルタリング、または期限切れのいずれが原因でメッセージが失敗したかを曖昧にするバイナリの送信済み・失敗ステータスにまとめないでください。
このガイドは役に立ちましたか？
関連ガイド
- ショートコードとトフリーのルート間における到達性メトリクスの比較
ホワイトラベルCPaaSコンソールにおける、キャリアのフィルタリング動作、DLRメトリクス、およびショートコードやトフリー番号のスループットプロファイルを分析します。
- 新規ルートのパイロット時におけるベースライン到達性メトリクスの確立
厳格な配信テストスイートの実行、キャリアパフォーマンスの分析、およびホワイトレーベルのトラフィックを新ルートで本格展開する前のメッセージング基本指標の確立を行います。
- ネットワークメンテナンス後の配信率監査とキューのクリア手順
キャリアおよび通信網のメンテナンス後に、プラットフォーム管理者がルートの健全性を検証し、遅延したDLRキューを安全にフラッシュするためのステップバイステップのテクニカルプレイブック。