Se você buscou "outcome-based pricing Agentforce" depois da Dreamforce, é provável que a manchete tenha soado como um sonho: pague só quando o agente resolve, não pela promessa. É uma boa notícia — com uma condição escondida que ninguém coloca no slide. Você só se beneficia do "pague quando resolver" se o seu agente consegue resolver. E resolver, no mundo real, quase nunca acontece dentro de um sistema só. A resposta curta: o outcome-based pricing não elimina o seu risco — ele o transfere do fornecedor para a sua camada de integração.
O que é outcome-based pricing no Agentforce (e por que a condição escondida é a integração)
Outcome-based pricing é o modelo em que você paga pelo resultado entregue — um caso resolvido — e não pelo consumo, pela licença ou pelo número de interações. No Agentforce, isso se traduziu num movimento concreto: cobrar apenas quando o caso é resolvido, não quando o agente devolve o problema para um humano. Para o comprador, parece a transferência perfeita de risco: se o agente não entrega, você não paga. O detalhe que muda tudo é que "resolver" é uma função da sua arquitetura, não do fornecedor. Um caso só "resolve" quando o agente consulta o pedido no e-commerce, checa o estoque no ERP, valida o crédito no financeiro e fecha — sem devolver para o humano. Se a integração não deixa o agente chegar a esses sistemas, o modelo de cobrança bonito não te salva: ele apenas revela, na fatura, onde a sua fundação está faltando.
O giro do Dreamforce: de "o que o agente diz" para "o que ele entrega"
O SiliconANGLE (25/09) resumiu o clima pós-Dreamforce numa frase: a indústria parou de avaliar agente por capacidade ("o que ele sabe dizer") e passou a avaliar por resultado ("o que ele entrega"). E dessa vez veio com prova. A Asymbl mostrou trabalhadores digitais compondo 50% da força de trabalho em 13 funções — com um agente recrutador que contratou cerca de 100 pessoas em 100 dias e um impacto de produtividade que saltou de US$ 5 milhões para US$ 13 milhões em um ano. O Slackbot atingiu 1,5 milhão de usuários ativos mensais desde janeiro, apontado como o produto de adoção mais rápida da história da Salesforce. George Gilbert (theCUBE Research) traduziu o discurso oficial: "a Salesforce juntou as peças pra o cliente não ter que juntar... a gente sai do request-response pro outcome". Os números são reais — e é justamente por serem reais que vale entender a condição que os sustenta.
A pegadinha: você só paga por resolução se o agente RESOLVE
Pay-per-resolution soa como risco zero para o comprador, mas ele carrega uma premissa silenciosa: a de que o agente consegue chegar ao fim. E resolver de verdade quase nunca é uma operação dentro de um único sistema. É uma cadeia: o pedido está no e-commerce, o estoque no ERP, o histórico no CRM, o crédito no financeiro. Um agente que "resolve" é um agente que atravessa essa cadeia inteira e fecha. Se qualquer elo dessa corrente não está conectado, o agente faz o que todo agente mal-integrado faz: começa, tenta, esbarra num dado que não alcança — e dá handoff. O modelo de cobrança premia quem já tem a integração no lugar e cobra caro, em handoff, de quem soltou o agente sobre sistemas desconectados.
O que acontece quando falta integração: o agente abre, esbarra e dá handoff
Repare no resultado perverso de não ter a fundação. O agente abre o caso, executa os primeiros passos, chega ao ponto em que precisaria consultar o estoque no ERP ou validar o crédito no financeiro — e, sem alcance, devolve para o humano. Nesse cenário, você não paga pela resolução (porque ela não aconteceu), mas também não economizou: o humano assumiu do mesmo jeito, só que mais tarde e depois de um retrabalho. O pay-per-resolution, aqui, não te deu economia — te deu uma métrica cara de tudo o que a sua integração não consegue concluir. Pior: enquanto você acha que está "testando o modelo de outcome", está na verdade pagando o custo humano de cada handoff que a arquitetura força.
Há ainda um custo que a fatura de outcome esconde e a operação sente: o handoff não é neutro. Cada caso que o agente começa e devolve gera fila, retrabalho e um cliente que já foi respondido pela metade — e agora precisa ser retomado do zero por um humano que não tem o contexto do que o agente tentou. Some isso ao longo de milhares de casos e você tem um agente "de graça" que, na prática, encareceu o atendimento em vez de baratear. O outcome-based pricing só protege o seu bolso na linha do fornecedor; ele não protege o seu custo humano interno, que é onde o handoff mal-resolvido cobra a conta. Por isso a pergunta certa antes de assinar não é "quanto custa por resolução?", e sim "qual é a taxa de resolução que a minha integração sustenta hoje?".
Condição 1 — Integração cross-system: CRM ↔ ERP ↔ e-commerce ↔ financeiro
A primeira condição para o outcome-based pricing virar economia é o alcance ponta-a-ponta. O agente precisa chegar, de forma governada, aos sistemas onde a resolução realmente acontece: o CRM que tem o cliente, o ERP que tem o estoque e a ordem, o e-commerce que tem o pedido, o financeiro que tem o crédito. Isso é integração cross-system — adaptadores, contratos de API, arquitetura orientada a eventos com MuleSoft e barramentos como Kafka/RabbitMQ — não um conjunto de telas que o agente "vê" e não consegue operar. Sem esse alcance, a resolução ponta-a-ponta é uma promessa; com ele, o agente consegue fechar o caso sem devolver para o humano, que é a única forma de o "pague quando resolve" funcionar a seu favor.
Condição 2 — Data 360 governado: o agente decide sobre dado que bate
A segunda condição é o dado governado. Um agente que resolve precisa decidir sobre informação confiável — não sobre um cliente duplicado em três sistemas, um estoque que diverge entre ERP e e-commerce, um status de pedido desatualizado. O Data 360 (a base de dado unificado e governado) é o que dá ao agente um retrato único e correto para agir. A própria Salesforce reconhece isso ao posicionar o Enterprise AI Harness = Data 360 + MuleSoft + Agentforce como fundação composable: a promessa de outcome vem amarrada à base de dado e integração. Traduzindo: o agente não resolve sobre dado sujo; ele resolve sobre dado que bate entre os sistemas — e garantir que ele bata é trabalho de fundação, feito antes de ligar a cobrança por resultado.
Condição 3 — Observabilidade: você só cobra por outcome se consegue MEDIR o outcome
A terceira condição é a medição. Outcome-based pricing pressupõe que existe um "outcome" mensurável e auditável — e não a palavra do agente de que resolveu. Sem observabilidade, você não tem como saber se o caso realmente fechou, se fechou certo, ou se o agente "resolveu" empurrando o problema para outro lugar. É preciso instrumentar cada passo: o que o agente tocou, em qual sistema, com qual resultado, e se o cliente voltou com o mesmo problema depois. Essa é a diferença entre pagar por resultado e pagar por uma alegação de resultado. Medir o outcome de verdade exige dado governado e telemetria — a mesma fundação que faz o agente resolver é a que faz você conseguir comprovar que ele resolveu.
Como a CCX prepara a fundação antes do pay-per-resolution
Antes de apostar no "pague quando resolver" do Agentforce, garanta que o agente CONSEGUE resolver. É isso que a CCX monta. Com Salesforce Commerce Cloud & Data Cloud, estruturamos o Data 360 governado sobre o qual o agente decide e o outcome é medido. Com Integrações & APIs Enterprise e MuleSoft, ligamos o alcance cross-system — CRM ↔ ERP ↔ e-commerce ↔ financeiro — que permite ao agente concluir ponta-a-ponta em vez de dar handoff. E com Data & BI, instrumentamos a medição do outcome, para você cobrar (ou ser cobrado) por resultado que dá para comprovar. O pay-per-resolution só é economia para quem já tem a fundação; para quem soltou o agente sobre sistema desconectado, vira handoff caro e resolução que não acontece. Falar com especialista Salesforce →
Perguntas frequentes (FAQ)
Como o Agentforce cobra?
No modelo de outcome-based pricing, a cobrança acontece por resultado entregue — um caso resolvido — e não por licença ou consumo. O ponto de virada anunciado é cobrar apenas quando o caso resolve, não quando o agente devolve o problema para um humano (handoff). Na prática, isso significa que a economia depende da taxa de resolução do agente, que por sua vez depende da sua integração e do seu dado.
O que é outcome-based pricing?
É o modelo de precificação em que o fornecedor é pago pelo resultado obtido, não pelo esforço ou pelo consumo. Ele transfere o risco de desempenho do comprador para o fornecedor — mas, no caso de agentes de IA, transfere de volta para a camada de integração do comprador: você só colhe a economia se a sua arquitetura permite ao agente concluir o trabalho.
Por que meu agente Salesforce dá handoff?
Quase sempre porque ele esbarra num dado ou numa ação que não alcança: precisa consultar o estoque no ERP, validar crédito no financeiro ou cruzar um histórico que está em outro sistema, e a integração não expõe esse caminho de forma governada. O agente então faz o que foi desenhado para fazer quando não consegue concluir: devolve para o humano. A solução é integração cross-system e dado unificado, não um prompt melhor.
Como medir o resultado de um agente de IA?
Com observabilidade fim-a-fim: instrumentar cada ação do agente, o sistema tocado, o resultado e a reincidência (o cliente voltou com o mesmo problema?). Isso exige dado governado e telemetria. Sem medição, "resolveu" é uma alegação; com medição, é um outcome auditável — que é a base para cobrar ou ser cobrado por resultado.
Vale a pena adotar pay-per-resolution no Agentforce?
Vale — mas o retorno depende da sua fundação, não do modelo de cobrança em si. Se a sua integração já permite ao agente concluir casos ponta-a-ponta e o seu dado é governado, o outcome-based pricing alinha o custo ao valor e tende a ser vantajoso. Se o agente ainda dá handoff em boa parte dos casos por falta de alcance ou por dado inconsistente, você paga pouco em licença de resolução, mas continua pagando caro em custo humano de retrabalho. O passo anterior à decisão de precificação é diagnosticar a taxa de resolução real e onde a integração para.
Outcome não é o que o agente promete; é o que a integração deixa ele concluir. Antes de ligar o "pague quando resolve", ligue a fundação que faz o agente resolver. Preparar a fundação com a CCX →