Dois trabalhos diferentes são chamados de "orquestração", e confundi-los é o que trava projetos multicanal. A orquestração de jornada decide se contatar alguém, quando, por quê e em qual canal: é lógica de negócio. As operações de entrega executam uma decisão já tomada: escolha de remetente e rota, adaptadores, tentativas e failover dentro de um canal. Têm donos, testes e falhas diferentes.
Modele o estado do cliente, não o fluxo por canal
A decisão mais importante é se o sistema mantém um estado canônico do processo — esta fatura está em aberto, este agendamento não confirmado — ou sequências separadas por canal que não sabem umas das outras. Com estado canônico, cada tentativa em cada canal age sobre o mesmo registro, que decide o próximo passo.
Eventos gatilho e sua validade
Eventos ficam obsoletos: a fatura já paga, o agendamento já confirmado. É preciso reler o estado imediatamente antes do envio, não só no momento de agendar, e carregar uma marca de atualidade na solicitação para rejeitar decisões obsoletas.
Regras de elegibilidade avaliadas no momento do envio
Consentimento com evidência recuperável, supressão propagada entre canais e provedores, disponibilidade real do canal, identidade verificada, idioma e fuso horário local, horário silencioso avaliado na hora local, limites de frequência e classe de tráfego: tudo isso é avaliado no momento do envio, não no da inscrição.
Política de decisão: qual canal e por quê
Canal preferido, urgência e prazo, sensibilidade do conteúdo — o SMS comum deve ser tratado como não criptografado em trânsito e visível na tela bloqueada, então n ão deve carregar credenciais nem dados sensíveis —, risco, custo como mais uma entrada da política, e capacidade do canal devem estar escritos em uma tabela por caso de uso.
Idempotência, estado da tentativa e fallback
A deduplicação precisa ocorrer no nível do estado, com uma referência própria salva antes do envio. Cada tentativa precisa de um estado explícito — criada, enviada, status final do provedor, expirada por tempo, substituída —, distinguindo uma falha definitiva de uma simples ausência de confirmação. O fallback deve ser disparado por prazos do próprio processo e por sinais confiáveis (rejeição explícita, destino inválido), tratando com cautela a mera ausência de recibo. Precisa ter um limite de canais e tentativas e um caminho para quando a cadeia se esgota.
Condições de parada, respostas e atribuição
Toda jornada precisa de condições de parada explícitas — resultado alcançado, mudança de estado, opt-out ou reclamação, prazo vencido, limite de frequência, chave de desligamento operacional — checadas no momento do envio. Respostas recebidas e opt-outs devem chegar à máquina de estados e se propagar entre canais. Um único ID de jornada em todas as tentativas, cliques e resultados permite saber o que funcionou, em vez de cada canal reivindicar o crédito.
Onde cada camada vive
Operações de entrega — adaptadores, roteamento, identidade de remetente, tentativas, reconciliação e escalonamento — são a parte que quase nenhuma equipe deveria construir duas vezes. A Flowstates fornece e opera canais e rotas, dá suporte a provedores próprios via BYOV, e suporta implantações híbridas como essa camada gerenciada. A orquestração é mais variável e costuma viver onde já vive o estado canônico do negócio: na própria aplicação, em um CRM ou em um fluxo com suporte da Flowstates.