Preços por Assento Estão Morrendo. Veja o Que Está Substituindo

O preço por assento fazia sentido quando o software era para desktop. Você tinha usuários. Contava eles. Pagava por licença. A relação entre o valor entregue e o custo era razoavelmente transparente.

Num mundo de automação com AI, orquestração de workflows e ferramentas que executam processos sem humanos no loop, cobrar por assento humano está cada vez mais desconectado de como o valor é realmente entregue. Um CRM que auto-enriquece registros, auto-resume calls e auto-gera e-mails de follow-up está fazendo trabalho significativo independentemente de um vendedor estar sentado na frente do computador. Uma plataforma de automação de workflows pode processar 10.000 registros de clientes durante a noite sem ninguém tocar um teclado. O modelo por assento não precifica nenhum desses resultados.

Os vendors estão mudando arquiteturas de precificação mais rápido do que a maioria dos compradores está ajustando seus modelos de procurement. O desalinhamento está criando surpresas de orçamento que nenhum CFO antecipou ao assinar o último acordo enterprise de três anos.

Por Que os Preços por Assento Estão Sob Pressão Estrutural

Três forças independentes estão convergindo no modelo por assento simultaneamente.

AI está substituindo assentos, não apenas aumentando-os. A promessa original das ferramentas de produtividade de software enterprise era que tornariam cada assento mais produtivo. A realidade emergente é que algumas funções estão sendo gerenciadas por AI agents que não têm assentos. Um time de desenvolvimento de vendas que antes precisava de 15 SDRs rodando sequências de outbound agora pode rodar volume comparável com cinco SDRs e uma camada de orquestração de AI. Se você está pagando por assento e o número de assentos está diminuindo, o vendor precisa de uma alavanca de precificação diferente — e o preço baseado em uso em ações de AI ou chamadas de API é o óbvio.

A automação de workflows muda padrões de uso. Ferramentas tradicionais por assento assumiam que o consumo de features correlacionava com headcount. Uma pessoa de marketing usa a plataforma de marketing, e o uso dela escala com o tempo dela no trabalho. A automação de workflows quebra essa suposição. Uma pessoa pode configurar um workflow que roda mil vezes por dia sem o envolvimento dela. O valor entregue não tem relação com o número de assentos.

Empresas estão resistindo a pagar por assentos inativos. A pressão mais direta sobre os preços por assento é simples: as organizações estão auditando suas licenças e descobrindo que de 30 a 40% dos assentos pagos são usados raramente ou nunca. De acordo com pesquisa de gestão de SaaS da Productiv, a empresa média desperdiça 37% do seu gasto em SaaS em ferramentas e assentos subutilizados. Times de procurement que rodaram essa análise estão recusando duro em conversas de renovação.

Os Quatro Modelos Emergentes

Precificação baseada em uso. Você paga pelo que consome: chamadas de API, ações de AI, registros processados, e-mails enviados, armazenamento usado. Twilio é o exemplo canônico em comunicações. Snowflake em dados. Benchmarks anuais de SaaS da OpenView acompanham a mudança: a precificação baseada em uso passou de um diferenciador amigável para startups a um modelo dominante em software de estágio de crescimento e enterprise.

O risco para o comprador é o choque de fatura. A precificação baseada em uso transfere a responsabilidade de forecasting do vendor (custo fixo por assento) para o comprador (custo variável de consumo). Empresas que subestimam o uso enfrentam faturas que excedem o orçamento sem recurso fácil. Empresas que superestimam desperdiçam dinheiro em mínimos comprometidos.

Precificação baseada em resultado. Você paga quando o software entrega um resultado definido. Esse modelo é mais maduro em marketing de performance (pay-per-click, pay-per-conversion) mas está emergindo em SaaS B2B. Algumas plataformas de inteligência de receita cobram com base no Pipeline influenciado ou deals fechados. Algumas plataformas de legaltech cobram com base em contratos processados.

A precificação baseada em resultado alinha os incentivos do vendor com os resultados do comprador, o que parece ideal. O desafio de negociação é definir o que "resultado" significa, atribuí-lo ao software em vez de outros fatores e garantir que a metodologia de medição seja precisa e resistente à manipulação.

Precificação baseada em módulo. Em vez de por assento, você paga por módulo de capacidade ativo, independentemente de quantos usuários o acessam. A transição do HubSpot para esse modelo é instrutiva: em vez de cobrar por assentos em cada hub, eles mudaram partes da precificação para um modelo onde você paga pelo acesso a capacidades (Marketing Hub, Sales Hub, Service Hub) com acesso de usuário mais flexível dentro de cada nível.

A precificação baseada em módulo é adequada para compradores que precisam de uso intenso de capacidades específicas em muitos usuários ocasionais. Ela se desfaz quando você precisa apenas de parte das capacidades de um módulo, mas a precificação exige o módulo completo.

Modelos híbridos. A maioria dos softwares enterprise está se estabelecendo em estruturas híbridas: uma cobrança de assento base para usuários core com precificação baseada em uso em features de alto consumo. A precificação do Einstein AI da Salesforce, o Operations Hub do HubSpot e os add-ons de AI enterprise do Monday.com seguem esse padrão: uma base comprometida mais consumo variável para capacidades habilitadas por AI por cima.

Modelos híbridos são os mais comuns e os mais confusos. Um CFO que aprovou um contrato de $180.000 por ano com o Salesforce pode não ter antecipado que as features de AI adicionariam $40.000 em cobranças de uso até o terceiro trimestre. O contrato permitia. A conversa de orçamento não antecipou.

O Problema do Choque de Fatura

O choque de fatura é o principal risco para o comprador na precificação baseada em uso. Não é teórico. É um padrão documentado. O Subscription Economy Index da Zuora descobriu que a receita baseada em uso cresceu mais rápido do que qualquer outra categoria de modelo de precificação, e as reclamações de compradores sobre faturas inesperadas cresceram junto.

O mecanismo é direto: os compradores não têm bons modelos para fazer forecast de uso de novas capacidades. Quando uma empresa adota uma feature de AI baseada em uso pela primeira vez, está fazendo estimativas sobre taxas de consumo. Essas estimativas frequentemente estão erradas, e os vendors se beneficiam da variância. O custo deles é limitado pela sua estrutura de unit economics, enquanto o seu custo é limitado pelo seu consumo.

Três cláusulas contratuais protegem contra o choque de fatura em deals baseados em uso:

Caps de uso com gatilhos de notificação. Antes de sua fatura atingir um limiar definido, o vendor notifica você e pausa o consumo a menos que você autorize explicitamente a continuação. Muitos vendors resistem a caps rígidos (preferem avisos suaves) mas gatilhos de notificação são negociáveis. Um teto de consumo médio de 90 dias com alertas de e-mail a 75% é um ponto de partida razoável.

Pisos de taxa e mínimos comprometidos com rollover. Se você se comprometer com um consumo mensal mínimo, negocie direitos de rollover para capacidade não usada. Sem rollover, mínimos não usados expiram e cobranças de excedente se aplicam separadamente. Com rollover, meses de consumo excessivo usam primeiro a capacidade acumulada. Isso reduz significativamente a variância líquida.

Frequência de true-up. True-ups anuais são favoráveis ao comprador: você reconcilia o consumo ao final do ano, não mensalmente. True-ups mensais significam que sua fatura flutua a cada ciclo, criando complexidade de gestão de fluxo de caixa e orçamento. Empurre por true-ups trimestrais ou anuais com caps mensais em vez de faturamento mensal de true-up.

O Que Muda no Procurement

Orçar software por assento é simples: headcount multiplicado pelo custo por assento, com uma ordem de mudança se o headcount crescer significativamente. Financeiro consegue modelar esse cenário com confiança.

Orçar software baseado em uso requer uma abordagem analítica diferente. Você precisa de um modelo de consumo, não de um modelo de headcount. Isso significa:

Construir uma baseline de uso. Antes de assinar um contrato baseado em uso, passe 30 a 60 dias em um trial ou implantação limitada rastreando taxas de consumo reais. Não aceite as estimativas do vendor. Seus padrões de uso são específicos para seus workflows e volumes de dados. As estimativas do vendor são baseadas em médias que podem não se aplicar a você.

Modelar cenários de variância. Em vez de um único número de orçamento, construa um forecast de consumo com três cenários: baseline (uso esperado), crescimento (20% acima do baseline se a adoção correr bem) e pico (um cenário específico de alto consumo como uma campanha importante ou migração de banco de dados). Seu orçamento deve acomodar o cenário de crescimento sem precisar de aprovação de emergência.

Separar orçamentos de features de AI. Capacidades de AI têm estruturas de custo fundamentalmente diferentes das features de software tradicionais. O consumo delas pode disparar de forma imprevisível com maior adoção da equipe ou novos casos de uso. Trate orçamentos de add-on de AI como uma linha separada dos custos da plataforma base, com revisão trimestral incorporada ao ciclo de orçamento.

Negociar taxas de uso plurianuais. Se você está se comprometendo com um contrato plurianual, negocie precificação de consumo bloqueada, não apenas precificação de assento bloqueada. Um deal de três anos que bloqueia os custos de assento mas permite que o vendor mude a precificação de API anualmente oferece menos proteção do que parece.

A Avaliação de Risco do Modelo de Precificação

Use esse framework para avaliar qualquer estrutura de precificação em três dimensões antes de assinar.

Pontuação de Previsibilidade de Orçamento (1-5): Quão previsível é sua fatura mensal sob essa estrutura de precificação? Uma taxa plana por assento é um 5. Baseado em uso puro sem caps é um 1. Híbrido com caps e gatilhos de notificação é um 3-4. Atribua uma pontuação e determine se os processos de gestão de orçamento da sua organização conseguem absorver o nível de variância que a estrutura de precificação introduz.

Pontuação de Alinhamento do Vendor (1-5): O vendor ganha mais quando você obtém mais valor? Na precificação baseada em resultado, a receita do vendor escala com seus resultados (pontuação: 5). Na precificação pura por assento com renovações anuais, o incentivo do vendor é te prender na renovação, não maximizar seu valor no ano um (pontuação: 2-3). A precificação baseada em uso fica no meio: a receita do vendor escala com seu consumo, o que se correlaciona mas não mede diretamente o valor.

Pontuação de Alavancagem na Renovação (1-5): Quanta alavancagem de negociação você tem na renovação? Deals por assento com altos custos de mudança te expõem na renovação. Sua alavancagem é limitada a menos que você esteja disposto a absorver o custo de migração. Deals baseados em uso te dão dados: você pode mostrar exatamente o que consumiu, comparar com o que previu e negociar a partir de uma base de evidências. Deals baseados em resultado dão a alavancagem mais forte se os resultados são mensuráveis e você pode creditar plausível a eles.

Some as três pontuações. Um total de 10-15 é uma estrutura de precificação gerenciável. Abaixo de 8 justifica uma negociação mais difícil antes de assinar. Isso não é uma ferramenta de pass/fail. É um perfil de risco que diz onde gastar capital de negociação.

O Que os Compradores Deveriam Fazer Agora

Se seus contratos atuais são por assento e estão para renovação nos próximos 12 meses, a conversa de renovação mudou. Vendors que estão mudando para precificação baseada em uso ou híbrida vão tentar usar a renovação como ponto de transição, frequentemente com um preço inicial que parece comparável ao custo de assento atual, mas com níveis de uso que podem aumentar significativamente sua fatura se a adoção crescer.

Faça essas perguntas antes de assinar:

"O que acontece com nossa precificação se implantarmos suas features de AI para todos os usuários?" Obtenha um número específico, não um vago "escala com seu uso." Você quer saber seu custo total na adoção plena.

"Como têm sido as faturas dos seus clientes de crescimento mais rápido no ano dois em comparação ao ano um sob esse modelo de precificação?" Isso identifica o padrão de variância real, não o comportamento teórico do modelo.

"Que caps e proteções estão disponíveis para componentes baseados em uso?" Trate um vendor que não consegue responder isso especificamente como um indicador de risco.

A mudança para longe dos preços por assento não é inerentemente desfavorável para o comprador. A precificação baseada em resultado, bem feita, está mais alinhada com como os compradores pensam sobre o valor do software. A precificação baseada em uso, com caps adequados e modelagem, recompensa a implantação eficiente e não te penaliza por assentos inativos.

Mas o período de transição cria risco assimétrico. Os vendors estão movendo para novos modelos mais rápido do que a maioria dos compradores está ajustando seus frameworks de avaliação. O comprador que assina um deal baseado em uso sem um modelo de consumo e caps negociados está aceitando um risco que não precificou. O comprador que constrói o framework analítico antes da conversa negociará em pé de igualdade.

Leia Mais