A maioria das decisões de CRM não precisa acontecer em milissegundos. Invista em IA em tempo real apenas quando um sinal confiável perde valor antes do próximo processamento, existe uma ação que pode ser executada dentro dessa janela e o benefício incremental provável supera o custo de integração, disponibilidade e controle. Se uma decisão pode esperar algumas horas ou um dia sem mudar o resultado, batch costuma ser mais barato, explicável e fácil de operar.
O erro é comprar velocidade como atributo da plataforma antes de medir o valor da latência. Um evento pode chegar instantaneamente e ainda produzir uma ação inútil porque a identidade não foi resolvida, o estoque está desatualizado, o cliente já recebeu outra mensagem ou a equipe humana só responderá amanhã. Tempo real é uma propriedade ponta a ponta: sinal, decisão, autorização, ação e registro de resultado precisam caber na mesma janela.
Defina o Contrato do Valor da Latência
- Decisão — qual escolha muda: enviar, esperar, suprimir, encaminhar, priorizar ou pedir revisão.
- Janela — quanto tempo existe entre o sinal e a última ação ainda útil.
- Decaimento — quanto valor econômico se perde a cada hora de atraso.
- Estado — quais dados precisam estar atuais para evitar ação errada.
- Elegibilidade — consentimento, frequência, estoque, preço, canal, risco e conflito de jornada.
- Ação — o que o sistema ou uma pessoa consegue realmente executar dentro da janela.
- Fallback — o comportamento seguro quando evento, identidade, modelo ou destino falha.
- Resultado — receita, margem, retenção ou resolução incremental, com comparador.
- Custo — ingestão, processamento, disponibilidade, suporte, observabilidade e revisão humana.
- Owner — quem responde pelo sinal, pela decisão, pela ação e pelo incidente.
A regra central é simples: a tecnologia não deve ser mais rápida que a operação que recebe sua decisão. Se a equipe comercial atende alertas apenas uma vez por dia, recalcular um score a cada segundo não encurta a resposta. Se preço e inventário atualizam em lote, uma recomendação instantânea pode estar errada. O contrato expõe esses limites antes de a empresa comprar uma arquitetura permanente.
Escolha entre batch, sob demanda, streaming e edge
- Batch diário ou intradiário — adequado para expansão de contas, churn com antecedência, planejamento de carteira e jornadas sem forte decaimento horário.
- Sob demanda — recalcula quando um usuário ou operador abre uma tela, evitando processamento contínuo onde a decisão é esporádica.
- Streaming — útil quando um evento recente muda elegibilidade ou prioridade e uma automação pode agir em minutos.
- Edge — reservado para decisões na mesma página ou na próxima interação, com poucos dados, regras duras e fallback imediato.
- Híbrido — mantém perfil, valor e políticas em batch; usa eventos recentes apenas para ajustar uma decisão limitada.
A Adobe documenta batch, streaming e edge como métodos diferentes de avaliar audiências. O ponto útil para o CMO não é escolher o modo mais avançado, mas combinar a janela do caso de uso com a avaliação suportada. A Salesforce também descreve ingestão e análise de dados em streaming e batch. Essas capacidades ampliam opções; não substituem a prova de que minutos adicionais mudam a decisão.
Exemplo: abandono de cotação com estoque e atendimento
Imagine um varejista brasileiro que recebe uma cotação de alto valor e identifica abandono. Em cinco minutos, ainda pode oferecer ajuda sobre entrega, instalação ou pagamento. Mas a ação só é válida se a pessoa estiver identificada, o canal puder ser usado, o item estiver disponível, a margem suportar a opção e não houver atendimento aberto. A decisão pode encaminhar para um especialista, oferecer conteúdo, manter o carrinho, esperar ou suprimir contato.
Compare esse caso com expansão de uma conta B2B. Uso de produto, tickets, renovação e potencial econômico podem ser consolidados durante a noite ou semanalmente, porque o owner não agirá em segundos. Tornar essa decisão streaming adiciona custo sem mudar a execução. O teste deve demonstrar que a velocidade altera comportamento ou resultado — não apenas que o pipeline atualiza mais vezes.
Prove a necessidade em seis semanas
- Semana 1 — escolher uma decisão, um segmento e um resultado econômico.
- Semana 2 — medir a distribuição real entre sinal, decisão, ação e resultado no processo atual.
- Semana 3 — escrever o contrato, elegibilidade, exclusões, fallback e orçamento de latência.
- Semana 4 — simular batch, sob demanda e streaming com eventos históricos e modo sombra.
- Semana 5 — liberar uma ação de baixo risco em uma janela limitada, mantendo comparador.
- Semana 6 — comparar valor incremental, erro, custo, incidentes e carga operacional; decidir simplificar, ampliar ou parar.
O piloto não precisa começar com nova plataforma. Use logs do CRM, analytics, mensageria e atendimento para reconstruir a linha do tempo. Simule o resultado se a decisão chegasse em 5 minutos, 1 hora, 6 horas e 24 horas. Só depois conecte o menor número de fontes e destinos necessário para testar a faixa em que o valor realmente muda.
Calcule custo por decisão útil, não eventos por segundo
O custo cresce com fontes em streaming, identidade em tempo real, picos de volume, baixa latência, disponibilidade 24×7, múltiplos destinos, deduplicação, estado de consentimento, observabilidade, reprocessamento, suporte e revisão humana. Meça custo por decisão elegível executada e por resultado incremental. Uma arquitetura que processa milhões de eventos para produzir poucas ações úteis pode ter custo unitário pior que um lote diário bem desenhado.
- Valor — margem ou receita incremental por ação executada.
- Velocidade — mediana e percentis do sinal à ação, não apenas tempo do modelo.
- Qualidade — elegibilidade, duplicação, estado incorreto, falso positivo e nenhuma ação.
- Confiabilidade — perda de eventos, atraso, indisponibilidade, reprocessamento e fallback.
- Experiência — pressão de contato, opt-out, conflito entre canais e resolução.
- Operação — alertas aceitos, capacidade humana, exceções e horas de suporte.
- Economia — custo total por decisão útil e por resultado incremental.
Responsabilidades para uma decisão que não pode esperar
Marketing define a janela e a ação; CRM governa pressão e conflito de jornadas; dados garante evento, identidade e estado; tecnologia assume integração, disponibilidade e reprocessamento; analytics desenha o comparador; atendimento ou vendas confirma capacidade; finanças valida margem; jurídico e privacidade revisam uso e comunicação; o sponsor decide qual indisponibilidade é aceitável. O perfil de IA generativa do NIST reforça medição e gestão contínuas ao longo do ciclo de vida.
Comece pela decisão, não pelo streaming
Use o loop mínimo de dados em https://makinai.co/insights/pt/cdp-ia-marketing-loop-minimo-dados-clientes-receita, a próxima melhor ação em https://makinai.co/insights/pt/ia-proxima-melhor-acao-crm-personalizacao, o QA de jornadas em https://makinai.co/insights/pt/ia-testar-jornadas-crm-automacoes-quebradas e o loop de expansão em https://makinai.co/insights/pt/ia-expansao-clientes-loop-receita-contas-b2b. A MAKINAI implementa CRM, dados e commerce em https://makinai.co/services/pt/consultoria-crm-ecommerce-commerce. Traga um sinal, a ação atual e a janela em que o valor desaparece; podemos testar se tempo real paga a integração.
Tempo real não corrige evento mal definido, identidade ambígua ou ação sem owner. Métricas de plataforma não provam impacto incremental, e um piloto de seis semanas é um recorte de escopo, não garantia. Requisitos de privacidade, comunicações e decisões automatizadas variam por país e setor; valide-os antes de escalar.