Agente do cliente como usuario do produto

O que muda quando o usuário do seu produto é um agente

Muda que o consumo para de ser proporcional a pessoas: fica mais constante, mais volumoso e menos sensível a treinamento e engajamento. Produto e contrato seguem os mesmos, mas três instrumentos que a operação comercial usa todos os dias — a fatura por assento, o relatório de usuários ativos e o health score — passam a medir uma realidade que não existe mais.

A fronteira: lá o agente compra, aqui o agente usa

São dois temas em fases diferentes do ciclo, com donos diferentes. O agente que compra — que pesquisa fornecedores, compara opções e conduz a transação — é assunto de pré-venda e está em agentes-de-compra-buyer-agents-o-que-muda-para-quem-vende: se a dúvida é como o seu material é lido por máquina ou o que muda na jornada de compra, o artigo é aquele. Este começa depois da assinatura, quando o produto já foi comprado por pessoas e quem o consome no dia a dia é um agente do cliente — e o dono do problema deixa de ser vendas para ser gestão de contas. Também não trata dos agentes da sua própria operação comercial, que estão em governanca-de-agentes-de-ia-agent-sprawl-na-operacao-comercial.

Por que o consumo deixa de ser proporcional ao número de pessoas

Porque desaparece o limite que sempre segurou o uso: a jornada de trabalho de uma pessoa. Um usuário humano abre o produto algumas vezes por dia, com pausas, férias e curva de aprendizado — é esse comportamento que faz o assento funcionar como aproximação de consumo. Um agente não tem jornada: executa quando é acionado, na frequência que a regra do cliente definir, e o volume vira função do processo automatizado, não do quadro de funcionários. Daí duas consequências: o uso deixa de crescer em degraus (contratação de pessoas) e passa a crescer em saltos (mudança de configuração); e deixa de responder às alavancas clássicas de adoção, porque treinar melhor um agente é reconfiguração — e quem faz isso não é o usuário final.

O que a telemetria de fornecedor indica — e o que ela não é

Indica direção, não tamanho de mercado, e a distinção precisa estar clara antes de qualquer número entrar numa proposta. Segundo a telemetria de uso da própria plataforma divulgada pela Salesforce (2026), referente ao período de fevereiro de 2025 a abril de 2026, o número médio de agentes ativados por organização cresceu quase três vezes, a complexidade média subiu de duas para seis skills (as habilidades distintas que um agente sabe executar) por agente, e a taxa de escalonamento para humano — a proporção de interações que o agente devolve para uma pessoa resolver — manteve-se estável em 32%.^[1]

O tipo de fonte precisa ser dito: é telemetria agregada de uso de um fornecedor sobre a própria base de clientes — não é pesquisa de mercado, não tem amostra representativa, não tem recorte do Brasil e não pode ser lida como "o mercado". Serve como sinal de que agentes vêm sendo ativados em número crescente e ficando mais complexos, e o escalonamento estável sustenta um ponto deste artigo: o agente não elimina o humano do fluxo, e o que ele devolve é medível. Não há dado brasileiro público sobre o tema — por isso o que segue trabalha o mecanismo, e a ancoragem local vem do exemplo em reais e do vocabulário de contrato, não de estatística.

Discovery: o que perguntar quando o consumidor é um agente

A discovery precisa descobrir o processo automatizado, não o número de pessoas na área — é o processo que determina volume, padrão de uso e risco. As perguntas de sempre valem para a parte humana da conta, mas não dimensionam nada quando o consumo vem de um agente.

As sete perguntas que dimensionam o consumo

São sete perguntas concretas, todas com resposta verificável antes da proposta:

1. Qual agente vai consumir o produto? Construído pelo cliente, contratado de terceiro ou embutido em ferramenta que ele já usa — e quem o mantém.
2. Que tarefa ele executa no seu produto? É a tarefa que define a unidade de cobrança defensável; sem ela, você cobra por um proxy.
3. Com que frequência e em que padrão? Disparo por evento, execução em lote ou varredura periódica — cada um produz uma curva de consumo diferente, e o lote é o que surpreende.
4. Por qual via ele acessa? Interface, API ou integração intermediada — isso determina o que você consegue medir.
5. Quem responde por ele do lado do cliente? Nome e área — o interlocutor de um agente não é o usuário final.
6. O que acontece quando ele erra ou entra em loop? Existe limite de tentativas e alerta — ou o erro vira volume cobrado dos dois lados.
7. Quantos agentes estão previstos adiante? A expansão típica é por novo caso de uso, e chega sem aviso comercial.

A sexta é a mais esquecida e a mais cara: um agente em loop gera volume que parece adoção, custo real para você e fatura inesperada para o cliente.

Quem responde pelo agente do lado do cliente

Quase nunca é a área que assinou o contrato. Quem configura, aciona e corrige o agente costuma ser um time técnico — integração, dados ou TI —, enquanto quem paga é a área de negócio e quem renova pode ser um terceiro interlocutor. Isso cria um risco silencioso: o produto pode estar entregando valor todos os dias sem que a pessoa que decide a renovação tenha contato com ele, porque não há uso humano gerando percepção. A contramedida é mapear três nomes desde a implantação — quem responde pelo agente, quem responde pelo resultado do processo e quem assina a renovação — e garantir que o segundo receba evidência periódica do que foi executado. Sem isso, a conta chega na renovação tecnicamente saudável e comercialmente órfã.

Cobrança: por que o assento perde lastro

O assento perde lastro porque é uma aproximação de consumo por pessoa, e o agente rompe essa proporção nos dois sentidos. Na substituição, o cliente automatiza um processo, precisa de menos pessoas com acesso, os assentos caem na renovação e a receita cai junto, mas o volume que o seu produto executa é o mesmo: a conta fica menor e mais cara de servir. Na multiplicação, o quadro humano permanece, os assentos crescem no máximo em uma unidade e o consumo cresce em múltiplos. Os dois convivem na mesma carteira e, no agregado, parecem estabilidade — a receita média por conta se mexe pouco enquanto a margem se deteriora nas duas pontas —, por isso a revisão precisa ser conta a conta. A escolha do modelo em abstrato está em modelos-de-cobranca-licenca-assinatura-uso-e-projeto e precificacao-de-saas-por-usuario-por-uso-ou-por-tier; aqui o gatilho já aconteceu na conta.

Que unidade de cobrança usar em cada caso

Não existe unidade universal: existe a proporcional ao seu custo, verificável pelo cliente e explicável em uma frase.

Simulação: a mesma conta sob três unidades de cobrança

A simulação compara uma conta de referência nos dois cenários que quebram o assento. Os valores são exemplo editorial para ilustrar o raciocínio, não benchmark de mercado — não há dado público brasileiro de consumo de agentes em produtos B2B. A conta tem 20 usuários humanos a R$ 300 por assento (R$ 6.000 por mês), volume de 4.000 tarefas por mês, custo fixo de entrega de R$ 1.000 e custo variável de R$ 0,50 por tarefa — custo total de R$ 3.000. As alternativas simuladas são R$ 1,20 por execução e R$ 1,50 por tarefa concluída com sucesso, a uma taxa de sucesso de 95%. No cenário A (substituição), restam quatro pessoas mais um agente — cinco assentos — e o volume segue em 4.000 tarefas. No cenário B (multiplicação), as 20 pessoas permanecem, entra um agente e o volume vai a 20.000 tarefas, elevando o custo para R$ 11.000.

Três leituras saem da tabela. No cenário base, o assento é a unidade mais rentável — por isso é padrão, e por isso trocá-lo custa uma conversa difícil internamente. Assim que um agente entra, é a única que produz prejuízo, e produz nos dois cenários opostos: o problema não é a direção do movimento, é o lastro da métrica. E a cobrança por resultado parece dominante, mas carrega risco assimétrico — o custo incorre em toda tentativa e a receita só entra no acerto. No cenário B, se a taxa de sucesso cair de 95% para 70% porque o agente do cliente passou a errar, a receita cai para R$ 21.000 e a margem para R$ 10.000. Por isso ela só se sustenta com critério de sucesso escrito e limite de tentativas.

O que precisa estar escrito no contrato como unidade de uso

Precisa estar escrito o que conta como uma unidade — no contrato, não em documentação de produto que você pode alterar depois. As bordas são onde a fatura vira disputa: uma tarefa que falhou conta? Uma execução que exigiu três chamadas internas é uma ou três? Reprocessamento por erro do agente do cliente é cobrado? Teste em homologação entra na franquia? Um agente em loop pode gerar sozinho, em uma noite, mais volume que a área inteira em um mês, e quem não escreveu a regra vai negociá-la depois do fato, em posição fraca. Junto da unidade vão três parâmetros: franquia inclusa, teto de gasto no período e alerta antes do estouro — notificar em percentuais definidos da franquia remove o principal argumento de contestação.

Adoção e health score quando não há login humano

Quando o consumo vem de um agente, as duas métricas que sustentam a gestão de contas — usuário ativo e volume de uso — precisam ser substituídas por medidas de trabalho concluído. Login não indica adoção quando ninguém faz login; uso alto não indica saúde quando o uso é automático. adocao-do-produto-por-que-ela-sustenta-a-renovacao e health-score-do-cliente-o-que-e-e-como-montar montam o instrumento no pressuposto de usuários humanos; aqui o pressuposto cai.

As métricas que substituem usuário ativo

Substituem usuário ativo quatro medidas, e todas descrevem trabalho entregue, não presença: a quantidade de tarefas concluídas com sucesso, segundo critério definido em conjunto com o cliente, que é o que mais se aproxima de valor entregue; a taxa de erro, que mede execuções que falham ou precisam de reprocessamento e sobe silenciosamente quando o cliente muda a configuração do agente; a taxa de escalonamento para humano, ou seja, quanto do que o agente tentou voltou para uma pessoa resolver; e a cobertura dos casos de uso contratados — de quantos processos previstos na venda o agente executa hoje.

A cobertura é a mais negligenciada e a mais preditiva de renovação: um cliente que contratou pensando em cinco processos e automatizou um consome e parece ativo, mas contratou uma promessa que não se realizou — e isso volta como questionamento de preço. Já a taxa de escalonamento não é defeito a eliminar: na telemetria da Salesforce citada acima ela se manteve estável ao longo do período,^[1] o que indica devolução ao humano como funcionamento normal. O que interessa é a variação dessa taxa na sua própria base ao longo do tempo, nunca a comparação com o número de um fornecedor, que mede outra plataforma e outros casos de uso.

O falso positivo do uso automatizado no health score

O falso positivo acontece porque o health score — o indicador que combina sinais de uso e relacionamento para estimar risco de perder a conta — foi construído assumindo que uso alto e constante é engajamento. Com agente, uso alto e constante é o comportamento padrão de um software em execução, e pode ser o oposto de saúde: um agente repetindo tarefa que falha, um processo em loop que reprocessa sem entregar, ou uma integração mal configurada que consulta o produto muito além do necessário. Nos três casos o painel fica verde, o custo sobe dos dois lados e o cliente forma uma percepção negativa que nenhuma métrica de volume captura.

A correção tem três movimentos. Trocar o componente de volume por tarefas concluídas com sucesso: se o volume subir e o sucesso não, o score deve piorar, não melhorar. Incluir a estabilidade da configuração, porque agente desligado, integração parada ou queda abrupta de execuções é sinal de risco muito mais forte que qualquer queda de login — significa que o processo saiu de produção. E manter um componente humano e explícito, com contato periódico com quem responde pelo resultado do processo, já que sem usuário humano no produto não há sinal relacional nenhum vindo do uso.

Onboarding, renovação e expansão

Com agente, a implantação é projeto de integração e não programa de treinamento — muda quem participa, o que conta como sucesso na primeira semana e como se mede o time-to-value (o tempo entre a assinatura e o primeiro resultado concreto). A régua baseada em capacitação e primeiros logins não se aplica: ninguém vai ser treinado, e o primeiro login pode nunca acontecer.

Onboarding com agente é integração, não treinamento

É integração porque o que precisa acontecer na primeira semana é técnico: credenciais, ambiente de teste, mapeamento do caso de uso, limites de execução e o primeiro processo rodando de ponta a ponta. Entram integração e arquitetura do lado do cliente, às vezes segurança, e o marco de sucesso deixa de ser "o time foi treinado" para ser "o agente executou o processo combinado em produção, com taxa de erro conhecida". A mecânica de conectar sistemas está em como-integrar-as-ferramentas-da-stack; o ponto comercial é outro: se a régua continuar contando treinamentos, a conta aparece como atrasada enquanto vai bem, ou como concluída enquanto o agente nunca entrou em produção. Um bom marco intermediário é o primeiro lote executado sem escalonamento anômalo, com limite de tentativas configurado.

Como provar valor e de onde vem a expansão

Prova-se valor com evidência do processo, já que não existe usuário humano para depor: quantas execuções foram concluídas no período, com que taxa de sucesso, quanto voltou para pessoas e o que isso representa no ciclo que o cliente queria melhorar. Esse relatório precisa existir por padrão, e não ser produzido às pressas trinta dias antes da renovação, porque o argumento é a série histórica — um retrato isolado não prova nada. A expansão, por sua vez, muda de natureza: deixa de vir de mais assentos e passa a vir de novos casos de uso do agente. Cada processo ainda executado manualmente é um movimento possível, e a pergunta de expansão deixa de ser "quantas pessoas mais vão usar?" para virar "qual é o próximo processo que o agente vai executar aqui dentro?" — o que reposiciona a conversa de crescimento para quem desenha processos, não para quem administra licenças.

Sobre dados pessoais: quando o agente do cliente consome dados por meio do seu produto, registre por escrito quem é controlador (quem decide a finalidade do tratamento — normalmente o cliente) e quem é operador (quem trata os dados por conta dele — normalmente você), e o que fica em log a cada execução. A pergunta que costuma faltar é por quanto tempo esse registro é retido e quem pode acessá-lo, porque volume automatizado gera volume de log na mesma proporção — item de contrato que, indefinido, vira bloqueio na auditoria do cliente.

Erros que transformam a conta com agente em prejuízo ou churn

Quatro erros respondem pela maior parte das perdas nessas contas, e todos são de gestão comercial, não de produto. Manter a cobrança por assento por inércia é o mais caro: a conta que substituiu pessoas encolhe a receita sem encolher o custo, e a que multiplicou volume drena margem em silêncio. Comemorar volume de uso como sinal de saúde converte um possível loop em relatório de sucesso, e o erro só aparece na reclamação da fatura ou na não renovação. Tratar o agente como usuário humano na régua de onboarding mede a implantação por treinamentos que ninguém precisa, escondendo o único marco que importa. Não definir no contrato o que conta como uma unidade de uso deixa a definição para depois do fato — e depois do fato quem interpreta é sempre quem paga. Some a eles não saber quem responde pelo agente do lado do cliente: sem esse nome, um limite mal configurado vira semanas de agente parado, o sinal de churn mais forte nessas contas.