O que é Next Best Action (NBA)

Next Best Action (NBA) é uma estratégia de decisão em tempo real que determina, para cada cliente individualmente, qual ação é mais relevante em determinado momento: uma oferta, uma mensagem de suporte, uma recomendação de produto ou simplesmente nenhum contato.

A diferença em relação a abordagens tradicionais é estrutural. Segmentação em massa trata grupos de clientes com o mesmo estímulo; NBA trata cada pessoa como um segmento de um. Um cliente que acabou de usar o app pela terceira vez na semana recebe uma decisão diferente de outro que ficou inativo por 30 dias, mesmo que ambos pertençam ao mesmo segmento demográfico.

O conceito surgiu no marketing direto dos anos 1990, quando empresas de cartão de crédito começaram a usar modelos estatísticos para decidir qual produto oferecer em cada ligação. Com o avanço de machine learning, dados em tempo real e, mais recentemente, IA generativa, o NBA evoluiu de scripts fixos de call center para sistemas de decisão contínua e multicanal.

Como a IA determina a próxima melhor ação

Dados como insumo principal

O motor de NBA consome três camadas de dados: comportamentais (páginas visitadas, produtos clicados, tempo de sessão), transacionais (histórico de compras, pagamentos, reclamações) e contextuais (canal atual, hora do dia, localização, dispositivo). Sem essa combinação, o modelo toma decisões com visão parcial do cliente.

A unificação desses dados em um perfil coeso é pré-requisito técnico. Dados fragmentados em silos, como CRM desatualizado, plataforma de e-commerce separada e dados de app sem conexão, produzem decisões contraditórias e experiências incoerentes.

Modelos de machine learning envolvidos

O NBA geralmente combina mais de um tipo de modelo. Modelos de propensão estimam a probabilidade de um cliente responder a cada ação possível. Modelos de classificação segmentam comportamento recente para ajustar o contexto. Algoritmos de otimização de decisão, como bandit contextual ou programação linear, selecionam a ação que maximiza o objetivo definido (receita, retenção, satisfação) dentro das restrições de negócio.

Nenhum modelo único resolve o problema. A qualidade da NBA depende tanto da acurácia dos modelos individuais quanto da lógica que os combina na camada de decisão.

O papel do motor de decisão

O decisioning engine é o componente que recebe o contexto do cliente, consulta os modelos, aplica as regras de negócio (elegibilidade, frequência de contato, pressão de canal) e seleciona a ação final. Funciona como árbitro entre o que os modelos sugerem e o que as regras permitem.

Essa camada é onde a maioria das implementações falha. Times que configuram apenas regras estáticas, sem feedback dos modelos, obtêm um motor de regras sofisticado — não um sistema de NBA com IA de fato.

Tempo real versus batch

Inferência em tempo real processa o evento no momento em que ele acontece: o cliente abre o app e, em milissegundos, o sistema decide o que exibir. Processamento em batch calcula as ações com antecedência e armazena as decisões para entrega posterior.

Cada abordagem tem custo e complexidade diferentes. Notificações push agendadas e e-mails de ciclo de vida funcionam bem com batch. Personalização de interface, chatbot e atendimento ao vivo exigem latência abaixo de 200ms, o que impõe requisitos de infraestrutura significativamente mais altos.

Principais casos de uso no mercado brasileiro

Varejo e e-commerce

Em vez de exibir um banner de desconto genérico, o sistema identifica que aquele cliente específico pesquisou um produto três vezes sem comprar e está acessando pelo mobile em horário de almoço. A NBA pode decidir mostrar um comparativo de reviews, um alerta de estoque baixo ou simplesmente aguardar, evitando pressão que aumentaria o opt-out.

O ganho não é apenas na conversão imediata. Reduzir o volume de comunicações irrelevantes preserva a permissão de contato a longo prazo, ativo cada vez mais escasso no mercado brasileiro com o avanço da LGPD.

Serviços financeiros

Bancos e fintechs usam NBA para identificar o momento certo de oferecer um produto de crédito, investimento ou seguro, não pelo calendário de campanha, mas pelo momento de vida do cliente. Um cliente que acabou de receber um aumento salarial identificado via transação tem propensão muito diferente do mesmo cliente seis meses antes.

Prevenção de churn é outro caso intenso no setor. Sinais como redução no volume de transações, transferência de saldo para outro banco ou abertura de conta em concorrente acionam decisões proativas antes que o cliente formalize o cancelamento.

Telecomunicações

Operadoras brasileiras enfrentam churn elevado e custo de retenção alto. NBA aplicado a contact center e canais digitais detecta sinais de insatisfação, como queda no uso de dados, reclamações recentes e visitas à página de cancelamento, e aciona a ação correta: oferta de upgrade, contato proativo de atendimento ou ajuste de plano, antes que o cliente ligue para cancelar.

Canais digitais e físicos

NBA não é exclusivo de canais digitais. Em contact centers, o sistema exibe para o atendente a próxima melhor ação sugerida durante a ligação, com base no perfil do cliente em tempo real. Em PDV físico com identificação do cliente (via app ou CPF), o mesmo princípio se aplica à abordagem do vendedor.

Requisitos técnicos e de dados para implementar NBA

Perfil de cliente unificado

Um CDP (Customer Data Platform) ou uma camada de identidade equivalente é o pré-requisito mais citado em implementações de NBA. Sem identidade resolvida, ou seja, o mesmo cliente reconhecido no app, no site, no WhatsApp e no CRM, o modelo toma decisões sobre fragmentos de comportamento, não sobre pessoas reais.

Não é obrigatório ter um CDP enterprise para começar. Mas é obrigatório ter uma fonte de verdade de perfil que seja atualizável em tempo próximo ao real e acessível pelo motor de decisão com baixa latência.

Qualidade dos dados

O princípio garbage in, garbage out é particularmente severo em modelos de decisão. Dados de CRM desatualizados, eventos de comportamento sem timestamp confiável ou histórico transacional com inconsistências produzem modelos que parecem funcionar em validação, mas falham em produção.

Antes de investir em modelos sofisticados, audite a cobertura e a atualidade dos dados disponíveis. Cobertura baixa em atributos críticos, como renda estimada ou frequência de compra, compromete a personalização mesmo com modelos bem construídos.

Infraestrutura de entrega

A decisão de NBA precisa chegar ao canal certo no momento certo. Isso requer APIs REST ou GraphQL para integração com canais digitais, webhooks para eventos em tempo real, conectores com plataformas de e-mail, push, SMS e WhatsApp, e integração bidirecional com o CRM para registrar o que foi entregue e capturar o resultado.

Governança e LGPD

Decisões automatizadas baseadas em dados pessoais são abrangidas pela LGPD, especialmente o artigo 20, que garante ao titular o direito de solicitar revisão de decisões tomadas exclusivamente por meios automatizados. Implementações de NBA precisam documentar as bases legais utilizadas, manter logs auditáveis das decisões e garantir que o cliente possa contestar e entender os critérios aplicados.

Explicabilidade do modelo não é apenas requisito regulatório: é também requisito operacional. Times de negócio precisam entender por que o sistema recomenda determinada ação para ajustar estratégias com confiança.

Benefícios esperados e métricas de avaliação

O benefício mais citado é o aumento da taxa de conversão por interação sem elevar o volume total de contatos. Mensagens mais precisas, não mais mensagens. Na prática, isso também reduz o custo por contato e o desgaste da base: menos opt-outs e menor descadastramento de canais.

Os indicadores-chave para avaliar NBA incluem:

• Uplift de conversão: diferença de taxa de conversão entre o grupo que recebeu a NBA e o grupo de controle com comunicação padrão.
• NPS e CSAT: para verificar se a personalização está melhorando a percepção do cliente, não apenas gerando cliques.
• Taxa de opt-out e descadastramento: indicador de pressão excessiva ou irrelevância.
• Custo por contato efetivo: eficiência do canal comparada ao retorno gerado.
• Customer Lifetime Value (CLV): métrica de longo prazo que captura o efeito acumulado de decisões mais relevantes.

Expectativas precisam ser calibradas. Modelos de propensão exigem volume mínimo de dados históricos para treinar com confiança, geralmente entre três e seis meses para os primeiros resultados estáveis. Ajuste contínuo de estratégias e retreinamento periódico dos modelos fazem parte da operação, não da fase de implantação.

Armadilhas comuns e critérios para avaliar soluções

Confundir NBA com motor de regras

A armadilha mais frequente é construir um sistema de regras condicionais, como “se o cliente tem mais de 60 dias de inatividade, envie e-mail X”, e chamar de NBA. Regras estáticas não aprendem com feedback, não ajustam propensão individualmente e não otimizam entre múltiplas ações concorrentes. São úteis, mas são outra coisa.

Superestimar a IA, subestimar os dados

Investir em plataformas sofisticadas antes de garantir qualidade de dados é o erro mais caro. Um modelo excelente treinado em dados ruins entrega resultados piores do que regras simples aplicadas a dados limpos. O retorno sobre investimento em qualidade de dados é, em geral, maior do que em complexidade de modelo.

Feedback loop é igualmente crítico: o sistema precisa capturar o resultado de cada ação entregue (clicou, converteu, ignorou, cancelou) para retreinar e ajustar continuamente. Sem esse ciclo, o modelo congela no estado do treinamento inicial.

Critérios vendor-neutral para avaliação de plataformas

Ao avaliar soluções de NBA, sejam plataformas especializadas em decisioning, CDPs com módulo de IA ou suítes de marketing cloud, considere os seguintes critérios independente de fornecedor:

• Explicabilidade: o sistema consegue justificar, em linguagem compreensível, por que selecionou determinada ação para determinado cliente?
• Latência: qual é o SLA de resposta da API de decisão em produção, e como o sistema se comporta sob carga elevada?
• Integrações nativas: o sistema conecta com os canais e ferramentas que você já usa, ou exige middleware adicional para cada integração?
• Flexibilidade de regras de negócio: times não-técnicos conseguem ajustar critérios de elegibilidade, frequência e prioridade sem depender de engenharia?
• Capacidade de teste e controle: é possível configurar grupos de controle, testes A/B e experimentos de forma nativa?

Como estruturar um piloto antes de escalar

Comece com um caso de uso de escopo limitado e alto impacto mensurável. Prevenção de churn em telecomunicações, oferta de cross-sell em serviços financeiros para clientes de alto valor ou recuperação de carrinho abandonado em e-commerce são pontos de partida com dados disponíveis e métricas claras.

Defina um grupo de controle desde o início: sem ele, é impossível medir o uplift real do NBA em relação ao que aconteceria sem intervenção. Execute por pelo menos 60 a 90 dias antes de tirar conclusões, para capturar variações de comportamento além do efeito novidade.

Documente as decisões do modelo durante o piloto, audite casos onde a ação selecionada pareceu inadequada e envolva as áreas de negócio no ajuste das regras. A transição de piloto para escala depende menos da tecnologia e mais da capacidade operacional de manter o ciclo de ajuste contínuo funcionando.