---
title: "渠道回退策略：WhatsApp、RCS 与短信"
description: "如何设计 WhatsApp、RCS 和短信之间的渠道回退策略：回退触发条件、按消息类型设置超时时间、防止重复发送，以及各渠道的用户授权与成本考量，帮助出海企业确保重要消息只送达一次，并兼顾送达率与成本，并附海湾电子产品零售商的实操案例与常见错误。"
canonical: "https://omnichannels.ai/zh/blog/channel-fallback-strategy/"
language: "zh"
updated: "2026-10-10"
publisher: "BroadNet Technologies"
brand: "OmniChannels.ai"
category: "omnichannel"
primaryQuery: "message channel fallback strategy"
keywords: ["短信回退", "WhatsApp 失败回退短信", "RCS 短信回退", "验证码回退", "多渠道消息触达", "回退超时设置", "防止重复发送消息"]
published: "2026-10-10"
author: "OmniChannels.ai Editorial Team"
reviewer: "BroadNet Messaging Solutions Team"
readingMinutes: 12
answer: "渠道回退策略会让每条消息先通过客户偏好的渠道（如 WhatsApp 或 RCS）发送，只有当第一个渠道失败，或在设定时间内未确认送达时，才切换到下一个渠道，通常是短信。请按消息类型定义渠道顺序和超时时间，根据送达状态而不是已读状态触发回退，通过让首次发送过期或撤回来防止重复，并遵守各渠道的授权规则。"
takeaways: ["回退有两种触发条件：发送时立即返回的错误，以及未在超时时间内确认送达；两者都需要处理。", "超时时间应与消息的有效期一致：验证码要短，订单更新可以更长，而大多数营销消息根本不应回退。", "Google 的 RCS 平台可通过消息过期机制自动撤回未送达的消息，从而实现向短信的平滑交接。", "防止重复消息的做法是：记录由哪个渠道送达、让待发送的尝试过期或撤回，并使用唯一的消息 ID。", "链路中的每个渠道都需要各自的合法依据或用户授权（opt-in），因此 WhatsApp 营销消息不能直接回退成短信营销。"]
faq: 
  - q: "什么是短信回退？"
    a: "短信回退是一条规则：当首选渠道（如 WhatsApp 或 RCS）无法送达消息时，改用短信发送。触发条件要么是发送时返回的错误，例如号码无法接收 RCS，要么是迟迟收不到送达确认而触发的超时。短信作为最后一步，是因为它无需应用或数据流量，几乎可以触达所有手机。"
  - q: "回退应该根据“已送达”还是“已读”状态来触发？"
    a: "对时效性强的消息，应根据送达状态触发。无论在 WhatsApp 还是 RCS 上，已读回执都取决于用户的设置，因此消息可能已被阅读，却始终没有收到 READ 事件。等待已读状态会发送不必要的回退消息，造成重复。已读数据仍然适合事后衡量互动情况，但不应作为回退决策的依据。"
  - q: "在回退到短信之前应该等待多久？"
    a: "这取决于消息保持有效的时间。验证码很快就会过期，所以超时时间必须足够短，才能给客户留出使用短信验证码的时间。物流更新可以等得更久，预约提醒可以等得更久。请按使用场景设置超时时间，衡量回退触发的频率以及两个渠道都送达的频率，并根据自己的数据进行调整。"
  - q: "营销消息可以回退到短信吗？"
    a: "只有在客户已同意接收短信营销，并且当地规则允许在该时间发送的情况下才可以。同意接收 WhatsApp 营销并不自动涵盖短信。在海湾市场，营销短信通常还需要已报备的 Sender ID，并且必须遵守允许的发送时段。许多企业干脆不对营销消息做回退，或在已获授权的情况下回退到电子邮件。"
  - q: "如何避免客户收到两次相同的消息？"
    a: "为每条逻辑消息分配一个 ID，记录由哪个渠道送达，一旦确认送达就停止所有其他尝试。在 RCS 上，发送短信前先设置消息过期时间或撤回该消息。在短信上，设置有效期，使延迟的消息被丢弃。当手机较晚上线时，难免会出现一些重复，所以要让消息内容即使收到两次也不会造成问题。"
  - q: "“WhatsApp、RCS、短信”这个顺序总是正确的吗？"
    a: "不是。对于内容丰富的交易类消息，这是一种常见顺序，但正确的顺序取决于你的受众和消息本身。对于关键提醒，许多团队会先发短信，因为它无需数据流量即可工作。对于没有 WhatsApp 账号的客户，先用 WhatsApp 只会增加延迟。请根据你对客户所用渠道的了解，按使用场景和客户来选择顺序。"
sources: 
  - title: "发送消息（消息过期与回退） — RCS for Business, Google for Developers"
    url: "https://developers.google.com/business-communications/rcs-business-messaging/guides/build/messages/send"
  - title: "撤回消息 — RCS for Business, Google for Developers"
    url: "https://developers.google.com/business-communications/rcs-business-messaging/guides/build/messages/revoke"
  - title: "能力检测 — RCS for Business, Google for Developers"
    url: "https://developers.google.com/business-communications/rcs-business-messaging/guides/build/capabilities"
  - title: "获取 WhatsApp 用户授权（opt-in） — Meta for Developers"
    url: "https://developers.facebook.com/docs/whatsapp/overview/getting-opt-in"
  - title: "WhatsApp Business Platform 定价 — Meta for Developers"
    url: "https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing"
  - title: "3GPP TS 23.040：短消息服务（SMS）的技术实现"
    url: "https://www.3gpp.org/dynareport?code=23040"
---

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

Canonical: https://omnichannels.ai/zh/blog/channel-fallback-strategy/
Language: zh
Publisher: OmniChannels.ai by BroadNet Technologies

本指南面向在多个渠道发送重要消息、并希望每位客户都只收到一次的客户体验、CRM 和工程负责人。它介绍如何设计 WhatsApp、RCS 和短信之间的回退：由什么触发、等待多长时间、如何避免重复，以及用户授权在哪些方面限制了你的做法。关于各渠道本身的对比，请参阅 [WhatsApp、短信与 RCS 对比](/blog/whatsapp-vs-sms-vs-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 事件。根据缺失的已读状态来回退，会发送不必要的短信并造成重复。请用已读数据来衡量互动，而不是驱动回退。

| 信号 | 是否作为回退触发条件？ | 原因 |
|---|---|---|
| 发送时出错（不支持、无账号、被拒绝） | 是，立即 | 该渠道无法送达这条消息 |
| 超时时间内没有 DELIVERED 状态 | 是 | 手机很可能离线，或在该渠道上无法联系 |
| 接受后出现 FAILED 状态 | 是，立即 | 送达尝试以失败告终 |
| 已 DELIVERED 但没有 READ | 否 | 已读回执可能被关闭 |
| 客户已回复 | 停止链路 | 已证明送达 |

## 每一步应该等待多久？

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

| 消息类型 | 有效期 | 超时思路 | 典型链路 |
|---|---|---|---|
| 验证码与登录码 | 几分钟 | 非常短；要给客户留出使用下一条验证码的时间 | WhatsApp 验证或 RCS，然后短信 |
| 欺诈与安全提醒 | 几分钟 | 较短；对最关键的消息也可并行发送短信 | 先发短信，或用丰富渠道配合快速短信回退 |
| 订单与物流更新 | 几小时 | 适中；必须在事件发生之前送达 | WhatsApp，然后 RCS，然后短信 |
| 预约提醒 | 直到预约开始 | 较长；在提醒失去意义之前过期 | WhatsApp 或 RCS，然后短信 |
| 营销与优惠 | 直到优惠结束 | 通常不做回退 | 单一渠道，并具备相应授权 |
| 客服回复 | 由客户主导 | 不做回退；在客户所用的渠道回复 | 同一渠道；对话丢失时使用电子邮件 |

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

- **回退时让首次发送过期。** 在 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](https://developers.facebook.com/docs/whatsapp/overview/getting-opt-in)。
- **RCS：** Google 的上线审核会检查你的触达是否符合用户授权，Agent 必须遵守 STOP 及等效关键词。
- **短信：** 受当地电信和数据保护规则约束。在海湾市场，营销短信通常需要已报备的 Sender ID 并遵守允许的发送时段；请向监管机构和服务商确认细节。我们的 [Sender ID 报备指南](/blog/sms-sender-id-registration-uae-saudi/)介绍了阿联酋和沙特的流程。

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

## 回退如何影响成本？

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

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

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

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

你可以在我们的[定价页面](/pricing/)比较各渠道的参考标价。

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

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

[消息 API 集成指南](/blog/messaging-api-integration-guide/)和[送达状态指南](/blog/message-delivery-status-explained/)介绍了 Webhook 方面的内容。

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

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

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

## 回退中有哪些常见错误？

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

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

## OmniChannels.ai 如何提供帮助

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