發送前查號：減少無效簡訊與預付費浪費

每則未送達的 OTP 都在消耗預算、客服時間與信任。發送前查號（line intelligence）幫助嚴謹的預付費團隊決定：發簡訊、走語音備援，還是給使用者更溫和的體驗路徑。

IOSOR 把查號與訊息放在同一套白標預付費模型裡：先充值錢包，再呼叫已上線能力；錯誤訊息對產品可讀，團隊不必進入其他品牌的維運後台。

查號能做什麼（不能做什麼）

查號提升的是命中機率與支出誠實度。送達仍依賴狀態、回呼與合規。

採購檢查清單

1. 清晰的回應欄位，可對應到產品規則，而不是不透明的整包資料。
2. 預付費扣款可見 — 財務把查號視為一等支出。
3. 延遲適合註冊路徑（或活動側非同步清洗）。
4. 失敗策略：風險場景 fail closed，體驗側 fail soft。
5. 無強制平台訂閱，僅為帳號存活而收費。

接近每月 1,000 美元平台用量時，把查號與簡訊指標一併做費率與支援複盤；試點可以更小起步。

把判定寫成可匯出三欄：時間戳、狀態碼、關聯 ID。值班與財務讀同一匯出。

查號在漏斗中的位置

1. 在合規同意下採集識別碼。
2. 當風險或目的地組合需要時執行查號。
3. 按自有規則選擇通道（簡訊 / 語音 / 其他）。
4. 僅在已開通走廊發送，並記錄關聯 ID。
5. 對比送達與失敗 — 先改名單衛生，而不是一味加重試。

值班交接時把判定標準寫進同一份說明：誰看 DLR、誰對帳、誰能暫停路由。峰值前按清單複核。

對帳或匯出必須帶同一 intent 或 session 鍵，方便財務回放。

上線前先跑窄走廊冒煙，確認閘門與回退觸發後再放寬目的地。

停發線與 hold 狀態要能在同一匯出裡看見，避免口頭交接。

值班交接時把判定標準寫進同一份說明：誰看 DLR、誰對帳、誰能暫停路由。峰值前按清單複核。

對帳或匯出必須帶同一 intent 或 session 鍵，方便財務回放。

上線前先跑窄走廊冒煙，確認閘門與回退觸發後再放寬目的地。

停發線與 hold 狀態要能在同一匯出裡看見，避免口頭交接。

值班交接時把判定標準寫進同一份說明：誰看 DLR、誰對帳、誰能暫停路由。峰值前按清單複核。

危險訊號

• 把查號吹成「100% 送達」
• 錢包中沒有查號扣費明細
• 錯誤原文洩漏上游品牌文案
• 目錄標為 live，實際仍在設定中
• 用查號結果取代同意與內容合規審查

把查號當成路由與支出誠實的工具，而不是行銷許可證，才能守住品牌與餘額。試點時同時記錄過濾比例與延遲——財務需要這兩類數字，才相信查號值得付費。

一週評估

選一條 OTP 走廊，準備小額預付費緩衝，對比開啟與關閉發送前檢查的結果；記錄延時、過濾比例與失敗原因；並明確名單衛生與防濫用負責人。

從 IOSOR 開始

發送預算前跑號碼查詢，盡早丟棄壞 line-type；查詢結果進稽核。

相關：lookup recon before send budget voip vs mobile before otp

IOSOR 要點

查詢號碼是預算控管的核心閘口，而非僅僅是裝飾性的功能。在觸發任何付費簡訊發送流程之前，透過預先查詢功能可以有效識別無法送達的號碼或市話，進而大幅減少無效的簡訊流量並節省預付費用。工程團隊應將查詢結果中的結構化欄位納入路由邏輯中，動態過濾掉無效的目標位址，而不是將查詢視為送達保證或替代用戶同意的手段。

在實際操作中，請務必直接在路由閘口檢查線路類型分類與失敗負載資訊，以確保在支付發送費用前排除所有無效目的地。同時，不應將查詢數據視為用戶訂閱許可的替代品，也不應在缺乏持續關聯檢查的情況下，假設外部目錄能完全反映即時的路由可達性。開發者應定期檢查控制台中的日誌與分類結果，並根據 UTC 時間戳記同步帳本數據，以確保預算分配與實際發送路徑保持一致。