幾時應該用群發 SMS
SMS 啱用喺短、有時限、而且收件人已經同你有關係嘅訊息：預約提醒、送貨時段、俾活躍客戶嘅偶爾優惠。以下情況就唔啱：需要較長篇幅或排版（email 更啱）、consent 記錄薄弱、內容敏感，或者因為分群困難而變成向所有人廣播——呢個 pattern 正正會導致退訂同運營商過濾。
分開 marketing、服務同緊急營運流量
呢個係最影響項目效果嘅結構性決定。traffic class 應該係每條訊息嘅核心屬性，決定發送方、路由、隊列同時段規則。Marketing 類需要 marketing consent，喺容量緊絀時最先被削減；服務/交易類優先級較高，但仍然受 suppression 約束；緊急營運類需要獨立容量同明確嘅界定標準，唔係咩都會變成「緊急」。混用一個發送方會令 marketing batch 拖慢服務流量，亦會損害服務流量依賴嘅發送方信譽。
名單來源、consent 證據同 suppression
每個聯絡人記錄都應該保存：號碼來源、蒐集時展示嘅確切字眼、consent 覆蓋邊啲 traffic class，同埋退訂時間戳。Suppression 應該係一個統一儲存，被每條發送路徑檢查，退訂需要即時全面生效。具體規則因市場、運營商同項目類型而異，需要逐項核實，唔可以假設。
分群、頻次同發送方
按相關性分群——關係狀態、流程所處階段、之前對 SMS 嘅參與度、語言同時區——效果一定好過向成個名單廣播。頻次封頂同安靜時段係企業自己擁有嘅客戶體驗治理手段，應該喺所有發送路徑統一執行，同需要按市場核實嘅法律義務係兩回事。發送方需要完成註冊、喺項目內保持穩定，並喺訊息開頭幾個字就可以俾人認得。
編碼、發送容量同結果量度
一個 Unicode 字元就可以令 160 字元嘅 GSM-7 訊息變成多段 Unicode 訊息，直接影響成本，所以段數應該喺發送前計算，並喺 template 儲存時驗證。大規模發送要對照每條路由嘅吞吐限制排隊，按 traffic class 分開隊列，並設定硬性送達限期，過咗期寧願放棄都唔好遲發。送達回執可以講嘅嘢有限，DLR semantics 因運營商同路由而異，更啱喺應用層量度：完成率、click、回覆同退訂率，並跨路由同供應商比較呢啲結果。
首次大規模發送之前
需要一個來源清楚、每條記錄都有 consent 證據嘅名單；一個已經喺該市場完成註冊嘅發送方；喺實際使用嘅發送路徑上核實過嘅 suppression；用真實資料驗證過編碼同段數嘅 template；以及事先定義好嘅停止條件——退訂率門檻、投訴數量、集中喺某個市場或運營商嘅失敗——每一項都要指定對應嘅行動同負責人。