入站第二個月：在同一租用 DID 上的 MO 負載

從試用到正式營運的過渡期

在成功完成 入站試用週：在租用的 DID 上進行 MO 即時檢查 後，營運的第二個月將重點放在穩定 MO（行動發起）流量的負載。與初期將連線能力視為首要任務不同，第二個月的關鍵在於同一租用 DID 的持續性。IOSOR 採用 JIT（即時）分配模型，在預付金額確認後，專門為您的帳戶佈建並保留該號碼。此舉能有效避免傳統系統中常見的號碼回收過快所導致的客戶流失問題。透過維持相同的號碼識別，您可以建立對行動網路的信任，並確保入站訊息串流的穩定與不間斷。

持續性 DID 上的 MO 負載動態

在第二個月維持相同的 DID 對於使用者留存和對話執行緒的連貫性至關重要。當使用者回覆一次性密碼（OTP）或行銷訊息時，他們期望對話能夠順暢延續。高 MO 流量的處理需要強固的 DLR（遞送報告）追蹤機制以及即時的 webhook 回應能力。這與稍後進行的 [入站帳單週：在同一匯出檔中比較 MO 與 MT 混合流量](/learn/inbound/inbound -invoice-week-mo-mt-mix) 中的帳務對帳流程不同，此階段更關注接收訊息的原始傳輸量。號碼的持續性有助於在 10DLC 和長碼路由上進行更精確的信譽管理，因為流量模式對下游的篩選器而言變得更加可預測，從而減少誤判。

技術門檻與計費

為了維持活躍的 DID 和高吞吐量路由，IOSOR 要求預付至少 20 美元的金額。此預付餘額確保 JIT 分配能夠持續鎖定您的專屬號碼，並保證系統能夠處理突發的 MO 流量而不發生中斷。隨著您的 MO 流量負載增加，系統會持續監控即時消耗量。若您的每月流量接近每月 1,000 美元的溫和審查門檻，我們的團隊將主動啟動效能檢查，以確保路由的穩定性並符合全球電信營運標準。這種主動式管理策略能有效防止在關鍵擴展階段發生服務暫停。

擴展入站 Webhook

每日處理數千則 MO 訊息需要一個可擴展的後端基礎設施。IOSOR 透過 webhook 將訊息資料推送至您指定的端點。在第二個月，您應優化您的 webhook 監聽器以處理並行 POST 請求，避免因請求堆積而造成的瓶頸。這包括配置足夠的伺服器資源，並可能採用負載平衡策略。同時，應確保您的應用程式能夠正確處理來自 IOSOR 系統的驗證請求，通常是基於權杖（token-based）的驗證，以確保資料傳輸的安全性。監控 webhook 的延遲時間，目標是從訊息到達 IOSOR 的時間（HB - Heartbeat）到您的端點接收到訊息的時間（Webhook）應小於 200 毫秒。同時，應設計您的系統以支援無限制的併發 MO 訊息串流，並確保資料日誌至少保留 30 天以供日後審查。傳輸協定必須是 HTTPS POST。

流量審查與合規性

隨著您業務的擴展，遵守 STOP 與 HELP 關鍵詞政策 變得至關重要。自動化系統會篩選這些關鍵詞，以保護長碼或 10DLC 路由的完整性，並避免被視為垃圾訊息。這與 入站帳單週：在同一匯出檔中比較 MO 與 MT 混合流量 的流程不同，後者專注於月底的帳單調整和流量匯總分析，而此階段則側重於即時流量的健康狀況監控與合規性。確保您的應用程式邏輯能夠正確處理這些關鍵詞的拒收請求，是維持高強度 MO 行銷活動訊息送達率的最有效方法。此外，應定期檢查您的預付錢包餘額，確保其始終高於最低要求，以避免因餘額不足導致服務中斷。在 console 中，您可以監控即時的訊息流量和預付餘額消耗情況。

與 IOSOR 一起啟航

在第二個月，您將使用在試用期內通過驗證的同一租用 DID，處理一整天的工作日流量負載，而非僅僅是尖峰時段的流量。這意味著您的 webhook 消費者、關鍵詞過濾表以及預付錢包的運行能力都必須能夠穩定支撐，並且不能丟失任何包含 "STOP" 指令的訊息。您需要監控匯出檔的處理延遲、關鍵詞的命中情況，以及當日入站訊息的扣款情況。將第二個月視為一次為期一小時的試點冒煙測試，若在此期間出現任何問題，則應視為失敗。這是對同一號碼的真實負載測試，而不是切換到第二個號碼，也不是在恢復限速狀態下進行測試。

IOSOR 要點

第二個月的入站流量測試，是在同一 DID 上進行真實的 MO 負載驗證。試點階段的冒煙測試並不能證明實際的容量承載能力。

必須做： 根據每日工作日的流量曲線，為您的 webhook 消費者和預付錢包設定合理的容量規劃。切勿做： 在生產環境的入站流量已經增加後，仍然保留試點階段的低容量限制。