租用 DID 上的 STOP 與 HELP：客服能辯護的政策

關鍵字不是可愛的自動回覆。在可接收回覆的租用 DID 上，STOP 與 HELP 是合規與品牌政策——客服必須在凌晨兩點也能辯護的腳本，而不是憑口耳相傳臨時編造。沒有這條政策的雙向訊息，會悄悄變成事故佇列。

IOSOR 將入站放在與出站相同的白標預付表面上：你的品牌關係、你的收件路徑、你的錢包——日常營運不必困在第三方入口裡。

關鍵字是政策，不是機器人支線任務

產品、法務與客服應在首次會話發送前共同簽署一頁：

若 STOP「通常能用」，你擁有的是運氣，不是政策。運氣無法通過凌晨合規審查，也無法寫進合約附件或任何對外的客戶 SLA。

寫出客服能大聲朗讀的 STOP 文案

STOP 回覆應簡短、面向品牌、毫不含糊：

• 確認該程式／身分下的退訂已生效
• 說明停止什麼（告警、行銷類、本 DID 執行緒）
• 若客戶仍需幫助，指向人工路徑
• 避免傾倒技術 ID 或第三方品牌名

日誌：誰發送了 STOP、哪個 DID、何時履行、哪些出站類別被攔截。客服升級必須從你們的平台拉取該日誌——而不是截圖追獵。

與真實工時相符的 HELP

HELP 是品牌最容易過度承諾之處。將自動回覆與以下對齊：

1. 真實的客服時段與時區
2. 你們實際配置的管道（郵件、聊天、回電）——不是幻想
3. 客戶應提供什麼（號碼後四位、訂單號）
4. 無人在線時的下一步

租用 DID 若用失效信箱回答 HELP，會訓練使用者在社交媒體更大聲投訴——燒毀信任比遲到 OTP 更快。

歸屬與稽核軌跡

指定主負責人與備援。生產環境 STOP 失敗是合規事件，不是「調一下機器人」工單。工單優先級應按合規事故處理，而不是按內容美化請求排隊。

需要：

• 你們的堆疊可核驗的 MO webhook 或收件事件
• 冪等處理（重試會發生）
• 關聯：入站關鍵字 → 客戶 id → 抑制狀態
• 可能含 PII 的關鍵字正文留存規則

白標意味著座席留在同一商業表面。「去查另一個入口」不是營運模型。

把收與發送成無關商品時，STOP/HELP 就會崩潰。放量前確認：

• 租用 DID 能接收 MO，並在規則允許處發送
• 購買後指派到你們帳戶——不是懸浮到有人去別處點擊
• Webhook 目的地與你們已有出站平台一致

IOSOR 號碼路徑是預付與即時：搜尋、暫扣、購買、指派。關鍵字就緒屬於該指派故事。

入站不是免費營運。號碼租金、計費處的 MO 處理、座席時間以及錯誤的 START/STOP 循環都要花錢。優先：

• 與 DID 程式綁定的可見預付錢包明細
• 自動回覆風暴上限，避免測試或誤觸掏空餘額
• 清晰區分資金失敗與關鍵字處理器失敗，避免客服把錢的問題當成政策故障
• 會話放量前先做小額預付緩衝演練，確認 STOP/HELP 與錢包事件可串聯

接近每月 USD 1,000+ 平台用量時，關鍵字政策品質成為合作訊號：受監管走廊與會話量需要可辯護的 STOP/HELP——不是為空帳戶講訂閱費故事。財務也要同一套詞彙：哪些 outbound 類因 STOP 被抑制、錢包何時扣費。

危險訊號

• STOP 回覆點名另一公司的入口
• HELP 時段與編制不符
• 沒有退訂履行時間日誌
• 行銷在合規審核外 live 改關鍵字
• 入站仍 in setup 卻宣稱 live 會話能力
• 用戶端錯誤傾倒上游品牌名
• START 循環可反覆燒預付卻無人工覆核

開始使用 IOSOR

寫一頁客服能對著租用 DID 大聲念出的 STOP 與 HELP。接上兩個詞，各證明一列稽核列，並點名非工作時間的 HELP。這是一個號碼上的口頭政策，不是租戶退出名單隔離，不是接入垃圾打分，也不是雙向收件匣架構。

相關: 入站自動回覆循環抽錢包 緩衝進站 Webhook 處理以應對電信商延遲飆升 首次扣款前的預付資金保留.

IOSOR 要點

STOP 與 HELP 是租號上的口頭政策，不是多租戶退出名單同步。

該做： 寫下客服能念的措辭，並證明稽核列。 別做： 把關鍵詞當機器人支線，或在此同步別的租戶退出名單。