「編排」呢個字經常用嚟講兩件唔同嘅工作，將佢哋混為一談，正正係多渠道項目卡住嘅原因。旅程編排決定係咪聯絡一個人、幾時聯絡、點解聯絡、用邊個渠道聯絡——呢個係業務邏輯。派送營運就負責執行一個已經做咗嘅決定：喺某個渠道入面揀發送方同路由、適配供應商、重試同 failover。兩者應該有唔同嘅負責人、唔同嘅測試方法同唔同嘅失敗處理。
建模客戶狀態，而唔係逐渠道砌工作流
最關鍵嘅設計決定，係系統維護嘅係關於個流程本身嘅統一狀態——呢張帳單未找、呢個預約未確認——定係各自為政、互不知情嘅逐渠道流程序列。有咗統一狀態，每個渠道上嘅每次嘗試都作用喺同一筆記錄度，由呢筆記錄決定下一步會發生咩事。
觸發事件同佢嘅時效
事件會過期：帳單已經找清，預約已經確認。系統需要喺發送前嗰一刻重新讀取狀態，唔係淨係喺排期嗰陣讀一次，並喺請求入面帶住一個新鮮度標記，用嚟拒絕已經過時嘅決定。
喺發送嗰一刻評估資格規則
可追溯嘅 consent 證據、跨渠道跨供應商同步生效嘅抑制名單、渠道嘅真實可用性、已驗證嘅身分、語言同本地時區、按本地時間評估嘅免打擾時段、頻率上限同流量類別，呢啲都應該喺發送嗰一刻評估，而唔係喺用戶加入旅程嗰陣評估一次就唔再變。
決策策略：揀邊個渠道，點解
偏好渠道、緊急程度同限期、內容敏感度——普通短訊喺傳輸中應該被視為未加密而且可能出現喺鎖屏上，所以唔應該帶住密碼或者敏感個人資料——風險、作為眾多輸入之一被記錄嘅成本，同渠道本身嘅能力，都應該按使用場景寫成一張明確嘅表。
幂等性、嘗試狀態同降級路徑
去重必須發生喺狀態層面，並喺發送前保存一個自有引用。每次嘗試都需要明確嘅狀態——已創建、已提交、供應商最終狀態、逾時、被取代——從而分清一個確定嘅失敗同淨係冇收到確認嘅分別。降級路徑嘅觸發應該按流程本身嘅限期同真正可信嘅訊號（明確拒絕、無效目的地），而對淨係欠奉回執呢種情況要小心處理。需要設定渠道同嘗試次數嘅上限，同鏈路耗盡之後嘅處理路徑。
停止條件、回覆同歸因
每個旅程都需要喺發送嗰刻被檢查嘅明確停止條件——已達成結果、狀態已改變、已退訂或投訴、限期已過、達到頻率上限、營運層面嘅開關已關閉。收到嘅回覆同退訂必須進入狀態機並喺各渠道之間同步。用同一個旅程 ID 貫穿所有嘗試、點擊同結果，先可以知道邊樣嘢真正發揮咗作用，而唔係任由每個渠道各自邀功。
兩層各自嘅歸屬
派送營運——適配器、路由、發送方身分、重試、對帳同升級處理——係幾乎冇團隊應該重複起嘅部分。Flowstates 提供並營運渠道同路由，透過 BYOV 支援客戶自有供應商，亦支援混合部署，做呢一層託管層。編排就變化性大好多，通常存在於業務統一狀態本身所在嘅地方：你自己嘅 應用、已有嘅 CRM，或者由 Flowstates 支援嘅工作流。