Atualizado em: 20 de maio de 2026

Precificar um SaaS B2B brasileiro é uma decisão comercial e operacional. O preço passa por discovery, proposta, desconto, aprovação do comprador, contrato, PO, nota fiscal, cobrança, reajuste e renovação. Quando o modelo entra errado nessa cadeia, a receita vaza antes de chegar no caixa.

Modelo de preço é a regra que transforma valor entregue em receita cobrável. Em SaaS B2B, essa regra precisa ser vendável pelo time comercial, aceitável pelo comprador e executável pelo financeiro. O modelo pode ser por assento, plano, uso, crédito, transação, módulo, resultado ou contrato customizado.

Este guia organiza os principais modelos de precificação em SaaS, com foco em negócios sales-led no Brasil. PLG, cobrança por crédito e pré-pago aparecem quando fazem sentido, mas a espinha dorsal é a venda consultiva: ticket, proposta, negociação, contrato e operação de cobrança.

O que é um modelo de precificação em SaaS?

Modelo de precificação em SaaS é a regra que define como o cliente paga pelo software. Ele pode pagar por usuário, por plano, por volume de uso, por transação, por resultado, por módulo, por contrato ou por uma combinação desses elementos.

Estratégia de preço define o posicionamento: barato para ganhar mercado, premium para vender valor, land and expand para entrar pequeno e crescer, enterprise para vender contrato grande com implantação. O modelo é a mecânica de cobrança. A estratégia é a tese comercial por trás dela.

Essa distinção importa porque duas empresas podem usar o mesmo modelo e operar negócios muito diferentes. Slack e Jira têm cobrança por usuário em planos. Mas um vende colaboração horizontal; o outro vende gestão de trabalho para times técnicos e áreas de negócio. O modelo é parecido. O motivo de compra, o ticket e a expansão são diferentes.

No Brasil, o padrão B2B é sales-led

No SaaS B2B brasileiro, o canal mais comum para tickets relevantes é sales-led. O cliente pede conversa, compara alternativas, envolve finanças, jurídico, operação e tecnologia, negocia escopo, pede condição de pagamento e espera uma proposta formal.

Esse contexto muda a precificação. Um modelo bonito para checkout self-service pode quebrar quando entra contrato anual, parcelamento, PO, múltiplas entidades, CNPJ diferente para faturamento, reajuste por índice, implantação, desconto por volume e regra de renovação.

Por isso, o modelo de preço precisa responder quatro perguntas antes da página pública:

  • Como vendas explica a unidade de valor? Assento, uso, crédito, módulo, contrato ou resultado.
  • Como o comprador defende o preço internamente? ROI, redução de custo, crescimento, governança ou risco.
  • Como o contrato registra a regra? Quantidade, mínimo contratado, excedente, reajuste, prazo, SLA e exceções.
  • Como o financeiro cobra sem reconstruir a proposta? NF, boleto, Pix, cartão, parcelamento, conciliação e renovação.

PLG existe no Brasil, principalmente em ferramenta horizontal, dev tool, produto de baixo ticket e compra por cartão. Mas, em SaaS B2B com ticket médio ou alto, PLG costuma funcionar como entrada. A monetização principal continua em vendas assistidas, expansão de conta e contrato anual.

Os principais modelos de precificação em SaaS

Empresas maduras combinam modelos. O padrão mais comum é híbrido: plano base mais assentos, uso excedente, créditos, add-ons ou contrato enterprise. Entender cada modelo isolado deixa o ponto de partida mais claro.

  • Flat-rate — Como cobra: Um preço fixo por conta ou workspace — Melhor quando: Produto simples, custo marginal baixo, comprador quer previsibilidade — Risco principal: Deixar dinheiro na mesa em contas grandes — Exemplos públicos: Basecamp
  • Tiered — Como cobra: Planos por pacote de funcionalidades — Melhor quando: SaaS horizontal ou com segmentos claros — Risco principal: Plano confuso, features mal distribuídas — Exemplos públicos: Slack, Jira, Intercom
  • Per-seat — Como cobra: Valor por usuário ou assento — Melhor quando: Valor cresce com adoção do time — Risco principal: Cliente restringe usuários para economizar — Exemplos públicos: Slack, Jira, Intercom
  • Usage-based — Como cobra: Valor por consumo — Melhor quando: Uso acompanha valor percebido — Risco principal: Receita imprevisível e cobrança difícil — Exemplos públicos: Datadog, Twilio, Snowflake
  • Transaction/take-rate — Como cobra: Percentual ou taxa por transação — Melhor quando: Plataforma participa do fluxo financeiro do cliente — Risco principal: Sensibilidade alta a margem e volume — Exemplos públicos: Marketplaces e plataformas com transação rastreável
  • Freemium — Como cobra: Plano gratuito com upgrade pago — Melhor quando: Entrada PLG em produto horizontal — Risco principal: Base grátis grande com baixa conversão — Exemplos públicos: Slack, Jira
  • Free trial — Como cobra: Teste por tempo limitado — Melhor quando: Trial assistido por vendas ou produto simples — Risco principal: Trial sem onboarding vira curiosidade — Exemplos públicos: Intercom, vários SaaS B2B
  • Modular/add-on — Como cobra: Módulos pagos além do plano base — Melhor quando: Plataforma com produtos adjacentes — Risco principal: Bundle complexo e difícil de comparar — Exemplos públicos: Intercom, Datadog
  • Créditos pré-pagos — Como cobra: Pacote de consumo pago antes do uso — Melhor quando: AI, enriquecimento, automação, API e dados — Risco principal: Crédito sem lastro claro vira confusão — Exemplos públicos: Produtos de AI, dados e dev tools
  • Outcome-based — Como cobra: Cobra por resultado entregue — Melhor quando: Resultado é mensurável e auditável — Risco principal: Disputa sobre atribuição do resultado — Exemplos públicos: Intercom Fin
  • Enterprise custom — Como cobra: Contrato negociado — Melhor quando: Alto ticket, compliance, implantação, SLAs — Risco principal: Ciclo longo e muita exceção operacional — Exemplos públicos: Jira Enterprise, Datadog Enterprise

1. Flat-rate: preço fixo para simplificar a decisão

Flat-rate é o modelo em que a empresa cobra um valor fixo por conta, normalmente com uso amplo ou ilimitado dentro de limites razoáveis. Ele reduz fricção comercial porque o comprador entende o custo antes de falar com vendas.

Funciona melhor quando o produto tem custo marginal baixo, o uso não varia drasticamente entre clientes e a empresa quer competir contra ferramentas cobradas por usuário. Também funciona bem quando o comprador odeia administrar assentos, como agências, consultorias, operações com freelancers e empresas com muitos convidados externos.

O ponto fraco é a captura de valor. Se uma conta com 20 pessoas paga o mesmo que uma conta com 400 pessoas, a empresa precisa aceitar que parte do valor criado ficará com o cliente. Isso pode ser uma escolha estratégica, mas precisa ser consciente.

Ticket map ideal: baixo a médio. De R$ 100 a R$ 2.000 por mês em produtos simples. No Brasil, acima disso o flat-rate costuma precisar de venda assistida, proposta e contrato anual para sustentar margem.

Bom para: ferramentas de produtividade, gestão de projeto simples, colaboração leve, produtos para agências, produtos com baixo custo computacional.

Ruim para: infraestrutura, AI com custo variável alto, produtos com grande diferença de valor entre contas pequenas e grandes.

Exemplo: Basecamp comunica um pacote com usuários ilimitados por preço fixo, além de opção por usuário em outro plano. A tese é previsibilidade e simplicidade para times que não querem pagar uma fatura maior a cada pessoa adicionada.

2. Tiered pricing: planos para capturar disposição a pagar

Tiered pricing organiza a oferta em planos. O formato clássico tem três ou quatro níveis: Free ou Starter, Pro ou Business, Advanced ou Enterprise. Cada plano combina limites, funcionalidades, suporte, governança e volume.

É o modelo mais fácil de entender para o comprador e um dos mais flexíveis para o vendedor. Em venda consultiva, os planos funcionam como matriz de proposta: o vendedor ancora o escopo, explica o upgrade e negocia desconto sem redesenhar o produto inteiro. Um cliente pequeno entra no plano inicial. Um cliente em crescimento sobe para o plano intermediário. Uma empresa maior vai para o plano enterprise com segurança, administração, suporte, SLA e contrato.

O erro comum é empilhar funcionalidades sem lógica. Um bom plano traduz o estágio do cliente. O plano de entrada prova valor. O plano principal captura a maioria da receita. O enterprise captura risco, governança e complexidade.

Ticket map ideal: amplo. Funciona de R$ 50 por mês até contratos enterprise de seis dígitos por ano, desde que os planos tenham upgrade triggers claros e uma política comercial que vendas consiga defender.

Bom para: SaaS horizontal, CRM, colaboração, gestão de trabalho, atendimento, marketing, analytics.

Ruim para: produtos em que o valor é quase totalmente proporcional ao consumo, como API, logs, processamento, infraestrutura e alguns produtos de AI.

Exemplos: Slack publica planos Free, Pro, Business+ e Enterprise Grid. Jira combina Free, Standard, Premium e Enterprise, com cobrança por usuário e limites de armazenamento, automação, suporte e governança.

3. Per-seat: cobra onde a adoção acontece

Per-seat pricing cobra por usuário, agente, colaborador ou assento. É natural em produtos cujo valor cresce com o número de pessoas trabalhando dentro da ferramenta.

O modelo é forte porque conecta expansão de receita com expansão organizacional. Se o produto começa em um time e se espalha para outros, a receita cresce sem renegociação estrutural. Esse é o motor clássico de colaboração, gestão de projeto, CRM, suporte e produtividade.

O problema é que assento nem sempre representa valor. Em alguns produtos, muitos usuários entram raramente. Em outros, o cliente quer convidar pessoas externas, mas evita porque cada assento aumenta a fatura. Quando isso acontece, o preço vira atrito para adoção.

Ticket map ideal: baixo a alto, dependendo do ACV. Em low-ticket, o assento pode entrar no checkout. Em mid-market e enterprise, per-seat aparece dentro de contrato anual negociado, com quantidade mínima, regra de true-up e data de renovação.

Bom para: colaboração, CRM, helpdesk, project management, sales engagement, BI com muitos usuários internos.

Ruim para: produtos em que poucos operadores geram muito valor para a empresa inteira, como billing, observability, APIs, automação de backoffice e AI agents.

Exemplos: Slack cobra planos pagos por usuário. Jira calcula custo a partir do número de usuários. Intercom combina preço por assento com componentes de uso em canais e AI.

4. Usage-based: o cliente paga pelo que consome

Usage-based pricing cobra por consumo: chamadas de API, eventos processados, logs indexados, mensagens, créditos, GB, hosts, minutos, tokens ou volume financeiro. O argumento é simples: quem usa mais, paga mais.

Esse modelo combina bem com infraestrutura e produtos técnicos porque o uso costuma acompanhar valor. Se a empresa envia mais mensagens, monitora mais hosts, consome mais créditos ou processa mais dados, o software está no caminho do crescimento dela.

No Brasil, usage-based puro costuma gerar desconforto em tickets médios e altos. O comprador quer previsibilidade para aprovar orçamento. Por isso, o desenho mais comum em sales-led é commit mínimo mensal ou anual, franquia de uso, desconto por volume e cobrança de excedente.

O modelo exige maturidade operacional. O cliente precisa prever custo. O time financeiro precisa fechar o mês com metering confiável. O produto precisa mostrar uso em tempo real. Vendas precisa explicar a conta antes de o cliente receber a fatura.

Ticket map ideal: de baixo a enterprise. Em baixo ticket, funciona com limite, crédito ou calculadora simples. Em contas sales-led, funciona melhor com commit mínimo anual, desconto por volume e overage controlado.

Bom para: APIs, infraestrutura, observability, data, AI, telecom, storage, automação com alto custo variável.

Ruim para: produtos em que o cliente valoriza previsibilidade acima de elasticidade, ou onde o uso não se conecta claramente ao resultado de negócio.

Exemplos: Datadog precifica vários produtos por dimensões de uso, como host, eventos, logs e spans, dependendo do módulo. Twilio cobra mensagens e voz por unidades de consumo, como segmento de SMS e minuto de chamada. Snowflake calcula custo a partir de recursos como compute, storage e data transfer.

5. Transaction ou take-rate: quando o SaaS participa da receita do cliente

No modelo transaction-based, a empresa cobra uma taxa fixa, um percentual ou uma combinação dos dois por transação. Em take-rate, a empresa captura uma parte do volume financeiro processado.

Esse modelo é poderoso quando o SaaS opera perto de um evento econômico rastreável: pedido, reserva, repasse, entrega, cotação, contratação, emissão, crédito ou outra transação que o cliente já mede. O cliente aceita melhor pagar sobre transação quando o software está diretamente ligado a um evento de receita, custo ou operação.

O risco é a margem. Quanto maior o volume do cliente, mais ele negocia. Em contas grandes, poucos basis points importam. Por isso, transaction pricing costuma migrar para contrato customizado em enterprise.

Ticket map ideal: muito amplo. Em SMB, o cliente começa sem contrato grande. Em enterprise, o ticket vira volume financeiro anual multiplicado por taxa negociada.

Bom para: marketplaces, commerce enablement, fiscal, logística, procurement, reservas, crédito e operações com transação rastreável.

Ruim para: produtos cuja contribuição para a transação é indireta ou difícil de provar.

Exemplos: marketplaces B2B, plataformas de procurement, ferramentas de logística e sistemas de reservas costumam combinar assinatura, taxa fixa ou percentual sobre transações. Nesses casos, a unidade econômica é o pedido, a reserva, a entrega ou a contratação concluída.

6. Créditos pré-pagos: consumo com caixa antes do uso

Créditos pré-pagos transformam uso futuro em pacote comprado antes do consumo. O cliente compra 10 mil créditos, 100 mil chamadas, 500 análises, 1 milhão de tokens ou um saldo para automações. Cada ação consome parte desse saldo.

O modelo ganhou força com AI, enriquecimento de dados, APIs e automações com custo variável. Ele reduz surpresa na fatura, melhora caixa e dá ao comprador um limite orçamentário claro. Em sales-led, créditos costumam aparecer junto de contrato anual: o cliente compra um pacote, recebe desconto por volume e renova quando o saldo acaba ou no ciclo contratual.

O cuidado está na definição do crédito. Um crédito precisa representar uma unidade compreensível. Se cada ação consome uma quantidade diferente sem explicação, o cliente sente que comprou uma moeda interna sem lastro.

Ticket map ideal: baixo a enterprise. Em PLG, o crédito funciona como recarga. Em sales-led, funciona como commit pré-pago com volume, desconto e regra de expiração.

Bom para: AI, APIs, dados, enriquecimento, automação operacional, dev tools, processamento e produtos com custo marginal claro.

Ruim para: produtos em que o uso é difícil de prever ou em que o cliente quer orçamento fixo sem acompanhar saldo.

7. Freemium: distribuição antes da monetização

Freemium oferece uma versão gratuita sem prazo final. O objetivo é reduzir a barreira de adoção, criar hábito e transformar parte da base em clientes pagos quando ela encontra limites.

Esse modelo funciona quando o produto tem custo marginal baixo, ativação rápida e potencial de expansão orgânica. O usuário começa sozinho, convida o time, cria dados dentro do produto e encontra um limite natural: histórico, usuários, integrações, automação, permissões, armazenamento ou governança.

Freemium funciona como canal de aquisição, principalmente em produto horizontal. Em SaaS B2B brasileiro, ele costuma ser entrada para times pequenos. A monetização de contas médias e grandes vem depois, com venda assistida, expansão e contrato anual. O plano grátis precisa ser útil o suficiente para gerar adoção e limitado o suficiente para criar upgrade.

Ticket map ideal: baixo ticket e PLG. Em geral, produtos que começam abaixo de R$ 500 por mês e depois expandem para times via vendas assistidas.

Bom para: colaboração, produtividade, ferramentas dev, design, documentação, analytics leve, produtos com viralidade interna.

Ruim para: produtos com implantação pesada, COGS alto, venda consultiva ou valor que só aparece depois de integração complexa.

Exemplos: Slack tem plano Free com limites e planos pagos por usuário. Jira oferece plano gratuito para até certo número de usuários e planos pagos conforme escala.

8. Free trial: compromisso baixo, urgência alta

Free trial dá acesso ao produto por um período, normalmente 7, 14 ou 30 dias. Diferente do freemium, o trial tem fim. Isso cria urgência e força o produto a demonstrar valor rápido.

Funciona bem quando o produto precisa de experiência prática para ser entendido. Em sales-led, o trial funciona melhor como etapa do processo comercial: diagnóstico, setup guiado, critérios de sucesso, reunião de avaliação e proposta logo depois do valor demonstrado.

O erro é liberar trial sem guiar o usuário. Se o cliente entra, não configura nada e volta 12 dias depois, a conversão será baixa. Trial bom tem "aha moment" desenhado.

Ticket map ideal: baixo a médio em produto simples, médio a alto no sales-assisted. Em enterprise, o equivalente costuma ser piloto ou prova de conceito, com escopo, prazo e critérios de sucesso.

Bom para: atendimento, CRM, automação, BI, ferramentas de marketing, produtos com setup simples.

Ruim para: plataformas que exigem migração, dados sensíveis, integração profunda ou decisão de múltiplos stakeholders antes de qualquer valor aparecer.

Exemplo: Intercom oferece trial em seus planos e combina o acesso com cálculo de seats, AI e componentes de uso.

9. Modular e add-on: plataforma que expande por adjacência

No modelo modular, o cliente compra uma base e adiciona módulos. Isso aparece quando o produto vira plataforma: suporte mais AI, observability mais logs, CRM mais marketing automation, billing mais revenue recognition, e-commerce mais POS.

O modelo é bom para land and expand porque cada módulo abre uma nova frente de monetização. Também evita empacotar tudo no plano principal e encarecer a entrada para clientes que precisam só de um pedaço.

O risco é virar cardápio ilegível. Se cada módulo tem uma métrica, um limite, um contrato e uma exceção, o cliente não entende a fatura e o time financeiro sofre no fechamento.

Ticket map ideal: médio a enterprise. Em low-ticket, muitos add-ons aumentam fricção. Em enterprise, módulos dão flexibilidade para negociação.

Bom para: plataformas horizontais, suítes de atendimento, observability, marketing, sales, ERP SaaS, products-led que viraram multi-produto.

Ruim para: produto jovem sem core claro. Antes de vender módulo, a empresa precisa saber qual é o produto principal.

Exemplos: Intercom lista add-ons e cobranças de uso além dos seats. Datadog organiza preços por produtos, como infraestrutura, APM, logs e segurança, cada um com métrica própria.

10. Outcome-based: cobrar pelo resultado validado

Outcome-based pricing cobra quando um resultado acontece. A empresa cobra por resolução, conversão, economia, lead qualificado, resposta correta ou outra unidade de resultado.

Com AI, esse modelo ficou mais relevante. Se um agente resolve conversas, classifica documentos, gera cobranças ou fecha tarefas operacionais, o cliente pode preferir pagar por resultado validado. A conversa muda de "quanto custa um assento" para "quanto custa resolver um caso".

O modelo exige definição precisa do resultado. Quem confirma que resolveu? Qual janela conta? O que acontece se o cliente discordar? Como evitar cobrança duplicada? Sem resposta para isso, outcome-based vira briga de fatura.

Ticket map ideal: médio a enterprise, ou low-ticket com unidade extremamente simples. Quanto maior o impacto financeiro do resultado, mais o cliente aceita pagar.

Bom para: AI agents, suporte, cobrança, vendas, automação operacional, backoffice, risk, compliance, enriquecimento de dados.

Ruim para: produtos em que o resultado depende demais de fatores externos ou não pode ser auditado.

Exemplo: Intercom precifica o Fin AI Agent por outcome, além dos seats da suíte de atendimento. A página define outcome como resolução confirmada, ausência de nova solicitação depois da resposta ou conclusão de workflow.

11. Enterprise custom: quando preço vira contrato

Enterprise custom combina negociação, commit, SLA, segurança, termos jurídicos, implantação, suporte, integrações e governança.

Ele aparece quando o comprador precisa de procurement, compliance, DPA, SSO, auditoria, múltiplas entidades, faturamento anual, PO, condição de pagamento e limites contratuais. Nesse cenário, o preço público vira referência. O contrato real nasce da combinação entre escopo, risco e valor.

O erro é levar exceção enterprise para dentro do produto sem estrutura. Cada contrato customizado precisa virar regra operável: preço, ciclo, desconto, reajuste, uso, limite, cobrança, nota, renovação e reconhecimento.

Ticket map ideal: alto. Normalmente ACV acima de R$ 100 mil por ano no Brasil, ou acima de US$ 25 mil a US$ 50 mil por ano em mercados globais, dependendo da categoria.

Bom para: SaaS mission-critical, segurança, infraestrutura, dados, financeiro, billing, ERP, enterprise workflow, produtos com integração profunda.

Ruim para: produto simples que ainda não provou repetibilidade. Enterprise cedo demais transforma produto em consultoria.

Exemplos: Jira, Datadog, Slack e Intercom têm planos enterprise ou caminhos de contato comercial para necessidades maiores.

Mapa de ticket: qual modelo funciona melhor em cada faixa

Ticket map conecta modelo de preço, canal de venda e operação de cobrança. As faixas abaixo servem como mapa para SaaS B2B no Brasil, com foco em venda consultiva e expansão de conta.

  • R$ 0 a R$ 500/mês — Canal mais comum: PLG ou self-service — Modelos que costumam funcionar: Freemium, créditos pré-pagos, flat-rate baixo, tiered simples — O que o cliente espera: Começar sem reunião — Atenção operacional: Checkout simples, cartão ou Pix, limites claros
  • R$ 500 a R$ 5 mil/mês — Canal mais comum: Inside sales ou venda assistida — Modelos que costumam funcionar: Tiered, per-seat, flat-rate, pacotes de uso — O que o cliente espera: Proposta simples, NF e condição de pagamento — Atenção operacional: Pro-rata, upgrade, downgrade e cobrança recorrente
  • R$ 5 mil a R$ 30 mil/mês — Canal mais comum: Sales-led — Modelos que costumam funcionar: Tiered anual, per-seat anual, hybrid, módulos, commit de uso — O que o cliente espera: ROI, onboarding, contrato e aprovação financeira — Atenção operacional: Desconto, PO, parcelas, reajuste e renovação
  • R$ 30 mil a R$ 100 mil/mês — Canal mais comum: Enterprise — Modelos que costumam funcionar: Custom, commit de uso, módulos, SLA — O que o cliente espera: Segurança, governança, auditoria e suporte — Atenção operacional: Contrato vira regra de billing
  • R$ 100 mil+/mês — Canal mais comum: Strategic enterprise — Modelos que costumam funcionar: Custom, take-rate, commit anual, outcome-based — O que o cliente espera: Negociação financeira e jurídica — Atenção operacional: Revenue operations precisa operar como sistema

Ticket baixo exige simplicidade. Ticket alto tolera complexidade quando ela está conectada a valor, risco e controle.

Um SaaS de R$ 99 por mês precisa de uma métrica simples. Um contrato de R$ 1 milhão por ano pode ter commit, overage, desconto por volume, SLA e módulos. O cliente enterprise compra software, previsibilidade operacional, governança e risco reduzido.

Como escolher o modelo certo

A unidade de valor vem primeiro. O cliente aceita pagar melhor quando reconhece que aquela métrica cresceu junto com o benefício: usuários ativos, volume processado, créditos consumidos, módulos contratados, casos resolvidos ou contrato customizado.

Use este roteiro:

  • Identifique a unidade de valor. Usuário, conta, transação, volume, resultado, ativo monitorado, receita processada ou contrato.
  • Meça o custo marginal. Se cada uso custa caro, flat-rate ilimitado pode destruir margem.
  • Defina o canal. PLG pede preço simples. Sales-led aceita mais nuance, mas exige proposta clara, contrato e governança.
  • Defina upgrade triggers. O cliente sobe de plano por uso, time, recurso, compliance, suporte ou resultado?
  • Proteja o core value. Não tranque a principal entrega no plano caro. Tranque escala, governança, automação, suporte e risco.
  • Simule contas reais. Pegue 20 clientes ou prospects e calcule quanto pagariam em cada modelo.
  • Teste a fatura antes da página. Se o financeiro não explica a cobrança, o cliente também não entende.

Modelos bons por tipo de SaaS

  • Colaboração e produtividade — Modelo recomendado: Freemium + per-seat + tiers — Canal típico no Brasil: PLG com expansão assistida — Por quê: Adoção começa individual e expande por time
  • CRM, atendimento e RevOps — Modelo recomendado: Per-seat + tiers + add-ons — Canal típico no Brasil: Inside sales e sales-led — Por quê: Valor cresce com usuários, workflows e governança
  • API e infraestrutura — Modelo recomendado: Usage-based + commit mínimo — Canal típico no Brasil: Sales-assisted técnico — Por quê: Uso acompanha valor e custo
  • Observability e data — Modelo recomendado: Usage-based + módulos + enterprise — Canal típico no Brasil: Enterprise — Por quê: Métricas de consumo variam por produto
  • Commerce enablement e marketplace — Modelo recomendado: Assinatura + transaction/take-rate — Canal típico no Brasil: Sales-led — Por quê: Software participa de uma transação rastreável
  • AI agents operacionais — Modelo recomendado: Créditos, outcome-based ou usage-based com teto — Canal típico no Brasil: Sales-led com piloto — Por quê: Valor aparece em tarefas resolvidas, tokens ou volume
  • Billing e contas a receber — Modelo recomendado: Custom ou hybrid por complexidade — Canal típico no Brasil: Sales-led — Por quê: Cada contrato pode ter regras próprias de cobrança
  • Produto simples para SMB — Modelo recomendado: Flat-rate ou tiered simples — Canal típico no Brasil: Self-service ou inside sales — Por quê: Comprador quer previsibilidade e decisão rápida
  • Plataforma multi-produto — Modelo recomendado: Plano base + módulos — Canal típico no Brasil: Sales-led — Por quê: Expansão vem por adjacência

O melhor modelo é aquele que cria três alinhamentos ao mesmo tempo: o cliente entende por que paga, vendas consegue explicar sem exceção e o financeiro consegue cobrar sem reconstruir o contrato todo mês.

Erros comuns em precificação SaaS

O primeiro erro é copiar o modelo de uma empresa maior sem copiar o contexto. Usage-based funciona para infraestrutura porque consumo e valor andam juntos. Em um SaaS administrativo, pode parecer punição por usar o produto.

O segundo erro é usar per-seat quando o valor não depende de usuários. Se três pessoas operam uma plataforma que economiza R$ 500 mil por ano, cobrar só por assento reduz o preço justo.

O terceiro erro é criar planos por feature interna, não por estágio do cliente. O comprador não acorda querendo "feature avançada". Ele quer resolver um problema maior, com mais escala, mais segurança ou menos risco.

O quarto erro é subestimar billing. Quanto mais sofisticado o pricing, mais robusto precisa ser o motor de cobrança. O modelo pode estar correto na planilha e errado na operação.

Como a Aira opera pricing complexo

Se o seu modelo de preço cabe em uma linha, a cobrança é simples. Se envolve plano, assento, uso, desconto, mínimo contratado, overage, reajuste, pro-rata, PO, NF, multa, crédito e renovação, pricing vira operação de receita.

A Aira lê contratos, versiona regras comerciais, calcula cobrança, emite faturas, reconcilia pagamento e mostra a origem de cada valor cobrado. Preço por uso entra como uso. Assento entra como assento. Desconto entra como regra. Reajuste entra no ciclo certo. Cada centavo aponta para contrato, cláusula, consumo e fatura.

Pricing bom aumenta receita. Billing frágil perde parte dela no caminho.

FAQ

Qual é o melhor modelo de precificação para SaaS?

O melhor modelo acompanha a unidade de valor que o cliente reconhece. SaaS de colaboração tende a funcionar bem com per-seat e freemium. Infraestrutura tende a funcionar melhor com uso. Enterprise complexo tende a exigir contrato customizado.

Quando usar usage-based pricing?

Use usage-based quando consumo, valor e custo marginal caminham juntos. APIs, logs, mensagens, AI, dados e infraestrutura costumam encaixar bem. Para clientes que precisam de previsibilidade absoluta, commit mínimo e pacote de uso costumam funcionar melhor que fatura aberta.

Quando usar per-seat pricing?

Use per-seat quando cada usuário adicional recebe valor real e aumenta adoção dentro da empresa. Produtos de colaboração, CRM, atendimento e gestão de trabalho são bons candidatos. Quando poucos operadores geram valor para toda a organização, contrato, uso, crédito ou resultado costumam capturar melhor a disposição a pagar.

Freemium é melhor que free trial?

Freemium é melhor quando o produto tem baixo custo marginal, uso recorrente e viralidade. Free trial é melhor quando o produto precisa demonstrar valor em um período curto e tem onboarding claro. Produto complexo demais para ativar sozinho costuma converter melhor com piloto ou venda assistida.

Como precificar um SaaS B2B enterprise?

Comece pela unidade de valor, estime ROI, defina commit mínimo, separe módulos, documente SLAs e transforme cada termo comercial em regra de cobrança. Em enterprise, o preço continua depois do contrato: ele precisa rodar no billing sem depender de planilha manual.

Fontes consultadas