Agentforce e a virada para o pay-per-resolution: a Salesforce finalmente colocou o preço onde sempre esteve a promessa

A Salesforce acaba de dar um passo importante na forma como vende Agentforce. E, na minha visão, esse movimento é maior do que uma simples mudança de tabela de preço.

O anúncio do Agentforce Help Agent com modelo pay-per-resolution muda a conversa porque desloca o centro da cobrança. Sai um pouco a lógica de “quanto o agente conversou”, “quantas ações ele executou” ou “quantos créditos ele consumiu”, e entra uma pergunta muito mais direta:

O problema do cliente foi resolvido?

Essa pergunta parece simples, mas para quem já implementou Salesforce de verdade sabe que ela carrega um mundo inteiro por trás. Resolver um caso não é apenas responder uma pergunta. Resolver significa entender contexto, buscar dados corretos, aplicar regra de negócio, executar uma ação quando necessário, respeitar segurança, transferir com contexto se precisar de humano e, principalmente, não criar mais bagunça no processo.

Por isso eu vejo essa mudança como uma virada relevante. Não apenas comercial. Arquitetural também.

O que a Salesforce anunciou

A Salesforce anunciou o Agentforce Help Agent, um agente de atendimento pré-configurado, desenhado para ser colocado em operação de forma mais rápida em canais como portal, web, mensagens e voz.

A proposta é reduzir a fricção inicial. Em vez de a empresa começar do zero, conectando conhecimento, desenhando todos os tópicos, criando ações e configurando cada canal manualmente, o Help Agent já vem com uma base mais pronta para atendimento. Ele pode ser fundamentado em Salesforce Knowledge, usar arquivos adicionais, rastrear uma URL e acionar fluxos reais, como gerenciamento de casos, agendamento e atualização de pedidos.

A parte mais chamativa, porém, está no preço: com o novo modelo, a empresa paga quando o agente resolve o problema autonomamente, de ponta a ponta.

Se o cliente pede um humano, se o problema é escalado ou se o usuário sinaliza que não ficou satisfeito, aquela interação não entra como resolução cobrada. A Salesforce posiciona isso como uma cobrança por resultado, não por atividade.

E aqui está a grande diferença.

O modelo antigo de “US$ 2 por conversa” era fácil de explicar, mas difícil de defender em alguns cenários. Uma conversa pode ser curta e valiosa. Pode ser longa e inútil. Pode conter uma pergunta simples, uma frustração enorme ou uma sequência de tentativas que não gera valor algum. Cobrar por conversa simplificava o discurso, mas não resolvia a principal dúvida do cliente: “vou pagar mesmo quando a IA não resolver nada?”

Com o pay-per-resolution, a Salesforce tenta responder essa objeção de frente.

De conversa para ação, de ação para resultado

Para entender a mudança, vale olhar a evolução recente do pricing do Agentforce.

Primeiro veio a cobrança por conversa. Era uma forma direta de comunicar valor: cada interação do cliente com um agente custaria um valor fixo. O problema é que conversa não é sinônimo de valor. Uma conversa pode terminar em escalonamento, frustração ou retrabalho.

Depois vieram os Flex Credits, que aproximaram a cobrança da execução. A ideia era cobrar pelas ações que o agente realiza: atualizar registro, executar automação, consultar dados, gerar resumo, acionar processos. Esse modelo é mais granular e faz sentido para muitos cenários internos e corporativos, especialmente quando estamos falando de automações espalhadas por Sales Cloud, Service Cloud, Data Cloud, Revenue Cloud, Slack e integrações.

Mas ele ainda tem um problema: para o cliente, estimar consumo de crédito pode ser quase tão difícil quanto estimar uso de API, storage, Data Cloud credits ou qualquer outro modelo baseado em consumo.

Agora, com pay-per-resolution, a Salesforce tenta se aproximar da linguagem do negócio.

Não é “quantos tokens foram gastos”.

Não é “quantas ações foram executadas”.

Não é “quantas conversas aconteceram”.

É: quantos problemas foram resolvidos sem intervenção humana?

Essa é a métrica que um diretor de atendimento entende. É a métrica que conversa com deflection, redução de volume, produtividade do time, SLA e custo por caso. E é aí que a Salesforce acerta no posicionamento.

Minha visão: isso é bom, mas não é mágico

Eu gosto da mudança porque ela força o fornecedor a compartilhar parte do risco. Se a IA não resolve, o cliente não deveria pagar como se tivesse resolvido. Esse alinhamento é saudável.

Mas tem uma armadilha perigosa: achar que o modelo de preço corrige um projeto mal desenhado.

Não corrige.

Um agente só resolve bem quando existe uma base minimamente madura por trás. Isso inclui Knowledge bem estruturado, dados confiáveis, processos claros, boas permissões, integrações estáveis e uma taxonomia decente de casos. Se a empresa tem artigos duplicados, políticas contraditórias, campos sem padrão, fila de atendimento bagunçada e automações frágeis, o agente não vai fazer milagre. Ele vai apenas expor a bagunça mais rápido.

Esse ponto é essencial: Agentforce não elimina arquitetura. Ele aumenta a importância dela.

Antes, um processo ruim ficava escondido atrás de um agente humano experiente, que sabia contornar exceções. Agora, quando você coloca um agente autônomo no meio, o sistema precisa estar muito mais explícito. A regra de negócio precisa estar modelada. O dado precisa estar confiável. O caminho de exceção precisa existir.

É aqui que o papel do arquiteto Salesforce cresce, não diminui.

O que muda para projetos Salesforce

Na prática, esse novo modelo deve mudar o discovery de projetos com Agentforce.

Até pouco tempo, muita conversa sobre IA começava pela pergunta errada: “qual agente vamos criar?”

Agora, a pergunta certa passa a ser:

Quais resoluções queremos automatizar?

Essa mudança parece pequena, mas muda tudo.

Em um projeto sério, eu começaria olhando para:

• Top motivos de contato: quais perguntas ou problemas mais aparecem?
• Taxa atual de resolução: quantos casos são resolvidos no primeiro contato?
• Custo por caso humano: quanto custa resolver isso hoje?
• Complexidade por categoria: quais casos são simples, médios ou complexos?
• Risco de automação: quais respostas podem gerar impacto financeiro, jurídico ou operacional?
• Qualidade do Knowledge: o conteúdo está pronto para ser usado por um agente?
• Ações necessárias: o agente só responde ou também precisa alterar pedidos, abrir casos, atualizar conta, reagendar visita, consultar contrato ou interagir com sistemas externos?

Esse tipo de análise deixa o projeto menos “demo bonito” e mais projeto de CRM de verdade.

Porque, no fim, uma resolução automatizada não nasce no prompt. Ela nasce no desenho correto do processo.

A definição de “resolução” vira ponto contratual

Esse é talvez o ponto mais importante para empresas e consultores.

Quando a cobrança depende da resolução, a definição de resolução passa a ser crítica.

O que conta como resolvido? O cliente precisa clicar em algo? Basta não pedir humano? Existe pesquisa de satisfação? E se o cliente abandona a conversa? E se o agente dá a resposta certa, mas o cliente não entende? E se resolve parcialmente? E se o mesmo cliente abre outro caso sobre o mesmo assunto dez minutos depois?

Essas perguntas não são detalhe. Elas afetam custo, ROI e governança.

Em projetos enterprise, eu não deixaria isso solto. Colocaria no desenho da solução e também na conversa comercial:

• qual evento marca uma resolução;
• como o feedback negativo será capturado;
• quando uma interação vira escalonamento;
• como evitar dupla contagem;
• como auditar as resoluções;
• como comparar resolução automatizada com resolução humana;
• como medir CSAT, não apenas deflection.

Porque existe um risco real de a empresa comemorar redução de volume humano e, ao mesmo tempo, piorar a experiência do cliente. Deflection sozinho é uma métrica perigosa. O objetivo não é esconder o humano. O objetivo é resolver melhor.

Por que a Salesforce fez isso agora?

Minha leitura é que a Salesforce percebeu três coisas.

A primeira: o mercado ainda está aprendendo a comprar agentes de IA. O modelo tradicional por usuário não encaixa perfeitamente quando o “usuário” é um agente autônomo trabalhando 24/7. Ao mesmo tempo, modelos puramente baseados em consumo assustam o comprador, porque podem parecer uma conta aberta.

A segunda: havia ansiedade real sobre previsibilidade. Empresas querem inovar, mas não querem tomar susto no fechamento do mês. Especialmente em mercados como América Latina, onde câmbio, orçamento anual e aprovação de compra pesam muito mais. Um modelo baseado em resolução é mais fácil de defender porque conecta gasto a resultado.

A terceira: a Salesforce está respondendo ao mercado. Empresas como Fin, Zendesk e Sierra ajudaram a empurrar a conversa para outcome-based pricing. Não é coincidência que a Salesforce tenha anunciado esse movimento pouco depois de assinar o acordo para adquirir a Fin. O mercado de atendimento com IA está indo para uma direção clara: pagar menos pela promessa e mais pelo resultado entregue.

E isso coloca pressão na própria Salesforce.

Quando ela cobra por resolução, ela está dizendo: “eu confio que meu agente resolve”. Esse é um posicionamento forte. Mas também é uma responsabilidade grande.

O impacto para Revenue Cloud e modelos de monetização

O ponto que mais me chama atenção, olhando com cabeça de Revenue Cloud, é que a Salesforce está vivendo no próprio produto um dilema que muitos clientes também vivem: como monetizar valor em um mundo de uso variável, automação e IA?

Durante muitos anos, SaaS foi basicamente assento, edição e add-on. Você comprava usuário, pacote, módulo, licença. Esse mundo não acabou, mas ficou incompleto.

Com agentes, o valor não vem apenas de acesso. Vem de trabalho realizado.

Isso muda pricing, packaging, billing, forecasting e até customer success.

Uma empresa que cobra por resolução precisa saber medir resolução. Precisa auditar consumo. Precisa explicar a fatura. Precisa tratar disputa. Precisa prever volume. Precisa separar o que foi tentativa do que foi entrega. Precisa transformar telemetria operacional em métrica comercial.

Isso é Revenue Cloud na veia.

Não basta ter um produto inteligente. Você precisa ter um modelo comercial inteligente o suficiente para capturar o valor sem destruir a confiança do cliente.

Por isso, eu vejo essa mudança da Salesforce como um sinal do que vem para muitos setores: software deixando de ser vendido apenas como acesso e passando a ser vendido como capacidade operacional.

O que eu recomendaria para quem está avaliando Agentforce

Eu não começaria comprando o sonho inteiro.

Começaria por um recorte muito claro: uma categoria de atendimento com volume alto, baixa ambiguidade, Knowledge confiável e ação bem definida.

Por exemplo:

• segunda via de informação ou documento;
• status de pedido;
• agendamento ou reagendamento simples;
• dúvidas recorrentes de produto;
• abertura de caso com classificação correta;
• consulta de contrato, plano ou elegibilidade;
• atualização simples de dados, com validações.

Depois disso, eu mediria o básico:

• quantas interações foram iniciadas;
• quantas foram resolvidas sem humano;
• quantas foram escaladas;
• quantas tiveram feedback negativo;
• quanto tempo o humano economizou;
• qual foi o impacto em CSAT;
• qual foi o custo por resolução comparado ao atendimento tradicional.

Essa é a conversa que faz sentido. Não adianta implementar Agentforce apenas para dizer que tem IA. O mercado já passou dessa fase. Agora a pergunta é outra: resolveu, economizou, melhorou a experiência e manteve governança?

O lado bom e o lado que exige cuidado

O lado bom é claro: pagar por resolução aproxima custo e valor. Também reduz o medo de pagar por interações inúteis. Para empresas que ainda estavam desconfiadas do modelo por conversa ou por crédito, isso pode destravar pilotos e projetos reais.

Mas o cuidado também é claro.

O cliente precisa entender exatamente o que está comprando. Pay-per-resolution soa simples, mas a simplicidade comercial depende de uma definição operacional muito bem feita. Sem isso, a discussão muda de “quantos créditos consumimos?” para “isso contou como resolução ou não?”

Ou seja: a complexidade não desaparece. Ela muda de lugar.

Antes, a complexidade estava no consumo. Agora, ela pode estar na medição do resultado.

Conclusão: a cobrança por resolução é o caminho certo, mas só funciona com arquitetura séria

Eu vejo essa mudança como positiva. A Salesforce está tentando alinhar o preço do Agentforce com o que o cliente realmente quer: problema resolvido.

Mas eu não compraria esse anúncio como se fosse uma bala de prata. A cobrança por resolução é um modelo melhor, não uma desculpa para ignorar fundamentos.

Agentforce precisa de dados bons. Precisa de Knowledge bem cuidado. Precisa de processos claros. Precisa de integração. Precisa de segurança. Precisa de monitoramento. Precisa de um arquiteto pensando no ciclo inteiro, não apenas em uma demo bonita.

A grande mensagem para mim é esta:

A Salesforce colocou o preço mais perto do valor. Agora as empresas precisam colocar seus processos mais perto da realidade.

Porque no fim das contas, o futuro do Agentforce não será decidido por quantas conversas ele consegue iniciar.

Será decidido por quantos problemas ele consegue resolver — com confiança, contexto e governança.