運營團隊在簽約前必須提問的關鍵問題

採購部門可能根據價格完成簽約，但運營團隊最終接手的卻是一個無法證明流量可靠性的平台。在正式簽字前，運營團隊需要明確知道 Webhook 心跳的最新狀態、門號如何透過 JIT 機制即時購買、Live 標籤的實際意義，以及 STOP 指令如何強制執行。這份檢核表是為了確保第一天跑道具備發射條件，而不是涵蓋 Payload 和等冪性的 SMS API 技術手冊。

IOSOR 第一天原則：順暢的跑道需要最新的 Webhook 心跳、僅在保管庫準備就緒時才顯示 Live，以及持續開啟的合規閘門。在沒有這些答案的情況下簽約，買到的只是一個表面看起來正常、實際發送路徑卻被阻斷的儀表板。請在法務簽字前將答案寫入第一天跑道檢核表中 — 缺少心跳機制必須堅決否決。

確認誰負責 Webhook 心跳時鐘

要求明確定義何謂最新的心跳，以及當心跳過期時會發生什麼情況。運營團隊必須清楚知道當心跳時間超出閘門限制時，會觸發何種警報、由誰來解除阻斷。如果合約中未明確指定心跳負責人，上線當天的流量狀態將會充滿不確定性。

要求提供最近一次成功的冒煙測試證明，而不是一張僅標註 '支援 Webhook' 的簡報頁面。

在承諾本地 DID 前釐清 JIT 門號採購流程

詢問門號是如何進行搜尋、預留、購買並從預付費餘額中扣款與指派的。JIT 意味著不存在偽裝成真實庫存的假資料，財務與運營團隊共享同一份訂單紀錄。如果合約承諾 '目錄中備有現成門號' 卻沒有完整的預留與指派流程，運營團隊將不得不建立第二套帳本。

要求明確劃分第一個 UTC 週期內的設定費與月租費負擔者，以免財務團隊在門號指派後產生疑慮。

審視 Live 標籤與設定圖示的差異

詢問哪些產品只有在保管庫綠燈後才能顯示為 Live，以及 '設定中' 對買方而言的真實含義。如果一個 Live 標籤所代表的通道無法被運營團隊進行測試，這就是誠信缺失。運營團隊應與銷售人員一同核對目錄，標註所有超出實際準備進度的標籤。

即將推出的功能屬於產品路線圖討論，不應列入第一週的強制性上線清單中。

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

確認 STOP 與生產環境合規閘門

詢問系統如何處理 STOP 關鍵字、黑名單儲存在何處，以及針對您將使用的通道，哪些生產合規閘門會保持強制執行。在沒有明確 STOP 權責的情況下簽約，首次收到用戶投訴時就可能引發法務與發送品質危機。

將 STOP 答案與第一天跑道檢核表結合，確保上線過程不會為了追求速度而忽略合規要求。

相關運營路徑

• SMS API 採購清單
• 第一天跑道：必須亮綠燈的事項
• A2P 放量前的合規閘門

從 IOSOR 開始

請開啟主控台的網頁hook設定，確認誰負責監控心跳逾期警報，以及過期閘道如何觸發系統升級。在您的測試專案中驗證隨需號碼搜尋、保留與指派流程，同時確認停止發送抑制表已有效封鎖不合規的通道。 簽約前把 heartbeat、JIT 與 Live 徽章答案寫進 day-1 runway；缺一項就是硬否決。

IOSOR 要點

買方檢核表必須在簽署合約前落實營運透明度。要求本地號碼具備清晰的保留、購買與指派流程、明確的網頁hook心跳負責機制，以及經過驗證的上線徽章準備狀態，能避免流量湧入時發生災難性的上線失敗。

請務必透過技術評估走訪每一個型錄功能，確保設定方塊符合實際執行能力。切勿接受表面的商業承諾，或在未通過完整稽核測試的停止抑制與正式合規閘道的情況下發布路由。