Стратегия fallback: резервные каналы WhatsApp, RCS и SMS

Это руководство для руководителей CX и CRM и инженеров, которые отправляют важные сообщения по нескольким каналам и хотят, чтобы каждый клиент получил их ровно один раз. Оно объясняет, как построить fallback между WhatsApp, RCS и SMS: что его запускает, сколько ждать, как избежать дублей и где согласие ограничивает ваши возможности. Сравнение самих каналов смотрите в статье WhatsApp, SMS и RCS: сравнение.

Что такое стратегия резервных каналов?

Стратегия резервных каналов (fallback) — это набор правил, который определяет, какой канал использовать первым для каждого сообщения, когда от него отказаться и какой канал взять следующим. Цель: клиент получает сообщение один раз, вовремя и по лучшему из доступных ему каналов.

У каждого канала есть пробелы. WhatsApp доходит только до людей, у которых есть аккаунт и подключение к интернету. RCS доходит только до устройств и операторов, которые поддерживают RCS-сообщения для бизнеса. SMS доходит почти до любого телефона, но передаёт только простой текст. Fallback объединяет каналы так, что пробелы одного закрываются другим.

Цепочка резервных каналов состоит из четырёх частей:

1. Порядок каналов, например WhatsApp, затем RCS, затем SMS.
2. Триггеры, которые переводят сообщение на следующий канал.
3. Таймаут для каждого шага, исходя из того, как долго сообщение остаётся полезным.
4. Правила остановки, которые завершают цепочку после подтверждения доставки и отменяют всё, что ещё ожидает отправки.

Как выбрать порядок каналов?

Выбирайте порядок для каждого типа сообщений и каждого клиента, а не один раз для всего бизнеса. WhatsApp, затем RCS, затем SMS — распространённый порядок для насыщенных транзакционных сообщений, но он подходит не всегда.

• Начинайте там, где клиента можно достать. Если по вашим данным у номера нет аккаунта WhatsApp, старт с WhatsApp добавит неудачную попытку и задержку. Если проверка возможностей (capability check) показывает, что номер не принимает RCS, пропустите RCS.
• Для критичных уведомлений ставьте первым самый надёжный канал. Для предупреждений о мошенничестве или сообщений о безопасности многие команды отправляют SMS первым, потому что оно работает без передачи данных, а насыщенный канал используют для последующего сообщения.
• Учитывайте заявленное предпочтение клиента. Если клиент выбрал SMS при регистрации, соблюдайте это, даже если доступен более богатый канал.
• Ведите поддержку в канале клиента. Ответы клиенту, который написал в WhatsApp, должны идти в WhatsApp; fallback нужен для сообщений, инициированных бизнесом.
• Пересматривайте порядок по рынкам. В странах Персидского залива (GCC) WhatsApp широко используется для бизнес-коммуникации, а покрытие RCS зависит от оператора и страны, поэтому лучший порядок может отличаться, например, в ОАЭ и в Европе.

Что должно запускать fallback?

Fallback должны запускать два типа событий: ошибка при отправке и отсутствие подтверждения доставки к концу таймаута. Отчёты о прочтении запускать его не должны.

Мгновенные ошибки

Некоторые сбои известны сразу. В RCS, как указано в документации Google, платформа возвращает 404 NOT_FOUND, если устройство не поддерживает RCS, RCS выключен или ваш агент не запущен в сети пользователя, и 400 INVALID_ARGUMENT, если сообщение использует функцию, которую устройство не может показать. В WhatsApp отправка может завершиться ошибкой, если у номера нет аккаунта WhatsApp или шаблон отклонён. В таких случаях сообщение нужно сразу передавать на следующий канал, не дожидаясь таймаута.

Многих таких ошибок можно избежать, проверив номер заранее. Платформа Google RBM предлагает проверки возможностей (capability checks): они показывают, может ли номер получать RCS и какие функции поддерживает, при условии что номер недавно подключался к RCS.

Таймауты

Другие сбои происходят молча. Сообщение принято, но статус DELIVERED не приходит, обычно потому что телефон выключен или не в сети. Платформа Google RBM хранит недоставленные сообщения в очереди до 30 дней, поэтому без таймаута RCS-сообщение может прийти намного позже, чем оно было нужно.

Почему не отчёты о прочтении?

Отчёты о прочтении зависят от настроек пользователя и в WhatsApp, и в RCS. Клиент, который их отключил, может читать каждое сообщение, но событие READ не придёт никогда. Если переходить на резервный канал из-за отсутствия прочтения, будут уходить лишние SMS и появятся дубли. Используйте данные о прочтении, чтобы измерять вовлечённость, а не чтобы управлять fallback.

Сколько должен ждать каждый шаг?

Задавайте таймаут исходя из времени, в течение которого сообщение остаётся полезным: чем короче этот срок, тем короче ожидание. Универсального числа нет, поэтому начните с обоснованного значения для каждого сценария и корректируйте его по собственным данным о доставке.

Два правила делают таймауты надёжными:

• Завершайте первую попытку по сроку, когда переходите на резервный канал. В RCS задайте ttl или expireTime для сообщения. Документация Google поясняет: если сообщение истекает недоставленным, платформа отзывает его и уведомляет ваш webhook, и это естественный сигнал отправить SMS. Сообщение также можно отозвать явно. Meta тоже описывает настройку времени жизни (TTL) для некоторых типов шаблонов WhatsApp; проверьте в актуальной документации, какие категории её поддерживают.
• Задавайте период действия и для SMS. Стандарт SMS (3GPP TS 23.040) позволяет отправителю указать период действия (validity period), по истечении которого сеть прекращает попытки доставки. Короткий период действия для OTP не даст коду прийти после того, как он истёк.

Как предотвратить дубли сообщений?

Считайте каждое сообщение одним логическим сообщением с несколькими возможными доставками и останавливайте цепочку, как только одна доставка подтверждена. Рекомендации Google RBM говорят о том же: убедитесь, что сообщение не было доставлено, прежде чем отправлять его повторно, и используйте уникальные ID сообщений.

Чек-лист защиты от дублей

1. Присваивайте один ID логическому сообщению и записывайте на него каждую попытку в каждом канале.
2. Проверяйте запись перед каждым шагом fallback: если любой канал сообщил DELIVERED, остановитесь.
3. Завершите по сроку или отзовите ожидающую попытку до отправки в следующий канал.
4. Учитывайте состояние гонки. Google отмечает, что в редких случаях отзыв может не сработать, потому что сообщение доставляется именно в этот момент. Если отзыв не удался, проверьте наличие события DELIVERED, прежде чем отправлять SMS.
5. Делайте содержимое безопасным для двойного получения. Сообщение с OTP не должно подразумевать, что первый код недействителен, если это не так, а два уведомления о заказе не должны противоречить друг другу.
6. Фиксируйте причины fallback, чтобы видеть, чем он вызван: ошибками, таймаутами или отсутствием поддержки канала.

Как согласие и требования регуляторов влияют на fallback?

Для каждого канала в цепочке нужно собственное разрешение. Fallback меняет канал, но не переносит согласие с одного канала на другой.

• WhatsApp: Meta требует получить согласие на получение сообщений (opt-in), прежде чем бизнес начнёт отправлять их пользователю, а сообщения по инициативе бизнеса вне окна обслуживания клиента должны использовать утверждённые шаблоны. См. WhatsApp opt-in в документации Meta.
• RCS: проверка Google перед запуском проверяет, что ваши рассылки соответствуют согласию пользователей, а агенты обязаны учитывать STOP и аналогичные ключевые слова.
• SMS: регулируется местными телекоммуникационными правилами и правилами защиты данных. В странах Персидского залива (GCC) для рекламных SMS обычно требуются зарегистрированные имена отправителя (альфа-имена) и соблюдение разрешённых часов отправки; уточняйте детали у регулятора и своего провайдера. Наше руководство по регистрации имени отправителя (альфа-имени) описывает процесс в ОАЭ и Саудовской Аравии.

Поэтому большинству маркетинговых сообщений не нужен fallback. Клиент, согласившийся на предложения в WhatsApp, мог не согласиться на рекламные SMS, а SMS может прийти вне разрешённых часов. Транзакционные сообщения, такие как OTP и уведомления о заказе, находятся в более устойчивой позиции, но во всех каналах они должны оставаться сугубо транзакционными. Держите отписки (opt-out) в центре процесса: STOP в одном канале нужно проверять перед тем, как любой другой канал отправит маркетинговое сообщение. Подробнее — в нашем руководстве по согласию.

Как fallback влияет на стоимость?

Fallback добавляет расходы только тогда, когда срабатывает, но плохо настроенная цепочка может заплатить дважды за одно сообщение. Считайте стоимость доставленного сообщения, а не попытки.

• WhatsApp: Meta берёт плату за каждый доставленный шаблон сообщения в зависимости от категории и рынка получателя. Согласно документации Meta о ценах, с 1 октября 2026 года Meta взимает плату за сервисные сообщения (service) сверх ежемесячного бесплатного лимита на каждый бизнес-номер телефона, а также за служебные шаблоны (utility), отправленные внутри окна обслуживания клиента; уточняйте в актуальном прайс-листе Meta.
• RCS: цены задают рынки, операторы и провайдеры, и они различаются для разных типов сообщений.
• SMS: оплачивается за сегмент в зависимости от направления. Арабский текст использует Unicode, и в сегмент помещается меньше символов; см. наше руководство по ограничениям длины.

Способы снизить расходы без ущерба для доставки:

1. Пропускайте каналы, которыми клиент не может пользоваться. Старт с WhatsApp для человека без аккаунта добавляет задержку и неудачную попытку.
2. Используйте проверки возможностей перед отправкой RCS.
3. Настройте таймауты так, чтобы fallback срабатывал для телефонов вне сети, а не из-за медленных отчётов о доставке (DLR).
4. Делайте резервное SMS коротким и, где возможно, в пределах одного сегмента.

Ориентировочные прайс-листовые цены по каналам сравните на нашей странице с ценами.

Как внедрить цепочку резервных каналов по шагам?

1. Составьте список типов сообщений и для каждого определите основной канал, цепочку и таймаут.
2. Фиксируйте доступность каналов для каждого клиента: известный аккаунт WhatsApp, поддержка RCS, действующий мобильный номер, согласие по каждому каналу.
3. Подготовьте равнозначное содержимое для каждого канала, с ключевыми фактами в обычном тексте.
4. Приведите статусы доставки из всех каналов к единой модели, например sent, delivered, read и failed, чтобы один движок правил мог на них реагировать.
5. Реализуйте триггеры: немедленный fallback при ошибках, fallback по таймеру при отсутствии доставки.
6. Реализуйте правила остановки: доставка или ответ завершает цепочку; ожидающие попытки завершаются по сроку или отзываются.
7. Протестируйте сценарии сбоев: номер без WhatsApp, телефон с отключённым RCS, выключенный телефон.
8. Отслеживайте показатели еженедельно: долю fallback по сценариям и рынкам, причины, дубли и стоимость доставленного сообщения.

Сторону webhook описывают руководство по интеграции API для сообщений и руководство по статусам доставки.

Пример из практики: интернет-магазин электроники в странах Персидского залива

«Najm Electronics» (вымышленный пример) продаёт онлайн в ОАЭ, Саудовской Аравии и Кувейте. Компания отправляет OTP при оформлении заказа, уведомления о заказах и еженедельные предложения.

• OTP при оформлении заказа. Клиенты, про которых известно, что у них есть WhatsApp, получают аутентификационный шаблон (authentication) с кнопкой копирования кода; остальные получают SMS сразу. Если WhatsApp возвращает ошибку или доставка не приходит в течение короткого таймаута, SMS-код отправляется с коротким периодом действия. Страница оформления заказа сообщает клиенту, что код может прийти по SMS.
• Уведомления о заказе. Цепочка: WhatsApp, затем RCS для поддерживаемых устройств, затем SMS. RCS-сообщение содержит насыщенную карточку с действием «Отследить заказ» и сроком действия, который истекает заметно раньше слота доставки. Когда сообщение истекает недоставленным, платформа отзывает его, и SMS уходит с той же ссылкой для отслеживания. Система фиксирует, по какому каналу сообщение доставлено, поэтому никто не получает все три.
• Еженедельные предложения. Предложения идут только в WhatsApp клиентам, которые дали согласие на маркетинг в WhatsApp. SMS-fallback нет: многие из этих клиентов не соглашались на рекламные SMS, а часы отправки различаются по странам.
• Анализ. После первого месяца команда проверяет причины fallback по рынкам. Высокая доля ошибок RCS у одного оператора показывает, что там агент ещё не запущен, поэтому RCS для этого оператора пропускается, пока покрытие не подтверждено. Это экономит лишнюю попытку на каждом сообщении.

Какие ошибки в fallback встречаются чаще всего?

• Переход на резервный канал из-за отсутствия отчётов о прочтении, из-за чего дубли уходят людям, которые прочитали первое сообщение.
• Нет срока действия у первой попытки, поэтому исходное сообщение приходит с опозданием после SMS.
• Один таймаут для всего: слишком длинный для OTP и слишком короткий для напоминаний.
• Перевод маркетинга на SMS без согласия на SMS.
• Разное содержимое в разных каналах, из-за чего клиенты видят противоречивые данные.
• Старт с каналов, которыми клиент не пользуется, что добавляет задержку и расходы.
• Отсутствие измерений fallback, из-за чего сбои операторов и пробелы в покрытии остаются незамеченными.

Ограничения: поведение платформ, цены и регулирование меняются. Проверяйте актуальные сведения в документации Google и Meta и у своего провайдера. Это руководство — практические рекомендации, а не юридическая консультация.

Как помогает OmniChannels.ai

OmniChannels.ai позволяет настроить резервные каналы (fallback) для каждого сценария, например WhatsApp, затем RCS, затем SMS. Статусы доставки из всех каналов (SUBMITTED, SENT, DELIVERED, READ, FAILED, REJECTED) приходят в одном формате webhook, поэтому один набор правил может управлять и fallback, и отчётностью. BroadNet Technologies — официальный Meta Business Solution Provider и партнёр Google RBM, а SMS работают через её прямые подключения к операторам. В RCS есть автоматический переход на SMS там, где RCS недоступен. Разработчики могут начать с документации RCS API.