Preço por usuário virou padrão em SaaS B2B porque é fácil de vender, fácil de prever e fácil de cobrar. O problema é que ele nunca mediu valor de verdade — media assentos. Em produtos onde o uso varia muito entre clientes, e isso está cada vez mais comum com funcionalidades de IA que consomem recursos de forma desigual entre contas do mesmo plano, cobrar por cadeira começa a distorcer tanto a receita quanto a percepção de valor do cliente.

É por isso que modelos híbridos — uma assinatura base somada a um componente de uso — vêm ganhando espaço. Não é modismo de precificação. É uma correção depois de anos de preço por assento sendo aplicado em contextos onde ele nunca fez muito sentido.

Por que o preço por assento está perdendo espaço

O argumento comercial do preço por assento sempre foi a simplicidade: um número, uma variável, fácil de explicar em uma call de vendas. Mas simplicidade para o vendedor nem sempre significa alinhamento com o cliente. Quando uma conta usa o produto pesadamente com poucos assentos e outra usa pouco com muitos assentos, as duas pagam de forma parecida por valor muito diferente — e isso corrói tanto a expansão quanto a retenção ao longo do tempo.

A newsletter Growth Unhinged, de Kyle Poyar, vem documentando essa migração para modelos híbridos e baseados em uso como uma das mudanças estruturais mais relevantes na monetização de SaaS B2B agora que produtos de IA tornaram o consumo desigual a regra, não a exceção. O ponto não é que preço por assento vai desaparecer — para muitos produtos ele continua sendo o modelo certo. É que ele deixou de ser o padrão automático.

O que quebra na operação quando o modelo de preço muda

Trocar a estrutura de preço é uma decisão que parece pertencer ao produto ou ao marketing, mas quem sente o impacto operacional completo é o RevOps. Alguns pontos que costumam quebrar primeiro:

  • CRM e estrutura de oportunidade: campos de valor de negócio pensados para “número de assentos x preço” não capturam componentes de uso, tiers de consumo ou preço mínimo garantido.
  • Faturamento e reconhecimento de receita: cobrança recorrente fixa é trivial de automatizar; cobrança híbrida com componente variável exige métricas de uso confiáveis, ciclos de fechamento mais frequentes e regras de reconhecimento de receita mais elaboradas.
  • Plano de comissão de vendas: comissionar sobre ACV fechado é simples quando o ACV é previsível no fechamento. Quando parte da receita depende do uso futuro do cliente, o vendedor está sendo pago por algo que ele não controla mais sozinho — o que empurra a conversa de comissionamento para perto do sucesso do cliente.
  • Forecasting: um modelo de receita baseado em assentos fixos permite prever com alta confiança a partir do pipeline. Um modelo com componente de uso introduz variância que o forecast precisa aprender a incorporar, normalmente com dados históricos que ainda não existem no início da transição.

Como preparar o RevOps antes de migrar

A maior parte dos problemas de uma migração de pricing não aparece no anúncio do novo modelo — aparece três a seis meses depois, quando o time percebe que a operação não estava pronta. Vale endereçar antes:

  • Ter telemetria de uso confiável e auditável antes de precificar em cima dela — se o dado de consumo não é confiável para debug interno, ele não deveria virar linha de fatura.
  • Redesenhar os campos de oportunidade no CRM para separar receita fixa, receita variável estimada e receita variável realizada, em vez de um único campo de ACV.
  • Revisar o plano de comissão junto com vendas antes do lançamento, não depois da primeira reclamação sobre comissão inconsistente.
  • Rodar o novo modelo em paralelo com o antigo em uma amostra de contas por pelo menos um ciclo de faturamento completo antes de generalizar.
  • Definir com clareza como contas existentes serão migradas — grandfathering, prazo de transição e comunicação — antes de anunciar qualquer coisa publicamente.

Mudança de pricing não é um projeto de produto com um efeito colateral operacional. É um projeto operacional que também muda o preço.

Erros comuns nessa transição

O erro mais comum é tratar a mudança de modelo como um anúncio de produto e só acionar RevOps depois que a data de lançamento já está marcada. O segundo erro mais comum é subestimar quanto trabalho manual vai ser necessário nos primeiros meses, porque as automações de faturamento e comissão ainda não foram testadas em produção com dados reais de uso.

O terceiro, mais silencioso, é migrar toda a base de clientes de uma vez. Testar o modelo híbrido em um segmento controlado — novos clientes, ou uma vertical específica — expõe os problemas de dados e processo em uma escala gerenciável, antes que eles apareçam multiplicados na base inteira.

Se sua empresa está considerando essa mudança, o trabalho de verdade não é decidir o novo modelo de preço. É garantir que CRM, faturamento, comissionamento e forecast consigam operar nele sem depender de planilha paralela.