不存在通用的渠道顺序
多数回退设计从一条渠道阶梯开始，随后才发现它对一半的旅程都是错的。顺序是结果，不是输入。输入是业务目标和可用的截止时间。
策略实际评估的内容
每次尝试之前：目标与成功判定；过了之后送达也无意义的可用截止时间；同意状态与用户表达的偏好；已验证的目的地；该市场的渠道可用性与你的发送方是否获批；内容的紧急程度与敏感度；每达成一次结果的成本；以及信号的可靠性。
可靠信号与含义模糊的信号
提交时被拒绝，足以支持切换到下一个渠道。送达回执说明渠道触达了设备，不代表有人看到。已读标记不能证明注意力，而且可能被关闭。没有状态是模糊，不是失败：把沉默当作失败会产生重复消息。
一次旅程，一个标识
在决定沟通的那一刻生成旅程 ID，并出现在每次尝试、回调与结果中。由此可得：每次尝试前重新评估资格；在旅程层面做幂等与去重；尝试状态与旅程状态分开保存；目标达成或业务状态变化时，停止条件优先；迟到的回调要记录，但不得重新打开已完成的旅程。
串行还是并行
默认串行。当漏掉一条消息的后果明显重于重复的代价——安全、欺诈、故障——或截止时间不允许串行链条时，才用并行。对于用户正在等待的验证码，约束是截止时间，而不是一条关于允许哪些渠道的规则；要避免的是同一会话产生第二个验证码。
决策表
| 旅程 | 目标与截止时间 | 排序逻辑 | 停止条件 |
|---|---|---|---|
| 验证码 | 在当前会话内收到验证码 | 信号可靠且目的地已验证的最快渠道 | 验证完成、会话结束、截止时间 |
| 配送或预约提醒 | 在事件发生前告知收件人 | 偏好渠道，其后是下一个合适渠道 | 已确认、事件已发生或已取消 |
| 付款提醒 | 到期前付款 | 具备同意与身份可信度的渠道，再升级到可回复渠道 | 已付款、已达成安排、状态变化 |
| 支持跟进 | 收到回复 | 该对话所在的渠道 | 已回复、工单关闭 |
| 营销推广 | 基于同意的互动 | 最便宜的合规渠道，不重复同一优惠 | 退订、频次上限、活动结束 |
| 紧急运营通知 | 收到确认 | 在合适渠道上并行，随后由人工升级 | 已确认或升级流程走完 |
状态机
旅程: 已计划 -> 尝试中 -> 已完成 | 已停止 | 已用尽
每次尝试: 检查截止时间与停止条件, 重新评估资格,
在提交前先保存幂等键并创建尝试记录
结果: 被拒绝或终态失败 -> 下一个候选渠道
已送达但未达成目标 -> 等待本次尝试的截止时间
到截止时间仍无状态 -> 模糊 (继续意味着接受重复)
收件人已行动 -> 已完成, 取消未结束的尝试
迟到回调: 记录, 但不重新打开已完成的旅程
模糊分支是多数设计静默出错的地方。当重复会造成伤害时——第二个验证码、第二条付款提醒——等待或停止通常才是正确选择。
归因与成本
按旅程类型和链条位置统计结果；整条链上每达成一次结果的成本；重复率；模糊率；停止条件的有效性。如果多数结果出现在第二或第三个位置，说明第一个位置对这部分人群是错的。
交付模式
Flowstates 销售并运营多渠道的消息路由，支持客户自有供应商合同（BYOV）与混合模式。无论哪种模式，链条逻辑都是同一份工作，并且应该与定义目标的业务状态放在一起。