O recurso saiu de graça, e ninguém chamou isso de decisão
Uma startup de SaaS lança um assistente de IA dentro do produto. A pressão pra rodar rápido empurra o preço junto: o recurso entra no plano de sempre, sem cobrança extra, porque tirar do ar depois de anunciado dói mais do que cobrar por ele agora. Seis meses depois, o time de produto olha o uso. Metade dos clientes nem abriu a tela do assistente. Da outra metade, a maioria testou duas ou três vezes e parou. Ninguém decidiu não cobrar. Só empurrou o recurso pra dentro do que já existia e deixou a adoção resolver sozinha o que era, desde o início, uma decisão de preço.
Essa cena se repete em reunião de board, e agora tem número atrás dela.
O número que veio da pesquisa
Em 23 de junho de 2026, a consultoria Blue Ridge Partners apresentou os resultados de uma pesquisa com 128 CXOs de empresas de SaaS na América do Norte e na Europa, sobre como elas precificam os recursos de IA que colocaram no produto. O achado central: entre as empresas que cobram por IA, 79% converteram menos da metade dos clientes elegíveis para o plano pago. Não é que a maioria não cobre. É que quem cobra, cobra errado, ou cobra sem checar antes se o cliente queria pagar aquilo do jeito que foi oferecido.
A pesquisa também perguntou como cada empresa chegou no preço que cobra hoje. 71% responderam que usaram pesquisa informal, uma conversa solta com alguns clientes ou um benchmark de concorrente, em vez de medir disposição a pagar de forma estruturada. E 73% disseram não ter guardrail financeiro que trave ou revise o preço quando o custo de inferência sobe.
| O que a pesquisa achou | Percentual |
|---|---|
| Conversão abaixo de metade dos clientes elegíveis, entre quem cobra | 79% |
| Preço definido com pesquisa informal, sem medir disposição a pagar | 71% |
| Sem guardrail financeiro pra travar o preço quando o custo sobe | 73% |
| Compressão de margem por IA já é pauta de board ou investidor | 90% |
Por que isso não é decisão de produto
O time de produto mede uso, ativação, retenção, churn de feature. É o trabalho dele e ele faz bem. O que ele não decide sozinho, e não deveria decidir sozinho, é se aquele uso vira receita. Essa fronteira importa mais com IA do que importava com software tradicional, porque o custo de rodar o recurso é variável: cada chamada custa de novo, e o custo sobe junto com o sucesso do recurso, não dilui como hospedagem diluía.
Quando o founder trata o lançamento de um recurso de IA como decisão de produto, e não como decisão de preço, ele está, na prática, terceirizando pro time de engenharia uma escolha que devia estar na mesa do financeiro desde o dia zero.
A pergunta certa não é se vale lançar o recurso de IA. É quanto custa rodar aquilo e quanto a empresa cobra por ele antes de anunciar, não depois.
A pesquisa foi feita com empresas de SaaS americanas e europeias, mas o mecanismo vale igual aqui. Startup brasileira que empacota IA no plano sem separar o custo variável descobre a mesma coisa três meses depois, só que com um caixa menor pra absorver o susto e sem CFO dedicado pra levantar a bandeira antes de virar rombo.
O que fazer na segunda de manhã
Três coisas dão pra fazer sem esperar o próximo ciclo de planejamento.
Rodar uma pesquisa curta de disposição a pagar com 15 a 20 clientes reais antes de fixar o preço, perguntando quanto pagariam pelo recurso e o que cortariam do orçamento pra abrir espaço. Informal não é sinônimo de rápida: dá pra estruturar isso em uma semana, com perguntas fechadas e um roteiro simples.
Definir um número de uso, chamadas, tokens ou execuções, que aciona revisão de preço automaticamente quando é ultrapassado. Sem esse gatilho, o custo sobe solto até aparecer no relatório trimestral, quando já é tarde pra reagir sem drama.
Colocar a revisão de preço do recurso de IA na agenda do founder a cada trimestre, e não como pauta de quando sobrar tempo. O custo de inferência muda mais rápido do que o preço de SaaS tradicional costumava mudar, e a precificação precisa acompanhar esse ritmo, não correr atrás dele.
Mapear onde o custo variável mora e desenhar o preço antes de escrever a primeira linha do recurso é parte do que a Overflow cobre na implementação IA-first: diagnóstico antes de piloto, piloto antes de produção, preço decidido antes das duas coisas.
