先分清楚名單、資格與通路狀態
常見做法是直接從 CRM 查出一批會員，再把 LINE user ID 丟進傳送 API。這在小規模測試時很快，但正式運作後容易失控：會員資料可能在排程執行期間更新，同一人可能出現在多個分群，LINE 好友狀態也可能已經改變。工程上應把「符合商業條件」、「同意接收這類訊息」與「目前可透過 LINE 聯絡」拆成三個判斷，不要用單一布林欄位代表全部。
每次活動應建立不可變的名單快照。快照保存分群規則版本、產生時間、來源系統、納入原因與排除原因；實際發送只讀取快照，不在傳送途中重新查詢動態條件。若活動需要反映即時狀態，可在送出前再執行一次資格檢查，但應把檢查結果寫回活動紀錄。這樣即使 CRM 標籤之後改變，團隊仍能重建當時的決策。
- 業務資格：例如合約狀態、產品別、服務區域、最近交易階段或工單狀態。
- 同意資格：訊息目的、取得來源、同意版本、生效時間，以及是否已撤回。
- 通路資格：LINE 帳號是否完成綁定、識別碼是否有效，以及是否已知無法觸達。
- 排除規則：退訂、內部測試帳號、重複身分、法務封鎖與活動冷卻期間。
把同意當成可追溯事件，而不是會員欄位
「已同意」若只是一個可被覆寫的欄位，之後很難說明同意的是什麼。較穩健的模型是保留事件式紀錄：誰在何時、透過哪個畫面或流程、針對哪一種通知目的、接受哪一版說明；撤回時新增撤回事件，而不是刪除舊資料。計算目前資格時，再依事件順序與規則取得有效狀態。這種設計也能處理會員重新加入、重新綁定或只取消部分通知類型的情況。
LINE 加好友、帳號綁定與行銷或服務通知同意，不應自動視為同一件事。服務異常、交易進度與促銷活動可能需要不同的目的分類。若規則不確定，系統應採取保守策略，把狀態標記為待確認或不可發送，而不是把缺少資料解讀為同意。所有排除邏輯也應集中在同一個資格服務中，避免 CRM、排程程式與後台各自實作一套不同規則。
- 同意紀錄不可靜默覆寫：修正資料時仍保留異動者、異動時間與原因。
- 退訂優先於分群：即使使用者再次符合行銷條件，也不能繞過有效的抑制狀態。
- 目的要足夠明確：不要用一個籠統欄位同時涵蓋交易通知、客服提醒與推廣內容。
- 資料保存要有界線：只保存稽核與營運真正需要的內容，並限制查閱權限。
傳送流程需要冪等、節流與明確的狀態機
排程重跑、工作逾時與網路錯誤都可能造成重複傳送。每次通知應建立穩定的冪等鍵，例如由活動、收件人、訊息版本與預定批次組成；工作程序在送出前先以原子操作取得傳送權，再記錄嘗試。若 API 回應不明確，不要立即當作失敗重送，因為請求可能已被服務端接受。比較安全的做法是標記為結果未知，經查詢或人工規則確認後再決定是否補送。
實作上可將狀態分為待處理、已抑制、送出中、平台已接受、已完成、已失敗與結果未知。狀態轉換要附帶時間、批次、請求識別資訊及錯誤分類。遇到速率限制或暫時性錯誤時使用有上限的退避重試；遇到無效識別碼、權限或訊息格式問題時則停止盲目重試。大型名單應分批處理，批次大小依平台限制、可觀測性與失敗重跑成本決定，而不是一味追求最大吞吐量。
- 活動層：內容版本、預定時間、分群快照與審核狀態。
- 收件人層：資格判斷、抑制原因、冪等鍵與最後處理狀態。
- 請求層：送出時間、平台請求識別資訊、嘗試次數與原始錯誤分類。
- 批次層：目標數、平台接受數、成功數、失敗數與尚待確認數。
只報告平台能證明的結果
通知系統最容易犯的錯，是把 API 成功回應寫成「使用者已收到」，甚至進一步當成「已讀」。實際上，成功回應通常只代表請求格式有效並被平台接受；可取得的批次進度或彙總結果，也不一定能對應到每一位收件人的裝置送達狀態。資料模型與後台用語應區分已提交、平台已接受、處理完成、失敗、互動與已讀，沒有可靠證據的狀態就不要推定。
營運報表應能從名單快照一路對帳到平台結果：原始符合人數、因同意或通路狀態被排除的人數、實際提交人數、平台回報的完成與失敗數，以及仍未知的差額。點擊與回覆屬於另一條事件鏈，可使用活動識別參數或 webhook 關聯，但要與傳送結果分開呈現。告警則應關注工作停滯、未知狀態累積、失敗原因突然改變，以及來源資料與批次總數無法平衡。
上線前至少要演練重複排程、傳送中斷、退訂與發送同時發生、CRM 延遲更新、失效 LINE 識別碼及平台暫時不可用等情境。真正可靠的自動化，不是保證每則訊息都成功，而是在不確定發生時不重複打擾使用者，並讓工程、客服與稽核人員看到一致的事實。若流程橫跨 LINE OA、CRM、ERP 與資料平台，整合團隊的價值就在於把這些狀態與責任邊界落到同一套可驗證的設計中。