A maioria dos debates sobre precificação em SaaS começa no lugar errado.
Os times discutem tiers. Se estressam com número de assentos versus limites de uso. Fazem benchmarks da concorrência. Rodam pesquisas perguntando aos clientes quanto pagariam. Depois lançam, veem as margens encolherem e ficam se perguntando o que deu errado.
O que deu errado foi o seguinte: o modelo de precificação foi construído sobre estimativas de custo, não sobre a realidade dos custos. E estimativas envelhecem mal. O segredo sujo da unit economics em SaaS
Quando um VP de Produto ou um consultor de precificação monta um modelo para um novo plano, ele parte de suposições e trabalha de trás para frente. Os custos de infraestrutura são aproximados. O consumo de recursos compartilhados vira uma média. O uso de IA é chute. A variância entre clientes é achatada em uma única linha.
O modelo diz que um cliente no plano Growth deveria custar US$ 80/mês para ser atendido. O custo real, quando você rastreia pela infraestrutura de verdade, fica mais perto de US$ 190 nas contas mais pesadas e US$ 12 nas mais leves. Na média, tudo parece ok. Mas a cauda está te matando em silêncio.
Isso não é um problema de estratégia de precificação. É um problema de dados. Mais especificamente, é um problema de dataset ausente.
Por que essa lacuna existe
As ferramentas tradicionais de custo de nuvem foram feitas para times de FinOps que gerenciam orçamentos de infraestrutura. Elas leem exports de billing, fazem parse de logs do CloudTrail e organizam o gasto por conta, região ou tag. Isso é útil para o time de engenharia que quer fazer right-sizing de instâncias EC2.
Não é útil para precificação.
Os times de precificação precisam do custo organizado de outra forma: por cliente, por linha de produto, por feature, pela unidade de uso que eles efetivamente cobram. Um export de billing não sabe qual cliente disparou qual workload. Não sabe que uma conta enterprise roda jobs de scan que consomem 40x mais compute do que qualquer outra no mesmo plano. Não sabe que sua feature de IA custa três vezes mais para power users do que para usuários casuais.
A camada de billing não tem esse contexto. Nunca teve. Ela foi feita para dizer aos provedores de nuvem quanto cobrar de você, não para te contar quanto custa rodar o workload de cada cliente.
Para responder essa pergunta, você precisa de uma fonte de dados totalmente diferente.
O que os dados de runtime mudam
Quando você instrumenta sua infraestrutura com base em dados de runtime, lendo o tráfego real, as chamadas de serviço reais e o consumo real de recursos conforme acontecem, o cenário de custos fica bem diferente.
Você consegue ver quais clientes estão puxando quais workloads. Consegue rastrear uma query de banco de dados até a feature que a disparou e, dali, até o cliente que a usou. Consegue observar recursos compartilhados como Kafka ou Elasticsearch e entender quais tenants estão consumindo quanto, sem precisar que os engenheiros taggeiem nada.
Isso não é uma capacidade teórica. Já existe, em produção, em empresas fazendo exatamente essa análise.
E o que elas descobrem?
A maioria descobre que o modelo mental que tinha da distribuição de custos estava errado. A diferença entre o consumidor mais leve e o mais pesado é maior do que se imaginava. Uma pequena porcentagem das contas, geralmente enterprise, geralmente no meio da sua pilha de planos, está consumindo num ritmo que faz o ARR delas parecer desconto.
Uma empresa encontrou 360 contas em que o cost-to-serve superava a receita. Exposição total: US$ 1,3 milhão em perdas anuais, invisíveis até que a atribuição em runtime mapeasse o custo de volta aos clientes. As perdas não estavam nas contas que qualquer um esperaria não serem lucrativas. Estavam escondidas em planos que pareciam ter um ARR saudável.
O problema da precificação de IA é uma prévia do que vem por aí
Esse tipo de compressão de margem está piorando, não melhorando.
Features de IA mudam a estrutura de custo de um produto SaaS de formas que a precificação por assento, ou mesmo por uso, muitas vezes não captura. Um agente de IA que executa um workflow de várias etapas não consome uma quantidade fixa de compute. O consumo depende da complexidade, do tamanho do input, de quantas ferramentas ele chama, de quantos tokens queima pelo caminho. Dois clientes usando a mesma feature de IA podem ter perfis de custo 10x diferentes.
Se o seu modelo de precificação trata os dois igual, um está bancando o outro.
As empresas que vão acertar a precificação de IA são as que conseguem enxergar consumo de tokens, ações de agentes e volume de tool calls no nível do cliente, e construir uma precificação que reflete essa realidade. Não por assento. Não por mil requisições. Estruturas de precificação que refletem os cost drivers reais do produto.
Isso exige dados de runtime. Não tem outro jeito de conseguir esse nível de granularidade.
O que isso destrava para os times de precificação
Você consegue identificar quais segmentos estão com margem negativa antes que eles apareçam em uma apresentação para o board. Consegue ver quais tiers de plano têm a maior variância de custo e desenhar limites de uso ou add-ons alinhados ao consumo real. Consegue testar o impacto na margem de uma nova capacidade antes de precificar e lançar, usando dados reais de baseline em vez de suposições modeladas.
Você também consegue construir modelos de precificação que antes eram impossíveis. A precificação por consumo deixa de ser aposta quando você sabe exatamente quanto custa entregar cada unidade de consumo. A precificação por valor se torna defensável quando você consegue mostrar quanto realmente gasta para gerar o resultado que está cobrando.
A era dos agentes torna isso ainda mais urgente. Se você cobra US$ 250 por tarefa concluída, precisa saber se aquela tarefa custou US$ 80 ou US$ 380 para rodar. A resposta muda tudo: quais workflows precificar mais alto, quais redesenhar, quais clientes são lucrativos ao seu preço atual. Sem dados de runtime, você está voando às cegas nas decisões de precificação mais importantes.
Você consegue finalmente responder à pergunta que os times de precificação sempre precisaram responder e raramente conseguiam: quanto custa, de verdade, entregar esse valor para esse cliente?
Com essa resposta na mão, a estratégia de precificação deixa de ser chute. Vira uma vantagem de negócio.
A pergunta a fazer na sua próxima revisão de precificação
Antes de discutir tiers de pacote ou gating de features, faça uma pergunta anterior a todas: nós realmente sabemos quanto custa atender cada cliente, cada plano, cada feature?
Se a resposta envolve planilhas e estimativas, o modelo de precificação está apoiado em uma base que não vai aguentar conforme o produto escala.
Comece pela realidade dos custos. Todo o resto vem depois.
O Attribute™ mapeia custos de infraestrutura de nuvem e IA para clientes, produtos e features usando dados de runtime, sem tagging. Veja como funciona para times de precificação.