RevOps mede adoção de IA, mas deveria medir o abandono das ferramentas

O dashboard de adoção mede distribuição, não valor

Todo RevOps hoje produz um painel de adoção de IA: licenças compradas, seats ativados, prompts enviados por semana. É o número que o board pede e que o fornecedor da ferramenta de copiloto de vendas, do assistente de prospecção ou do motor de forecast com IA reporta na revisão trimestral de negócio. O problema é que esse número mede distribuição, não se a ferramenta ganhou um lugar permanente no trabalho de alguém.

Essa é a tese central de um artigo de opinião publicado em 9 de outubro de 2026 na CIO, assinado por Nishant Virmani, staff technical program manager no Google, que lida diariamente com adoção de IA e governança de plataforma em larga escala. Segundo ele, apenas 31% dos líderes do C-level esperam conseguir medir o ROI da IA generativa nos próximos seis meses. Na prática, métricas de adoção não complementam o ROI: elas o substituíram.

Para quem cuida de pilha de ferramentas de receita, isso tem um agravante: na maioria dos contratos SaaS, quem define a métrica de uso é o próprio fornecedor, que a instrumenta e reporta de volta. Não é má-fé, é prática comercial padrão, mas o critério foi desenhado para justificar a utilização da licença, não para auditar se o representante comercial, o analista de marketing ou o CS realmente mudaram como trabalham.

Três padrões de abandono, três consertos diferentes

Virmani separa o abandono em três categorias que pedem ações distintas. Tratá-las como um único tipo de fracasso é o erro mais comum de quem só olha a taxa de adoção agregada.

O caso mais perigoso é o terceiro, porque parece adoção saudável em qualquer fotografia isolada. Só a curva ao longo do tempo mostra a ferramenta morrendo devagar, geralmente porque resolveu uma tarefa de novidade inicial e perdeu relevância conforme o playbook mudou, ou porque o resultado nunca ganhou confiança suficiente para virar mais que um gerador de primeiro rascunho.

A conta fecha rápido: num contrato de mil seats, 20% nunca adotados somados a 20% experimentados e abandonados são 400 licenças pagas que ninguém usa. Em qualquer stack de RevOps com várias ferramentas de IA coexistindo, esse número costuma estar escondido atrás da média de adoção geral.

Como montar a curva de retenção sem comprar nova plataforma

A boa notícia é que não é preciso instrumentar nada novo. Retenção por cohort é padrão em software de consumo há duas décadas e funciona igual em ferramenta interna de IA: agrupe usuários pelo mês em que ativaram a licença e veja quantos ainda usam ativamente na semana 1, na semana 4 e na semana 12.

O artigo propõe três regras práticas para construir essa curva a partir de logs que o RevOps já tem:

• Conte ações intencionais, não carregamento de plugin em segundo plano. Use logs de single sign-on, de rede ou do próprio fornecedor, e conte escolhas ativas, como enviar um prompt ou aceitar uma sugestão de IA direto no registro do CRM.
• Compare contra duas baselines. Usuários ativos na semana 12 contra o total de licenças compradas expõe orçamento desperdiçado num rollout travado; contra quem logou ao menos uma vez expõe se a ferramenta entregou valor no dia a dia.
• Leia onde a queda acontece. Queda forte na semana 1 aponta para onboarding quebrado ou ferramenta no time errado; sangria lenta entre a semana 4 e a 12 aponta para atrito de fluxo de trabalho depois que a curiosidade inicial passa.

Um detalhe que pesa especialmente em vendas e marketing: fornecedores de IA reajustam ou trocam modelos entre versões sem aviso, então uma queda súbita pode refletir atualização de modelo, não problema de workflow. E vale checar o uso geral de IA do time além da ferramenta específica, porque mais de 12 mil aplicações de shadow AI já operam dentro de empresas, com cerca de 50 novas surgindo por dia, segundo o artigo. Um representante que abandona o copiloto oficial pode simplesmente ter migrado para outro assistente aprovado ou contornado o processo de IT, o que quebra atribuição e governança de dado de funil sem que ninguém perceba na métrica agregada.

O que muda na renovação do contrato

É na renovação que a diferença aparece. Hoje a maioria das decisões se apoia em número cumulativo de adoção, que nunca foi desenhado para dizer se vale manter o contrato.

Com dado de abandono, a divisão fica em três grupos: ferramenta com alto índice de nunca adotado ou experimentado e abandonado é candidata a cortar, independente de como o dashboard de uso tenta embelezar o número; ferramenta com uso em decaimento é candidata a conserto, via ajuste de fluxo, integração melhor ou retreinamento nas tarefas onde a confiança quebrou; e ferramenta com retenção realmente sustentada é candidata a receber mais orçamento, inclusive expandindo seats mais rápido que o ritmo padrão de rollout.

Quando duas ferramentas atendem a mesma população, por exemplo duas plataformas de inteligência de conversação depois de uma fusão, a que segura o cohort deveria tomar seats da que não segura. E há dois pedidos que o RevOps deveria colocar em qualquer contrato novo: definir o que conta como usuário ativo antes da assinatura, e exigir exportação de uso em nível de evento, não só o dashboard-resumo. É essa granularidade que entra no warehouse e sustenta qualquer modelo de atribuição depois.

Por que mandar usar e meta de retenção saem pela culatra

Dois erros comuns destroem o próprio sinal que se quer medir. O primeiro é tratar uso como meta compulsória.

Adoção diz o que você comprou. Abandono diz o que vale manter. (original, en) Adoption tells you what you bought. Abandonment tells you what to keep. (autor) Nishant Virmani, staff technical program manager no Google

No momento em que o uso vira item de avaliação de desempenho, o comportamento para de significar qualquer coisa: alguém concluir que a ferramenta não serve para o seu trabalho é a avaliação funcionando, não falhando. A meta correta de abandono não é zero.

O segundo erro é tratar retenção saudável como prova automática de entrega. Abandono funciona limpo numa direção só: quem aprendeu a ferramenta e largou deu um veredito claro, mas quem continuou usando diz menos do que parece. O artigo cita um estudo controlado em que desenvolvedores experientes, trabalhando em código que já conheciam, levaram 19% mais tempo usando ferramenta de IA enquanto acreditavam estar 20% mais rápidos.

Em RevOps o paralelo é direto: representante que se sente mais produtivo com rascunho de e-mail gerado por IA pode não estar fechando mais rápido, nem melhor. Por isso retenção precisa andar ao lado de métrica de receita, como taxa de vitória, ciclo de venda e acurácia de forecast, não só tempo de uso ou produtividade autorreportada.

Antes da próxima renovação

Nada disso exige programa novo. Pegue as datas de ativação que o RevOps já tem, construa uma curva de retenção para os três maiores contratos de IA da pilha de receita, como o copiloto de CRM, a inteligência de conversação e o motor de forecast, e cheque semana 4 e semana 12. Para a maioria das operações isso é trabalho de uma tarde.

Coloque uma revisão trimestral de 15 minutos na agenda com o dono de cada plataforma para inspecionar a curva e o gap entre provisionado e sustentado. Essa revisão é do time que cuida do fluxo de trabalho, não de compras: consertar um cohort em decaimento significa mudar o rollout, não renegociar preço unitário. E observe a retenção dentro do cohort, não o headcount bruto: uso durável numa equipe pequena de alto valor vale mais que adoção rasa numa equipe grande.

Os números de adoção continuam úteis para saber se os times estão dispostos a experimentar algo novo. Mas antes da próxima renovação, o pedido certo para o fornecedor é a curva de retenção, não o relatório de prompts enviados.