A orquestração de canais entrega uma mensagem lógica através de vários canais por cascata: verifica a capacidade, tenta o canal rico preferido (RCS ou WhatsApp) e recorre ao SMS em caso de ausência de capacidade, falha ou timeout. O encaminhamento equilibra menor custo com melhor experiência, as regras de repetição e timeout delimitam cada salto, e um DLR unificado concilia o estado entre canais.
- Utilizador solicita um códigoLogin, pagamento ou registo
- A sua aplicação chama a API de verificaçãoUma solicitação por código
- A BroadNet entrega o códigoPelo melhor canal disponívelFallback em caso de não entregaSMSWhatsAppVoz
- O utilizador insere o códigoValidado contra o código emitido
- VerificadoAcesso concedido
Porque existe a orquestração
Nenhum canal isolado chega a todos, e cada um tem características de custo, riqueza e entrega diferentes — pelo que uma empresa que quer tanto alcance como experiência tem de usar vários canais para a mesma mensagem lógica. A orquestração omnicanal é a lógica que transforma uma intenção ("informar este cliente de que a encomenda foi expedida") na sequência certa de tentativas de canal para esse destinatário específico: tentar o canal mais rico e com mais marca que o dispositivo pode receber, e recuar através de canais progressivamente mais simples até um entregar. O orquestrador esconde essa complexidade por detrás de um único envio, para que o remetente exprima intenção e política enquanto a plataforma trata da capacidade, do encaminhamento, das repetições e da conciliação.
A cascata: verificação de capacidade e depois fallback
Uma cascata é uma lista ordenada de canais com uma regra para avançar para o seguinte. Começa com uma verificação de capacidade — este dispositivo está acessível por RCS, este utilizador fez opt-in ao WhatsApp — porque enviar para um canal inacessível apenas desperdiça um salto. O orquestrador tenta o primeiro canal elegível e avança para o seguinte perante um gatilho definido: o canal não tem capacidade, o envio é rejeitado, ou a entrega não é confirmada dentro de um timeout. As cascatas comuns são RCS→SMS (rico e com marca primeiro, texto universal como piso), WhatsApp→SMS (canal de aplicação com opt-in primeiro, SMS caso contrário) e RCS→WhatsApp→SMS. O SMS fica quase sempre no fundo por ser o piso universal, sempre acessível.
deliver(order_shipped, +15551234567):
if rcsCapable(msisdn):
send RCS rich card; await DLR up to T_rcs
if delivered: DONE
if whatsappOptedIn(msisdn):
send WhatsApp template; await status up to T_wa
if delivered/read: DONE
send SMS (universal fallback); await DLR up to T_sms
record final status on the unified message idEncaminhamento: menor custo vs melhor experiência
Escolher a ordem da cascata é uma decisão de encaminhamento, e dois objetivos competem entre si. O encaminhamento de menor custo prefere o canal e a rota mais baratos que realizarão a entrega — útil para tráfego de alto volume e baixa urgência, onde uma cobrança de RCS por conversa, uma cobrança de WhatsApp por mensagem ou uma rota SMS mais barata vença. O encaminhamento de melhor experiência prefere o canal mais rico, com mais marca e mais confiável que o destinatário possa receber — útil onde o envolvimento, a marca ou a interatividade importam mais do que o custo unitário. A maioria das políticas combina os dois por classe de mensagem: recibos transacionais podem otimizar para experiência e marca, enquanto notificações em massa focam no custo. O orquestrador aplica a política juntamente com a capacidade e as regras por mercado (registo de ID de remetente, categorias WhatsApp, disponibilidade RCS) para escolher o primeiro salto real.
| Objetivo | Prefere | Ideal para |
|---|---|---|
| Menor custo | Canal/rota apta mais barata | Notificações de alto volume e baixa urgência |
| Melhor experiência | Canal mais rico entre os verificados e aptos | Mensagens de marca, interativas e focadas no envolvimento |
| Foco em confiabilidade | Canal com a mais alta garantia de entrega | OTPs, alertas críticos / urgentes |
| Restrito por conformidade | Somente canais permitidos no mercado | Destinos regulamentados, regras de identificação do remetente |
Repetição, timeout e desduplicação
Cada salto de uma cascata precisa de comportamento delimitado para que toda a entrega seja determinística e nunca cobre o destinatário em duplicado. Um timeout por canal define quanto tempo esperar pela confirmação antes de avançar — longo o suficiente para uma entrega legítima, curto o suficiente para que o fallback ainda chegue de forma útil (um OTP que chega uma hora tarde não vale nada). As repetições dentro de um canal tratam falhas transitórias, mas têm de distinguir uma rejeição permanente (avançar de imediato) de uma transitória (repetir e depois avançar). E como uma mensagem pode ter sido enviada num canal rico enquanto um fallback dispara, o orquestrador desduplica face a um único ID de mensagem lógica, para que o cliente não receba a mesma notificação duas vezes. Chaves de idempotência no envio tornam as repetições seguras.
Relatórios de entrega unificados entre canais
Cada canal reporta a entrega de forma diferente — o SMS devolve um relatório de entrega SS7/SMPP, o WhatsApp publica webhooks sent/delivered/read/failed, o RCS emite eventos de entrega e de leitura — pelo que um envio orquestrado precisa de um DLR unificado que os mapeie a todos num único modelo de estado face ao ID de mensagem lógica. Isso permite a um remetente fazer uma única pergunta, "chegou isto ao cliente, e como", e obter uma resposta que nomeia o canal que acabou por entregar, os canais que foram tentados e ignorados, e o sinal de leitura/envolvimento onde o canal o fornece. A visão unificada é também o que alimenta a análise de encaminhamento — que cascatas entregam, a que custo, em que mercados — fechando o ciclo da política ao resultado.
| Canal | Status nativo | Status unificado |
|---|---|---|
| SMS | Relatório de entrega SMPP / SS7 | enviado / entregue / falhou |
| RCS | Eventos de entrega + leitura | enviado / entregue / lido / falhou |
| webhook enviado / entregue / lido / com falha | enviado / entregue / lido / falhou | |
| Resultado em cascata | (composto) | delivered-via-<channel> / exhausted |
Perguntas frequentes
O que é o fallback de canais?
O fallback de canais entrega uma mensagem lógica tentando os canais por ordem e avançando quando um está indisponível ou não confirma a entrega. Uma cascata típica é RCS→SMS ou WhatsApp→SMS: tentar primeiro o canal rico e com marca, e recorrer ao SMS — o piso universal — em caso de ausência de capacidade, rejeição ou timeout.
Como decide o orquestrador que canal tentar primeiro?
Combina uma verificação de capacidade (o dispositivo está acessível por RCS, o utilizador fez opt-in ao WhatsApp) com uma política de encaminhamento. O encaminhamento por menor custo prefere o canal capaz mais barato; o de melhor experiência prefere o mais rico e verificado; o de fiabilidade em primeiro lugar prefere a entrega garantida. Regras por mercado como o registo de sender ID e as categorias do WhatsApp restringem ainda mais os canais elegíveis.
O que é o encaminhamento por menor custo vs melhor experiência?
O encaminhamento por menor custo escolhe o canal e a rota mais baratos que entreguem, adequado a tráfego de grande volume e baixa urgência. O encaminhamento por melhor experiência escolhe o canal mais rico, com mais marca e mais confiável que o destinatário pode receber, adequado a mensagens orientadas ao envolvimento. A maioria das políticas mistura os dois por classe de mensagem — recibos para experiência, alertas em massa para custo.
Como é que o fallback evita enviar a mesma mensagem duas vezes?
Ligando cada salto a um único ID de mensagem lógica e desduplicando face a ele, com timeouts por canal e chaves de idempotência para que as repetições sejam seguras. Uma rejeição permanente avança de imediato para o canal seguinte; uma falha transitória é repetida antes de avançar. O destinatário vê a notificação uma vez, no canal que acabou por entregar.
Que timeout deve usar cada salto de canal?
Longo o suficiente para permitir um relatório de entrega legítimo, curto o suficiente para que o fallback ainda chegue de forma útil. Uma palavra-passe de utilização única que chega uma hora tarde não vale nada, pelo que os seus timeouts por salto são curtos; uma notificação não urgente pode esperar mais tempo num canal rico antes de recorrer ao SMS.
O que é um DLR unificado?
Um relatório de entrega unificado mapeia o estado nativo de cada canal — relatórios de entrega SMS, webhooks sent/delivered/read/failed do WhatsApp, eventos de entrega e de leitura do RCS — num único modelo de estado face ao ID de mensagem lógica. Permite a um remetente fazer uma única pergunta sobre se e como uma mensagem chegou ao cliente, e alimenta a análise de encaminhamento.
Especificações de origem
Os padrões publicados nos quais esta página se baseia. Abre num novo separador.