Você acabou de fechar o orçamento de suporte para o próximo ano fiscal. Headcount definido, licenças de CRM contratadas, ferramenta de help desk paga. Linha fixa, previsível, defensável no board. Aí a Salesforce anuncia que o Agentforce Help Agent — o agente autônomo que resolve tickets sem intervenção humana — não custa uma assinatura mensal fixa. Custa por resolução. US$ 2 cada conversa que o agente conclui com sucesso. E de repente uma linha que era fixa há uma década vira variável.
Essa mudança parece pequena. É contabilidade, não estratégia — ou assim parece. Mas quem já operou uma máquina de receita sabe que o modelo de cobrança de uma ferramenta molda o comportamento da operação inteira. Quando o custo de suporte deixa de ser um número que você paga independentemente do volume e passa a ser um número que cresce com cada ticket resolvido, você não comprou uma ferramenta. Você comprou uma nova mecânica de unit economics — e a maioria das operações não está preparada para geri-la.
O que exatamente a Salesforce mudou
Historicamente, software de suporte cobrou por assento. Você paga por agente humano que usa a ferramenta, e o preço não muda se aquele agente resolve 10 ou 100 tickets por dia. O custo é do lugar na plataforma, não do trabalho feito. Esse modelo tem uma virtude enorme para quem faz orçamento: previsibilidade. Você sabe exatamente quanto vai gastar antes do ano começar.
Com o Agentforce Help Agent, a Salesforce introduziu no mercado enterprise o modelo de pay-per-conversation — cobrança por conversa resolvida pelo agente de IA, com o valor de referência amplamente divulgado de US$ 2 por conversa. A lógica é honesta na superfície: você não paga por um assento que talvez fique ocioso. Você paga pelo trabalho que a IA efetivamente entregou. Se o agente resolveu, você paga. Se não resolveu e escalou para um humano, teoricamente você não paga aquela conversa.
É o que se chama de outcome-based pricing — cobrança por resultado, não por acesso. E não é um capricho da Salesforce. É a resposta natural de toda a indústria de software a uma pergunta que os compradores começaram a fazer com força: se a IA substitui trabalho humano, por que eu deveria pagar por assento se não tem mais ninguém sentado ali?
Por que pay-per-outcome é sedutor — e o que o mercado diz
Vamos ser justos com o modelo antes de criticá-lo. Cobrar por resolução tem um apelo genuíno, e não é marketing barato. Há razões estruturais pelas quais compradores e fornecedores estão migrando para cá.
- Alinhamento de incentivo aparente. Você só paga quando o problema foi resolvido. Se o agente falha, você não paga aquela falha. Na teoria, o fornecedor tem interesse em fazer o agente funcionar bem, porque a receita dele depende disso.
- Elimina o desperdício de licença ociosa. Quantos assentos de help desk sua empresa paga hoje que ficam subutilizados em meses de baixa demanda? O modelo variável promete cortar esse desperdício.
- Entrada mais barata. Uma operação pequena pode começar a usar o agente sem comprometer um contrato anual pesado. Paga conforme usa. Isso democratiza o acesso à IA de suporte.
- Escalabilidade sem contratação. Um pico sazonal de tickets — Black Friday, lançamento de produto — não exige contratar e demitir gente. O custo sobe e desce com a demanda.
O mercado enxerga isso como a evolução inevitável. Analistas como Gartner e Forrester vêm sinalizando há um tempo que o software está migrando de licenciamento por usuário para modelos baseados em consumo e em resultado, à medida que a IA agente assume tarefas que antes exigiam pessoas. A lógica é: se o valor entregue não está mais no acesso à ferramenta, mas no trabalho autônomo que ela executa, faz sentido cobrar pelo trabalho.
Nós mesmos já defendemos aqui no portal que a conta correta de um agente de IA não é comparar assinatura com salário — é calcular o custo por resolução real, a unit economics que sobrevive ao CFO. O modelo pay-per-resolution parece, à primeira vista, resolver essa conta para você: a própria cobrança já é o custo por resolução. Não precisa mais estimar. Está no invoice.
Mas é exatamente aí que mora o problema. Quando o fornecedor decide o que conta como resolução e você paga por cada uma, a métrica mais importante da sua operação de suporte deixa de ser sua e passa a ser dele.
A verdade incômoda: o incentivo se inverte
Aqui está o ponto que quase nenhum material de vendas menciona. No modelo por resolução, o fornecedor lucra mais quanto mais o agente "resolve" — não quanto melhor ele resolve. E esses dois objetivos parecem iguais, mas não são.
Pense no que acontece quando a receita do fornecedor é uma função direta do número de conversas marcadas como resolvidas. O sistema tem um incentivo estrutural para:
- Marcar como "resolvida" uma conversa em que o cliente simplesmente desistiu e foi embora sem resposta.
- Contar como resolução um caso que na verdade só empurrou o problema para frente — o cliente vai voltar amanhã com o mesmo assunto, gerando outra conversa cobrável.
- Preferir resolver muitas conversas superficiais a resolver poucas conversas profundas.
Um agente que resolve mal, mas resolve muito, é mais lucrativo para o fornecedor do que um agente que resolve bem, mas resolve pouco. O modelo de cobrança não pune a má resolução — em muitos casos, ela vira duas resoluções cobradas.
Esse é o mesmo tipo de armadilha de incentivo que já discutimos ao falar de quem audita o agente quando a IA age sozinha. Quando um sistema autônomo toma decisões que geram receita para quem o vende, você precisa de uma trilha independente que prove o que aconteceu de fato — não pode confiar cegamente no relatório de quem cobra por aquele resultado.
Não estou afirmando que a Salesforce fará isso deliberadamente. O ponto é estrutural, não moral: quando você não controla a definição da métrica pela qual paga, você delegou o controle do seu custo a um terceiro cujo interesse não é idêntico ao seu. E delegar isso silenciosamente é o tipo de decisão que só cobra o preço meses depois, quando a fatura chega maior do que a operação justifica.
Os três riscos que o modelo variável introduz
Vamos organizar os riscos concretos que aparecem quando o suporte migra de linha fixa para linha variável. Não são hipóteses distantes — são coisas que qualquer operação que adote esse modelo vai encontrar.
Risco 1: o custo perde o teto
Custo fixo tem uma virtude subestimada: ele é um teto. Você sabe que, aconteça o que acontecer com o volume, sua fatura não passa daquele número. No modelo variável, o teto some. Um pico inesperado de tickets — uma falha de produto, uma mudança de política que gera confusão em massa, um bug que dispara reclamações — vira uma explosão de custo no exato momento em que sua operação está sob pressão.
Pior: o incentivo interno se distorce. Se cada ticket resolvido pelo agente custa dinheiro, alguém na sua operação vai começar a se perguntar se não seria melhor não deixar o agente resolver certos casos — mesmo quando ele resolveria bem — só para conter a fatura. Você criou um atrito entre "resolver o cliente" e "controlar o custo" que antes não existia.
Risco 2: o deflection deixa de ser gratuito
Boa parte do valor de um bom sistema de autoatendimento está no deflection — evitar que o ticket sequer chegue a um agente, humano ou de IA. Uma boa base de conhecimento, um bom portal de autoatendimento de tickets, um FAQ bem construído resolvem o problema do cliente antes de virar conversa.
No modelo por resolução, você precisa ser cuidadoso: cada conversa que o agente pega e resolve é cobrada, mesmo que aquela dúvida pudesse ter sido resolvida por um artigo de ajuda de graça. Se você não investir na camada de deflection barato, o agente pago vira o primeiro recurso em vez do último — e você paga US$ 2 por perguntas que uma página estática responderia por zero. O modelo variável recompensa quem tem uma boa camada de autoatendimento antes do agente, e pune quem joga todo o volume direto no agente pago.
Risco 3: a previsibilidade orçamentária evapora
Todo o trabalho de forecast que discutimos como disciplina séria depende de conseguir projetar números com credibilidade. Custo fixo é trivial de projetar. Custo variável atrelado a volume de tickets exige que você preveja o volume de tickets — que depende de qualidade de produto, sazonalidade, base instalada crescendo, mix de clientes. É muito mais difícil de acertar. Você troca previsibilidade por flexibilidade, e nem sempre esse é um bom negócio quando o board quer números firmes.
O buraco na definição de "resolução"
Este é o ponto técnico mais importante do contrato, e o que menos gente lê com atenção. O que, exatamente, conta como uma resolução cobrável? Antes de assinar qualquer coisa, você precisa arrancar essa definição em detalhe, porque ela é o preço unitário do seu suporte inteiro.
Perguntas que precisam de resposta contratual clara, não de resposta de vendedor:
- Uma conversa em que o cliente abandonou no meio, sem sinal de que o problema foi resolvido, conta como resolução?
- Se o agente entrega uma resposta e o cliente volta em 5 minutos com o mesmo assunto, isso é uma conversa ou duas cobranças?
- Uma conversa que o agente começa e depois escala para humano é cobrada? E se ele escala só depois de várias trocas de mensagens?
- Uma resposta que o cliente marca como "não resolveu meu problema" ainda é cobrada?
- Existe janela de tempo — perguntas do mesmo cliente sobre o mesmo tópico dentro de X horas contam como uma só?
Essa é, no fundo, a mesma disciplina que aplicamos aos KPIs de mensageria que ligam canal à receita: uma métrica sem definição operacional rigorosa é uma métrica que pode ser inflada. E quando a definição vaga é a base do seu invoice, a ambiguidade não é neutra — ela tende a favorecer quem cobra.
A tabela abaixo organiza o que você deveria exigir que fique explícito no contrato, contrastando a resposta genérica de vendas com o que você precisa fixar:
| Cenário | Resposta genérica de vendas | O que você precisa fixar no contrato |
|---|---|---|
| Cliente abandona a conversa | "Depende do fluxo" | Não cobrável sem confirmação explícita de resolução |
| Cliente volta com mesmo assunto | "Cada conversa é cobrada" | Janela de deduplicação (ex.: 24h, mesmo tópico = 1 cobrança) |
| Agente escala para humano | "Só cobramos se o agente resolve" | Zero cobrança em qualquer conversa que termine em handoff |
| Cliente marca "não resolveu" | Silêncio | Reembolso ou não-cobrança em CSAT negativo pós-resolução |
| Pico anômalo de volume | "Escala com você" | Teto mensal ou cláusula de revisão em spike acima de X% |
A tese: trate suporte como linha de receita, não de custo
Aqui está o giro que quero propor. O reflexo natural de quem enxerga o pay-per-resolution é defensivo: "como eu contenho esse custo?". É uma pergunta legítima, mas incompleta. A pergunta melhor é: se cada resolução tem um preço explícito agora, quanto vale para o meu negócio cada resolução?
Quando o suporte era custo fixo, ninguém precisava responder isso. Você pagava os assentos e pronto. Agora que cada resolução tem etiqueta de preço, você é forçado — pela mecânica do modelo — a comparar o custo de resolver com o valor de resolver. E aí o suporte deixa de ser um centro de custo genérico e vira algo que você precisa avaliar como avalia um investimento com retorno.
Considere o que uma resolução bem-feita significa em termos de receita:
- Retenção. Um cliente cujo problema foi resolvido rápido e bem tem menor probabilidade de churn. Se você conhece o valor de um cliente retido, você consegue estimar quanto uma boa resolução vale — e US$ 2 pode ser barato ou caro dependendo de para quem.
- Expansão. Suporte é ponto de contato onde a receita de expansão nasce ou morre. Uma interação bem conduzida pode abrir espaço para upsell; uma mal conduzida fecha portas.
- Custo evitado. Cada resolução autônoma bem-feita é uma que não consumiu tempo de agente humano — e o custo do agente humano é a régua real de comparação, não zero.
Isso muda a natureza da decisão. Você não está mais perguntando "como pagar menos por suporte". Está perguntando "quais resoluções valem o preço variável, e quais eu deveria estar deflectindo de graga ou tratando de outra forma". É uma disciplina de segmentação de custo por valor de cliente — e é exatamente o tipo de rigor que o retorno do CAC como métrica-rainha exige de toda linha da operação.
O modelo pay-per-resolution, ironicamente, força uma maturidade que a maioria das operações de suporte nunca teve: saber quanto vale cada resolução. Quem transforma essa imposição em disciplina sai na frente. Quem só tenta "conter o custo" perde a oportunidade e ainda paga caro.
Como isso se aterra numa operação real
Deixe-me aterrar isso num exemplo claramente hipotético, sem inventar números de resultado — apenas para mostrar o mecanismo de raciocínio.
Suponha uma empresa de software B2B de médio porte, com uma base de clientes que paga assinaturas de valores bem diferentes entre si — alguns pagam pouco por mês, outros pagam contratos anuais robustos. Essa empresa está avaliando adotar o Help Agent no modelo por resolução. O reflexo inicial do time seria ligar o agente para toda a base e deixar ele resolver tudo que puder. Parece eficiente.
Mas aplicando a lógica da tese, a operação faria diferente. Primeiro, mapearia o valor de cada resolução por segmento de cliente. Para os clientes de contrato robusto, cujo churn custa muito, resolver rápido e bem vale muito mais do que o preço unitário da resolução — ali, deixar o agente atuar com folga faz sentido, e talvez até valha combinar agente com handoff humano nos pontos certos para garantir a experiência.
Para o segmento de baixo ticket, com muitas dúvidas repetitivas e de baixa complexidade, a operação priorizaria investir na camada de deflection gratuito — base de conhecimento, FAQ, fluxos de autoatendimento — antes de deixar o volume cair no agente pago. Porque pagar US$ 2 por uma pergunta que um artigo responde de graça é queimar margem justamente no segmento onde a margem já é apertada.
Note o que essa empresa não faria: ela não trataria "resolução" como um número neutro. Ela também não confiaria cegamente no relatório de resoluções do fornecedor. Manteria uma medição própria — CSAT pós-resolução, taxa de reabertura, tickets do mesmo cliente sobre o mesmo tema — para checar, de forma independente, se as resoluções que estão sendo cobradas são de fato resoluções. Isso é o mínimo de governança de IA que um modelo variável exige.
O ponto da ilustração não é um placar de "economizou X%". É o mecanismo: o modelo por resolução só é vantajoso para quem segmenta o valor da resolução e controla a definição do que é cobrado. Para quem apenas liga o agente e paga a fatura, ele é uma linha variável sem freio.
E se der errado? Objeções honestas
Seria desonesto vender a tese sem enfrentar as objeções. Vamos a elas.
"Você está sendo paranoico com o fornecedor. A Salesforce não vai fraudar resolução."
Correto, provavelmente não vai fraudar deliberadamente. Mas o argumento nunca foi sobre fraude. É sobre incentivo estrutural e sobre ambiguidade de definição. Mesmo com boa-fé total do fornecedor, se "resolução" não estiver rigorosamente definida no contrato, casos-limite serão resolvidos de formas que você não controla. E boa-fé não é cláusula contratual. O que protege sua fatura é a definição escrita, não a intenção do vendedor.
"O modelo variável ainda sai mais barato que headcount humano."
Pode sair — e frequentemente sai, para o volume que o agente realmente resolve bem. Mas essa comparação só é honesta se você contar o custo total: o custo das resoluções pagas mais o custo das resoluções ruins que geram retrabalho, reabertura e churn mais o custo do humano que ainda precisa existir para os casos escalados. A comparação simplista "US$ 2 é menos que o custo/hora de um agente" ignora que nem toda resolução do agente equivale a uma resolução humana em qualidade. A conta certa é a de custo por resolução efetiva, não por resolução cobrada.
"Ter custo variável é bom, dá elasticidade."
Dá — para cima. Elasticidade é ótima quando o volume cai e você paga menos. É péssima quando o volume explode por um motivo que não é receita: um bug, uma crise, uma mudança confusa. Custo variável atrelado a problema de produto significa que quanto pior seu produto está num mês, mais caro fica seu suporte — exatamente quando você menos quer gastar. Sem um teto contratual ou cláusula de revisão em spike, essa elasticidade trabalha contra você nos piores momentos.
"Isso é complexidade demais para uma operação pequena."
Talvez. Para uma operação muito pequena, com pouco volume e pouca variação, o modelo variável pode ser genuinamente simples e vantajoso — você paga pouco porque resolve pouco, e a fatura nunca chega perto de doer. O alerta deste artigo é mais forte à medida que o volume cresce e a base se diversifica. Quanto maior e mais heterogênea a operação, mais o modelo variável exige a disciplina de segmentação e controle de definição que descrevemos. Saber em que ponto dessa curva você está é parte da decisão.
O que o modelo variável revela sobre o futuro do software
O pay-per-resolution do Help Agent não é um detalhe de precificação da Salesforce. É um sinal de para onde o software inteiro está indo. À medida que agentes de IA assumem trabalho que antes exigia gente, o modelo de "pague pelo acesso" perde sentido e o modelo de "pague pelo resultado" avança. Isso vai acontecer em vendas, em marketing, em operações — não só em suporte. O que estamos vendo em suporte é apenas o primeiro lugar onde a mudança ficou explícita, porque suporte é onde a IA agente amadureceu mais rápido.
E aqui está a reflexão que quero deixar. Por décadas, o custo de software foi uma linha que você negociava uma vez por ano e esquecia. Fixo, previsível, invisível no dia a dia. O modelo por resultado acaba com isso. Ele torna cada uso do software uma microdecisão econômica — e transfere para dentro da sua operação a responsabilidade de saber quanto vale cada resultado que você compra. Isso é mais trabalho. Também é mais honesto. Você não pode mais esconder desperdício numa licença anual esquecida; cada resolução ruim aparece na fatura.
O modelo por resultado não é mais barato nem mais caro por natureza. Ele é mais exigente. Recompensa quem sabe o que cada resultado vale e pune quem nunca se deu ao trabalho de descobrir.
A pergunta que fica não é "devo adotar o Help Agent no modelo por resolução?". É uma pergunta anterior e mais desconfortável: minha operação sabe quanto vale cada resolução de suporte que ela entrega hoje? Se a resposta for não — e para a maioria será não — então o problema nunca foi o modelo de cobrança da Salesforce. O modelo só escancarou uma cegueira que já existia. E, como toda dívida que sua operação carrega em silêncio, ela não some quando você ignora. Ela só vira uma linha maior no mês seguinte.