Estratégia de fallback entre canais: WhatsApp, RCS e SMS

Este guia é para líderes de CX, CRM e engenharia que enviam mensagens importantes por mais de um canal e querem que cada cliente as receba exatamente uma vez. Ele explica como desenhar o fallback entre WhatsApp, RCS e SMS: o que o dispara, quanto tempo esperar, como evitar duplicatas e onde o consentimento limita o que você pode fazer. Para uma comparação entre os próprios canais, veja WhatsApp vs SMS vs RCS.

O que é uma estratégia de fallback entre canais?

Uma estratégia de fallback entre canais é um conjunto de regras que decide qual canal tentar primeiro para cada mensagem, quando desistir dele e qual canal usar em seguida. O objetivo é que o cliente receba a mensagem uma única vez, a tempo, pelo melhor canal disponível para ele.

Todo canal tem lacunas. O WhatsApp só alcança quem tem conta e conexão de dados. O RCS só alcança aparelhos e operadoras que suportam RCS business messaging. O SMS chega a quase todo celular, mas só leva texto simples. O fallback combina os canais para que as lacunas de um sejam cobertas por outro.

Uma cadeia de fallback tem quatro partes:

1. Uma ordem de canais, por exemplo WhatsApp, depois RCS, depois SMS.
2. Gatilhos que passam a mensagem para o próximo canal.
3. Um timeout para cada etapa, baseado em quanto tempo a mensagem continua útil.
4. Regras de parada que encerram a cadeia quando a entrega é confirmada e cancelam o que ainda está pendente.

Como escolher a ordem dos canais?

Escolha a ordem por tipo de mensagem e por cliente, não uma única vez para a empresa inteira. WhatsApp, depois RCS, depois SMS é uma ordem comum para mensagens transacionais ricas, mas nem sempre é a certa.

• Comece por onde o cliente é alcançável. Se seus registros mostram que um número não tem conta de WhatsApp, começar pelo WhatsApp só acrescenta uma tentativa fracassada e atraso. Se uma verificação de capacidade mostra que o número não recebe RCS, pule o RCS.
• Coloque o canal mais confiável primeiro em alertas críticos. Em alertas de fraude ou de segurança, muitas equipes enviam primeiro o SMS, porque funciona sem conexão de dados, e usam um canal rico para o acompanhamento.
• Respeite a preferência declarada pelo cliente. Se o cliente escolheu SMS no cadastro, respeite, mesmo que haja um canal mais rico disponível.
• Mantenha o atendimento no canal do cliente. Respostas a um cliente que escreveu pelo WhatsApp devem ficar no WhatsApp; o fallback serve para mensagens iniciadas pela empresa.
• Revise a ordem por mercado. Nos mercados do GCC, assim como no Brasil, o WhatsApp é amplamente usado para mensagens empresariais, enquanto a cobertura de RCS depende da operadora e do país, então a melhor ordem pode mudar entre, por exemplo, os Emirados Árabes Unidos e a Europa.

O que deve disparar um fallback?

Dois tipos de evento devem disparar o fallback: um erro no envio e a ausência de confirmação de entrega ao fim do timeout. As confirmações de leitura, não.

Erros imediatos

Algumas falhas são conhecidas na hora. No RCS, a documentação do Google informa que a plataforma retorna 404 NOT_FOUND quando o aparelho não suporta RCS, o RCS está desativado ou o seu agente não foi lançado na rede do usuário, e 400 INVALID_ARGUMENT quando a mensagem usa um recurso que o aparelho não consegue exibir. No WhatsApp, um envio pode falhar quando o número não tem conta de WhatsApp ou quando um modelo é rejeitado. Esses casos devem passar ao próximo canal sem espera.

Você evita muitos desses erros verificando antes. A plataforma RBM do Google oferece verificações de capacidade que informam se um número pode receber RCS e quais recursos ele suporta, desde que o número tenha se conectado ao RCS recentemente.

Timeouts

Outras falhas são silenciosas. A mensagem é aceita, mas nenhum status DELIVERED chega, normalmente porque o celular está desligado ou offline. A plataforma RBM do Google mantém mensagens não entregues na fila por até 30 dias, então, sem um timeout, uma mensagem RCS pode chegar muito depois de deixar de importar.

Por que não usar as confirmações de leitura?

As confirmações de leitura dependem das configurações do usuário tanto no WhatsApp quanto no RCS. Um cliente que as desativou pode ler todas as mensagens e nunca enviar um evento READ. Fazer fallback por falta de leitura gera SMS desnecessários e duplicatas. Use os dados de leitura para medir engajamento, não para guiar o fallback.

Quanto tempo cada etapa deve esperar?

Defina o timeout pela vida útil da mensagem: quanto mais curta a vida útil, menor a espera. Não existe um número universal, então comece com um valor fundamentado por caso de uso e ajuste-o com os seus próprios dados de entrega.

Duas regras tornam os timeouts confiáveis:

• Expire a primeira tentativa ao fazer o fallback. No RCS, defina ttl ou expireTime na mensagem. A documentação do Google explica que, quando a mensagem expira sem ser entregue, a plataforma a revoga e notifica o seu webhook, que é o sinal natural para enviar o SMS. Você também pode revogar uma mensagem explicitamente. A Meta também documenta uma configuração de time-to-live para alguns tipos de modelo do WhatsApp; consulte a documentação atual para ver quais categorias a suportam.
• Dê também um período de validade ao SMS. O padrão de SMS (3GPP TS 23.040) permite que o remetente defina um período de validade, depois do qual a rede para de tentar. Um período de validade curto em um OTP impede que o código chegue depois de expirado.

Como evitar mensagens duplicadas?

Trate cada mensagem como uma mensagem lógica com várias entregas possíveis e interrompa a cadeia assim que uma entrega for confirmada. As boas práticas de RBM do Google dizem o mesmo: confirme que a mensagem não foi entregue antes de reenviá-la e use IDs de mensagem únicos.

Checklist de prevenção de duplicatas

1. Atribua um ID por mensagem lógica e registre cada tentativa por canal vinculada a ele.
2. Consulte o registro antes de cada etapa de fallback: se algum canal informou DELIVERED, pare.
3. Expire ou revogue a tentativa pendente antes de enviar pelo próximo canal.
4. Trate a condição de corrida. O Google observa que, raramente, uma revogação pode falhar porque a mensagem está sendo entregue naquele instante. Se a revogação falhar, verifique se chegou um evento DELIVERED antes de enviar o SMS.
5. Crie conteúdo que possa ser recebido duas vezes. Uma mensagem de OTP não deve dar a entender que o primeiro código é inválido, a menos que seja verdade, e duas atualizações de pedido não devem se contradizer.
6. Registre os motivos de fallback para ver se ele é causado por erros, timeouts ou falta de capacidade.

Como consentimento e compliance afetam o fallback?

Cada canal da cadeia precisa da própria permissão. O fallback muda o canal; ele não transfere o consentimento de um canal para outro.

• WhatsApp: a Meta exige opt-in antes de a empresa enviar mensagens ao usuário, e mensagens iniciadas pela empresa fora da janela de atendimento precisam usar modelos aprovados. Veja WhatsApp opt-in na documentação da Meta.
• RCS: a análise de lançamento do Google verifica se a sua comunicação corresponde ao consentimento do usuário, e os agentes precisam respeitar STOP e palavras-chave equivalentes.
• SMS: regido pelas regras locais de telecomunicações e de proteção de dados (no Brasil, por exemplo, pela LGPD). Nos mercados do GCC, o SMS promocional normalmente exige IDs de remetente cadastrados e horários de envio permitidos; confirme os detalhes com o regulador e com seu fornecedor. Nosso guia de cadastro de ID de remetente explica o processo nos Emirados Árabes Unidos e na Arábia Saudita.

É por isso que a maior parte do marketing não deveria ter fallback. Um cliente que aceitou ofertas pelo WhatsApp pode não ter aceitado SMS promocional, e o SMS pode chegar fora do horário permitido. Mensagens transacionais, como OTPs e atualizações de pedido, estão em terreno mais firme, mas precisam continuar puramente transacionais em todos os canais. Centralize os descadastros (opt-outs): um STOP em um canal deve ser verificado antes que qualquer outro canal envie marketing. Nosso guia de consentimento aprofunda o tema.

Como o fallback afeta o custo?

O fallback só gera custo quando é disparado, mas uma cadeia mal ajustada pode pagar duas vezes pela mesma mensagem. Meça o custo por mensagem entregue, não por tentativa.

• WhatsApp: a Meta cobra por modelo entregue, conforme a categoria e o mercado do destinatário. Segundo a documentação de preços da Meta, desde 1º de outubro de 2026 a Meta cobra as mensagens de serviço acima de uma franquia mensal gratuita por número de telefone comercial, e cobra os modelos de utilidade enviados dentro da janela de atendimento ao cliente; confirme na tabela atual da Meta.
• RCS: os preços são definidos por mercados, operadoras e fornecedores e variam entre os tipos de mensagem.
• SMS: cobrado por segmento e por destino. Textos em árabe, e textos em português com caracteres fora do GSM-7, usam Unicode, que comporta menos caracteres por segmento; veja nosso guia de limites de caracteres.

Alavancas de custo que não prejudicam a entrega:

1. Pule os canais que o cliente não usa. Começar pelo WhatsApp com alguém que não tem conta só acrescenta atraso e uma tentativa fracassada.
2. Use verificações de capacidade antes dos envios por RCS.
3. Ajuste os timeouts para que o fallback seja disparado por celulares offline, não por relatórios de entrega lentos.
4. Mantenha o SMS de fallback curto e, sempre que possível, em um único segmento.

Compare as tarifas indicativas de tabela por canal na nossa página de preços.

Como implementar uma cadeia de fallback passo a passo?

1. Liste os tipos de mensagem e atribua a cada um um canal principal, uma cadeia e um timeout.
2. Registre a disponibilidade de canais por cliente: conta de WhatsApp conhecida, capacidade de RCS, número de celular válido, consentimento por canal.
3. Escreva conteúdo equivalente para cada canal, com os dados essenciais em texto simples.
4. Normalize os status de entrega de todos os canais em um único modelo, como enviada, entregue, lida e com falha, para que um único motor de regras possa agir sobre eles.
5. Implemente os gatilhos: fallback imediato em caso de erro, fallback temporizado quando a entrega não é confirmada.
6. Implemente as regras de parada: entrega ou resposta encerram a cadeia; tentativas pendentes são expiradas ou revogadas.
7. Teste os caminhos de falha: um número sem WhatsApp, um celular com RCS desativado, um celular desligado.
8. Monitore semanalmente: taxa de fallback por caso de uso e mercado, motivos, duplicatas e custo por mensagem entregue.

O guia de integração de API de mensagens e o guia de status de entrega tratam do lado dos webhooks.

Exemplo prático: uma varejista de eletrônicos do GCC

A "Najm Electronics" (fictícia) vende online nos Emirados Árabes Unidos, na Arábia Saudita e no Kuwait. Ela envia OTPs no checkout, atualizações de pedido e ofertas semanais.

• OTP no checkout. Clientes que sabidamente têm WhatsApp recebem um modelo de autenticação com botão de copiar código; os demais recebem SMS diretamente. Se o WhatsApp retornar erro, ou se nenhuma entrega for confirmada dentro de um timeout curto, o código é enviado por SMS com um período de validade curto. A página de checkout avisa o cliente de que o código pode chegar por SMS.
• Atualizações de pedido. A cadeia é WhatsApp, depois RCS para aparelhos compatíveis, depois SMS. A mensagem RCS leva um rich card com a ação "Rastrear pedido" e uma expiração definida bem antes da janela de entrega. Quando ela expira sem ser entregue, a plataforma a revoga e o SMS sai com o mesmo link de rastreamento. O sistema registra qual canal entregou, para que ninguém receba as três.
• Ofertas semanais. As ofertas vão apenas pelo WhatsApp, para clientes que aceitaram marketing no WhatsApp. Não há fallback para SMS, porque muitos desses clientes não consentiram com SMS promocional e os horários de envio variam por país.
• Revisão. Depois do primeiro mês, a equipe analisa os motivos de fallback por mercado. Uma proporção alta de erros de RCS em uma operadora mostra que o agente ainda não foi lançado nela, então o RCS é pulado para essa operadora até a cobertura ser confirmada, o que evita uma tentativa desperdiçada em cada mensagem.

Quais são os erros de fallback mais comuns?

• Fazer fallback por falta de confirmação de leitura, enviando duplicatas para quem já leu a primeira mensagem.
• Não expirar a primeira tentativa, fazendo com que a mensagem original chegue atrasada depois do SMS.
• Um único timeout para tudo, longo demais para OTP e curto demais para lembretes.
• Fazer fallback de marketing para SMS sem consentimento para SMS.
• Conteúdo diferente em cada canal, fazendo com que o cliente veja informações conflitantes.
• Começar por canais que o cliente não usa, acrescentando atraso e custo.
• Não medir o fallback, deixando passar despercebidas quedas de operadoras e lacunas de cobertura.

Limites: o comportamento das plataformas, os preços e as regulamentações mudam. Confirme os detalhes atuais na documentação do Google e da Meta e com seu fornecedor. Este é um guia prático, não aconselhamento jurídico.

Como a OmniChannels.ai ajuda

A OmniChannels.ai permite configurar o fallback entre canais por caso de uso, por exemplo WhatsApp, depois RCS, depois SMS. Os status de entrega de todos os canais (SUBMITTED, SENT, DELIVERED, READ, FAILED, REJECTED) chegam em um único formato de webhook, então um único conjunto de regras pode guiar o fallback e os relatórios. A BroadNet Technologies é Meta Business Solution Provider oficial e parceira RBM do Google, e o SMS trafega pela sua conectividade direta com as operadoras. O RCS inclui fallback automático para SMS onde o RCS não está disponível. Desenvolvedores podem começar pela documentação da API de RCS.