「编排」这个词常被用来指两件不同的工作，把它们混为一谈正是多渠道项目卡住的原因。旅程编排决定是否联系一个人、何时联系、为什么联系、通过哪个渠道联系——这是业务逻辑。投递运营则执行一个已经做出的决定：在某个渠道内选择发送方和路由、适配供应商、重试与故障转移。两者应有不同的负责人、不同的测试方式和不同的失败处理。
建模客户状态，而不是按渠道建工作流
最关键的设计决策是系统维护的是一份关于流程本身的统一状态——这张账单未付、这个预约未确认——还是各自为政、互不知情的按渠道流程序列。有了统一状态，每个渠道上的每次尝试都作用于同一条记录，由这条记录决定接下来会发生什么。
触发事件与其时效性
事件会过期：账单已经付清，预约已经确认。系统需要在发送前的那一刻重新读取状态，而不是只在排期时读取一次，并在请求中携带一个新鲜度标记，用来拒绝已经过时的决定。
在发送时刻评估资格规则
可追溯的 consent 证据、跨渠道跨供应商同步生效的抑制名单、渠道的真实可用性、已验证的身份、语言与本地时区、按本地时间评估的免打扰时段、频率上限与流量类别，这些都应该在发送那一刻评估，而不是在用户加入旅程时评估一次就不再变化。
决策策略：选哪个渠道，为什么
偏好渠道、紧迫程度与截止时间、内容敏感度——普通短信在传输中应被视为未加密且可能出现在锁屏上，因此不应携带凭证或敏感个人信息——风险、作为众多输入之一被记录的成本，以及渠道自身的能力， 都应该按使用场景写成一张明确的表格。
幂等性、尝试状态与降级路径
去重必须发生在状态层面，并在发送前保存一个自有引用。每次尝试都需要明确的状态——已创建、已提交、供应商最终状态、超时、被取代——从而区分确定的失败和仅仅是没有收到确认。降级路径的触发应该依据流程本身的截止时间和真正可信的信号（明确的拒绝、无效目的地），而对仅仅缺少回执这种情况要谨慎对待。需要设定渠道和尝试次数的上限，以及链路耗尽后的处理路径。
停止条件、回复与归因
每个旅程都需要在发送时被检查的明确停止条件——已达成结果、状态已改变、已退订或投诉、截止时间已过、达到频率上限、运营层面的开关被关闭。收到的回复和退订必须进入状态机并在各渠道间同步。用同一个旅程 ID 贯穿所有尝试、点击和结果，才能知道真正起作用的是什么，而不是让每个渠道各自邀功。
两层各自的归属
投递运营——适配器、路由、发送方身份、重试、对账与升级处理——是几乎没有团队应该重复建设的部分。Flowstates 提供并运营渠道与路由，通过 BYOV 支持客户自有供应商，也支持混合部署作为这一托管层。编排则更具变化性，通常存在于业务统一状态本身所在的地方：你自己的应用、已有的 CRM， 或者由 Flowstates 支持的工作流。