先講清楚：呢篇係營運指引，唔係法律意見。 要求會因司法轄區、營運商同你自己供應商嘅條款而異，而且會隨時間改變。以下任何內容都唔應該取代查閱你嘅營運商、註冊平台同你自己法律顧問嘅最新一手指引。
營運美國 SMS 計劃,重點與其講係識法律,不如講係要隨時攞到證據證明你嘅營運真係做緊佢話做嘅嘢。Consent、退訂、sender 身分同註冊,呢啲都可能被營運商、aggregator,甚至客戶嘅律師要 求舉證。好多計劃出事,唔係因為冇人明白規則,而係證據根本冇留低,或者散落喺五個唔同、互相對唔上嘅系統入面。
Consent 證據：要留低咩
問題永遠唔係「有冇攞到 consent」,而係「六個月後,可唔可以就一個特定號碼,即刻拎出紀錄」。呢份紀錄應該包括：來源（邊個表格、keyword、結帳流程定合作夥伴渠道攞到 opt-in）、時間戳、當時顯示嘅確實文案（唔係而家版本嘅條款頁——如果法律團隊之後改咗文案，你要保留舊版對應舊嘅 consent 紀錄），同渠道／IP（頁面、app 畫面或者渠道,以及有攞到嘅話,網頁 opt-in 對應嘅 IP）。
第三方 lead 來源同舊有登記表格通常係最弱一環——lead 供應商會話「用戶已經 opt-in」,但如果佢哋攞唔出當時嘅文案同時間戳,你有嘅只係一個講法,唔係證據。
Brand 同 campaign 註冊：文件同流量對唔對得上
10DLC（或者類似機制）嘅目的係話俾營運商知你係邊個、你送緊咩、用戶點樣可以進出。最常見嘅營運失誤係「漂移」：登記做「帳戶通知」嘅 campaign 之後開始夾雜促銷內容,或者登記做低流量嘅用途規模擴大超出登記吞吐。呢唔淨係文書問題——營運商同 aggregator 會主動比較登記用途同實際流量,唔一致係合法流量被過濾或者限速嘅常見原因之一。內容、流量或者受眾有明顯改變嘅時候都應該重新覆核註冊,唔淨係一開始做一次。
唔同流量類別要分清楚
營銷、事務性、OTP、客服，呢幾類流量嘅期望唔一樣，混用同一個 sender ID 或者同一個登記 campaign 係常見問題根源。一個 OTP sender 一旦開始夾雜促銷文案,喺營運商過濾系統眼中就唔再似 OTP sender；營銷發送如果同 OTP 共用路由,亦會拖慢時效性訊息。將 sender 同 campaign 對齊單一登記用途,sender 承載內容改變要當成需要簽核嘅改動,而唔係文案微調。
退訂處理
STOP 同其常見變體要即時自動生效，但客戶都會用自然語言講（「唔好再send」、「刪除我」），支援渠道（電話、電郵、chat）都會收到退訂請求——要明確決定呢啲會唔會、點樣入返同一個 suppression 系統。一個系統入面加嘅 suppression（客服 ticket、某個 campaign 嘅 keyword handler）要傳到所有其他可能發訊息俾嗰個號碼嘅系統：其他 campaign、其他供應商、CRM 重新入資料、lead 供應商同步——呢通常係最弱一環,因為 suppression 邏輯多數係逐個 campaign 起,唔係逐個客戶。由「客戶話要停」到「號碼真係全面被 suppress」之間嘅延遲要短,亦要監測,唔可以假設佢冇問題。
Quiet hours 同發送時段
Quiet hours 講就簡單,實現就難,因為要跟收件人本地時間,唔係發送方時間。將電話號碼對應返時區係個真實嘅工程問題：區碼未必反映而家所在位置,可攜號碼冇位置訊號,存低嘅寄件地址都未必等於 手機而家所在地。要明確決定信邊個訊號嚟判斷時區（帳單地址、註冊時 IP、營運商回報嘅地區）,並且承認呢只係個估算,而唔係假設一個全球統一嘅截止時間啱曬所有地方。
Suppression 名單：範圍、擁有者、換供應商
Suppression 名單只有喺大家對「覆蓋範圍」有共識時先有用——係按品牌、按 campaign,定係涵蓋所有訊息類型？由邊個團隊擁有——SMS 平台、CRM,定專門嘅合規系統？換供應商嗰陣,名單會唔會跟過去,定新供應商由零開始,重新發訊息俾本來已經 suppress 嘅號碼？呢係遷移供應商時常見嘅出事點,值得寫成正式流程,唔係口頭交接。
Template 同內容管治
邊個負責審批新 template、按咩準則？有冇版本紀錄可以還原某個時間送咗咩俾邊個受眾？連結點樣處理——短連結有冇經審批,production 入面可唔可以直接改文案而唔經審批？邊個有權限改 production 嘅 template,呢個權限有冇紀錄？一個悄悄偏離已登記版本嘅 template,正正就係營運商或者註冊審核時最容易被揪出嘅落差。
紀錄保留
Consent 紀錄、退訂紀錄、訊息紀錄同 template 版本歷史要保留幾耐,係一個business要主動決定嘅政策,唔應該由「資料庫剛好保留咗幾耐」或者「供應商預設 log 保留期」決定。保留期要參考法律顧問意見同自身風險狀況去定,寫低決定,並確 保所有相關系統（包括第三方供應商）都真係跟到,唔淨係主平台。
路由同供應商變更管控
換供應商、加 failover 路徑、換 sender ID,呢啲係合規層面嘅改動,唔淨係技術改動,因為可能影響登記有效性、suppression 名單覆蓋同吞吐預期。路由改動上線之前應該記低：改咗咩、點解改、邊個批准、登記有冇跟住更新、suppression 名單有冇確認跟得住。同改 consent 文案一樣，呢個都要留紀錄,唔止係一次 deploy。
事故責任
當營運商、aggregator 或者監管機構提出投訴或者違規通知,第一個鐘頭好緊要。要事先定好：邊個係對外聯絡人,佢有冇權單方面暫停 campaign？可以幾快整合出一份證據包——某個號碼嘅 consent 紀錄、相關退訂歷史、送出嘅 template 版本、註冊狀態、路由歷史？邊個負責同供應商或者營運商溝通,邊個要先審核回覆先出？
自己要查嘅嘢
以上任何內容都唔可以取代查閱最新一手指引：你嘅註冊平台目前嘅登記要求、你嘅營運商目前嘅過濾同內容政策,以及現行嘅聯邦同州法律,理想情況下要有自己嘅法律顧問參與。規則、登記欄位同平台要求都會變,呢篇文寫嘅時候啱,唔代表你睇嘅時候仲啱。
Flowstates 唔提供法律合規服務——嗰個決定要由你同你嘅法律顧問去做。我哋幫得手嘅係底層嘅營運層：路由、sender 管理,同埋支援你用自己嘅供應商、Flowstates 營運嘅渠道,或者兩者混合,提供足夠嘅能見度令你有人問起呢份清單入面嘅問題時答得出。