渠道回退策略：WhatsApp、RCS 与短信

本指南面向在多个渠道发送重要消息、并希望每位客户都只收到一次的客户体验、CRM 和工程负责人。它介绍如何设计 WhatsApp、RCS 和短信之间的回退：由什么触发、等待多长时间、如何避免重复，以及用户授权在哪些方面限制了你的做法。关于各渠道本身的对比，请参阅 WhatsApp、短信与 RCS 对比。

什么是渠道回退策略？

渠道回退策略是一组规则，用来决定每条消息先尝试哪个渠道、何时放弃该渠道，以及接下来使用哪个渠道。它的目标是让客户在最合适的可用渠道上，及时、只收到一次这条消息。

每个渠道都有覆盖盲区。WhatsApp 只能触达有账号且有数据连接的人。RCS 只能触达支持 RCS 商业消息的设备和运营商。短信几乎可以触达所有手机，但只能承载纯文本。回退把它们结合起来，用一个渠道弥补另一个渠道的盲区。

一条回退链路包含四个部分：

1. 渠道顺序，例如先 WhatsApp，再 RCS，最后短信。
2. 将消息转移到下一个渠道的触发条件。
3. 每一步的超时时间，依据消息保持有效的时长而定。
4. 一旦确认送达就结束链路，并取消所有待处理尝试的停止规则。

如何选择渠道顺序？

渠道顺序应按消息类型和客户来选择，而不是为整个业务只定一次。对于内容丰富的交易类消息，“先 WhatsApp，再 RCS，最后短信”是常见顺序，但并不总是最佳。

• 从客户能够触达的渠道开始。 如果你的记录显示某个号码没有 WhatsApp 账号，先用 WhatsApp 只会多一次失败的尝试并造成延迟。如果能力检测显示该号码无法接收 RCS，就跳过 RCS。
• 关键提醒优先使用最可靠的渠道。 对于欺诈预警或安全类消息，许多团队先发短信，因为它无需数据连接即可工作，然后用内容丰富的渠道做后续跟进。
• 尊重客户明确表达的偏好。 如果客户在注册时选择了短信，即使有功能更丰富的渠道，也应尊重这一选择。
• 让客服留在客户所用的渠道。 对在 WhatsApp 上发来消息的客户，应在 WhatsApp 上回复；回退针对的是企业主动发起的消息。
• 按市场复核顺序。 在海湾市场，WhatsApp 被广泛用于企业消息，而 RCS 的覆盖情况取决于运营商和国家，因此最佳顺序在阿联酋和欧洲之间可能不同。

什么应该触发回退？

两类事件应当触发回退：发送时出现的错误，以及超时结束时仍未收到送达确认。已读回执不应触发回退。

即时错误

有些失败可以立刻得知。在 RCS 上，Google 的文档指出，当设备不支持 RCS、RCS 已关闭，或你的 Agent 尚未在用户所在网络上线时，平台返回 404 NOT_FOUND；当消息使用了设备无法显示的功能时，返回 400 INVALID_ARGUMENT。在 WhatsApp 上，当号码没有 WhatsApp 账号或模板被拒绝时，发送可能失败。这些情况应无需等待，直接切换到下一个渠道。

你可以通过事先检测来避免许多此类错误。Google 的 RBM 平台提供能力检测，可以报告某个号码能否接收 RCS，以及支持哪些功能，前提是该号码近期连接过 RCS。

超时

其他失败是无声的。消息被接受了，但始终没有 DELIVERED 状态，通常是因为手机关机或离线。Google 的 RBM 平台会把未送达的消息最多保留 30 天，所以如果没有超时机制，RCS 消息可能在早已失去意义之后才到达。

为什么不用已读回执？

无论在 WhatsApp 还是 RCS 上，已读回执都取决于用户的设置。关闭了已读回执的客户可能读过每条消息，却从不发送 READ 事件。根据缺失的已读状态来回退，会发送不必要的短信并造成重复。请用已读数据来衡量互动，而不是驱动回退。

每一步应该等待多久？

根据消息的有效期来设置超时时间：有效期越短，等待时间越短。不存在通用的数值，所以请先为每个使用场景设定一个有依据的初始值，再根据自己的送达数据调整。

两条规则能让超时机制更加可靠：

• 回退时让首次发送过期。 在 RCS 上，为消息设置 ttl 或 expireTime。Google 的文档说明，当消息未送达而过期时，平台会撤回它并通知你的 Webhook，这正是发送短信的天然信号。你也可以显式撤回消息。Meta 也为部分 WhatsApp 模板类型记录了生存时间（time-to-live）设置；哪些类别支持该设置，请查阅最新文档。
• 同样给短信设置有效期。 短信标准（3GPP TS 23.040）允许发送方设置有效期，超过该期限后网络将停止重试。验证码使用较短的有效期，可以避免验证码在过期之后才到达。

如何防止重复消息？

把每条消息当作一条有多种可能送达方式的逻辑消息，一旦确认其中一次送达就立刻停止链路。Google 的 RBM 最佳实践也强调了同一点：在重新发送之前，先确认消息未被送达，并使用唯一的消息 ID。

防重复检查清单

1. 为每条逻辑消息分配一个 ID， 并把每次渠道尝试都记录在该 ID 之下。
2. 每个回退步骤之前先检查记录： 只要任何渠道已报告 DELIVERED，就停止。
3. 在下一个渠道发送之前，让待处理的尝试过期或撤回。
4. 处理竞态条件。 Google 指出，撤回偶尔会失败，因为消息恰好在那一刻正在送达。如果撤回失败，请在发送短信之前先检查是否出现了 DELIVERED 事件。
5. 让内容即使收到两次也没问题。 验证码消息不应暗示第一个验证码已失效，除非确实如此；两条订单更新也不应互相矛盾。
6. 记录回退原因， 以便了解回退是由错误、超时还是能力缺口引起的。

用户授权与合规如何影响回退？

链路中的每个渠道都需要各自的许可。回退改变的是渠道，并不会把授权从一个渠道转移到另一个渠道。

• WhatsApp： Meta 要求企业在向用户发送消息之前先获得 opt-in，并且在客户服务窗口之外由企业发起的消息必须使用已审核的模板。请参阅 Meta 文档中的 WhatsApp opt-in。
• RCS： Google 的上线审核会检查你的触达是否符合用户授权，Agent 必须遵守 STOP 及等效关键词。
• 短信： 受当地电信和数据保护规则约束。在海湾市场，营销短信通常需要已报备的 Sender ID 并遵守允许的发送时段；请向监管机构和服务商确认细节。我们的 Sender ID 报备指南介绍了阿联酋和沙特的流程。

这也是为什么大多数营销消息不应回退。同意接收 WhatsApp 优惠的客户，可能并没有同意接收营销短信，而且短信还可能落在允许的时段之外。验证码和订单更新等交易类消息的处理依据更为扎实，但它们在每个渠道上都必须保持纯交易属性。退订要集中管理：在任何其他渠道发送营销消息之前，应先检查某个渠道上是否已有 STOP。我们的授权指南对此有详细说明。

回退如何影响成本？

回退只在触发时才增加成本，但调校不当的链路可能为同一条消息付两次费。请按每条已送达消息衡量成本，而不是按每次尝试。

• WhatsApp： Meta 按送达的模板消息，依类别和收件人所在市场计费。根据 Meta 的定价文档，自 2026 年 10 月 1 日起，Meta 对每个企业手机号超出每月免费额度的服务类消息收费，并对在客户服务窗口内发送的实用型（Utility）模板收费；请以 Meta 最新的价目表为准。
• RCS： 价格由各市场、运营商和服务商决定，并因消息类型而异。
• 短信： 按目的地、以分段为单位计费。阿拉伯语文本使用 Unicode，每个分段容纳的字符更少；请参阅我们的字符限制指南。

不影响送达效果的降本杠杆：

1. 跳过客户用不了的渠道。 对没有账号的人先用 WhatsApp，只会增加延迟和一次失败的尝试。
2. 在 RCS 发送之前使用能力检测。
3. 调整超时时间， 让回退针对离线手机触发，而不是针对延迟的送达回执。
4. 让回退短信保持简短， 尽量控制在一个分段内。

你可以在我们的定价页面比较各渠道的参考标价。

如何一步步实施回退链路？

1. 列出消息类型， 并为每一种指定主渠道、链路和超时时间。
2. 按客户记录渠道可用性： 是否已知有 WhatsApp 账号、RCS 能力、有效的手机号，以及各渠道的授权情况。
3. 为每个渠道撰写等效内容， 把关键信息用纯文本表达。
4. 将所有渠道的送达状态统一为一个模型，例如已发送、已送达、已读和失败，这样同一个规则引擎就可以据此行动。
5. 实现触发条件： 出错时立即回退，未确认送达时按超时回退。
6. 实现停止规则： 送达或回复即结束链路；待处理的尝试被过期或撤回。
7. 测试失败路径： 没有 WhatsApp 的号码、关闭了 RCS 的手机、关机的手机。
8. 每周监控： 各使用场景和市场的回退比例、原因、重复情况，以及每条已送达消息的成本。

消息 API 集成指南和送达状态指南介绍了 Webhook 方面的内容。

实操案例：一家海湾地区的电子产品零售商

“Najm Electronics”（虚构）在阿联酋、沙特阿拉伯和科威特进行线上销售。它在结账时发送验证码，并发送订单更新和每周优惠。

• 结账时的验证码。 已知有 WhatsApp 的客户会收到带“复制验证码”按钮的身份验证模板；其他客户直接收到短信。如果 WhatsApp 返回错误，或在较短的超时时间内未收到送达确认，就会发送有效期很短的短信验证码。结账页面会告知客户验证码可能通过短信送达。
• 订单更新。 链路是 WhatsApp，然后是支持设备上的 RCS，最后是短信。RCS 消息带有一张含“跟踪订单”操作的富媒体卡片，并把过期时间设置在配送时段之前很早的时刻。未送达而过期时，平台会撤回它，并附上相同的跟踪链接发送短信。系统会记录由哪个渠道送达，所以没有人会收到全部三条。
• 每周优惠。 优惠只通过 WhatsApp 发送给选择接收 WhatsApp 营销的客户。不做短信回退，因为这些客户中许多人并未同意接收营销短信，而且各国的发送时段不同。
• 复盘。 第一个月之后，团队按市场检查回退原因。某家运营商上较高比例的 RCS 错误表明，该 Agent 尚未在那里上线，因此在确认覆盖之前对该运营商跳过 RCS，从而为每条消息省下一次浪费的尝试。

回退中有哪些常见错误？

• 根据缺失的已读回执回退， 导致给已读过第一条消息的人发送重复消息。
• 首次发送没有设置有效期， 导致原始消息在短信之后才姗姗来迟。
• 所有消息共用一个超时时间， 对验证码来说太长，对提醒来说又太短。
• 未获得短信授权就把营销消息回退到短信。
• 各渠道内容不一致， 导致客户看到相互矛盾的细节。
• 先用客户不使用的渠道， 增加延迟和成本。
• 不衡量回退， 导致运营商故障和覆盖缺口无人察觉。

局限： 平台行为、定价和法规都会变化。请在 Google 和 Meta 的文档中以及向服务商确认最新细节。本指南是实用性指引，不构成法律意见。

OmniChannels.ai 如何提供帮助

OmniChannels.ai 允许你按使用场景配置渠道回退，例如先 WhatsApp，再 RCS，最后短信。来自每个渠道的送达状态（SUBMITTED、SENT、DELIVERED、READ、FAILED、REJECTED）都以统一的 Webhook 格式送达，因此同一套规则就可以驱动回退和报表。BroadNet Technologies 是 Meta 官方的 Business Solution Provider，也是 Google RBM 合作伙伴，短信通过其运营商直连通道发送。RCS 在不可用的地方内置自动短信回退。开发者可以从 RCS API 文档开始。