Template de Preços SaaS: Tiers Prontos que Vendem

A maioria dos problemas de precificação SaaS não são problemas de preço. São problemas de estrutura — planos demais, sem métrica de valor clara, gatilhos de upgrade que parecem arbitrários, e uma página de preços que explica tudo menos por que alguém deveria pagar mais.

Esta página te dá a estrutura. Um template de modelo de preços SaaS de 3 tiers que você pode copiar, adaptar e publicar — com o raciocínio por trás de cada decisão para que você entenda o que mudar quando seu produto não encaixar no padrão. Para contexto sobre a gama completa de modelos de preços disponíveis, o guia minimalista cobre cada abordagem com exemplos reais.

O template: modelo de preços SaaS de 3 tiers

Esta é a estrutura mínima viável de preços para a maioria dos produtos SaaS self-serve.

Tabela de preços

Plano	Melhor para	Preço	Limite principal	Gatilho de upgrade
Starter	Uso solo / avaliação inicial	19€/mês	Cap de volume baixo	Primeiro marco de uso atingido
Growth	Usuários pagantes ativos	49€/mês	Cap de volume médio	Crescimento de volume / mais automação
Scale	Equipes / uso mais pesado	99€/mês	Cap de volume alto	Colaboração / escala avançada

Destaque o Growth como padrão. Deve ser visualmente distinto — a maioria dos visitantes avaliando seriamente vai aterrissar aqui. Starter é a entrada de baixo compromisso. Scale é para contas que já encontraram valor e precisam de mais.

Como os tiers devem se sentir para os clientes

Starter: “Consigo ter valor real disto antes de decidir pagar mais.” Não é um plano de punição. Não é uma demo mutilada. O suficiente para provar que o produto funciona.

Growth: “Este é o plano para quem realmente usa isso.” O melhor valor por unidade. Claramente a escolha certa para qualquer um sério. A maior parte da sua receita vem daqui.

Scale: “Para quando estou rodando isso em capacidade máxima.” Limites maiores, opcionalmente features de equipe ou colaboração. Deve parecer um passo natural seguinte, não um salto de preço repentino.

Quer saber se sua última mudança de preço realmente moveu o ARPU? Veja a decomposição de MRR por plano →

O modelo de preços por trás: como preencher o template

A tabela acima é o output. As escolhas abaixo determinam se ela realmente converte.

Passo 1: Escolha uma métrica de valor

A métrica de valor é a unidade pela qual os clientes pagam mais conforme obtêm mais valor. Ela impulsiona o limite que muda entre tiers e cria o gatilho de upgrade.

Bons exemplos de métrica de preço SaaS por tipo de produto:

Tipo de produto	Opções fortes de métrica de valor
Ferramenta de analytics / métricas	Contas conectadas, receita rastreada, fontes de dados
Ferramenta de IA / automação	Workflows concluídos, execuções de automação, documentos processados
API / ferramenta de dev	Requisições de API, minutos de computação, execuções de pipeline
Ferramenta de email / outreach	Contatos, e-mails enviados por mês
Ferramenta de projeto / ops	Projetos ativos, assentos ativos, boards
Ferramenta de billing / finanças	Faturas enviadas, assinaturas gerenciadas

O teste: você consegue completar esta frase? “Cobramos mais quando clientes [fazem mais X], porque [mais X significa mais valor].” Se não, a métrica não está clara o suficiente.

Para o framework completo sobre escolher uma métrica de valor, veja o guia dedicado sobre escolher uma unidade que esclarece tudo.

Passo 2: Defina limites que criam momentos naturais de upgrade

Os limites em cada tier devem ser calibrados para que:

Starter seja suficiente para atingir um primeiro resultado real (não apenas configurar a conta)
Growth acomode um cliente usando ativamente o produto no ritmo normal
Scale seja onde clientes acabam naturalmente conforme o negócio deles cresce

Uma heurística útil: olhe seus dados de uso ativo e encontre os clusters naturais de uso. Starter deve cobrir o quartil inferior de uso ativo. Growth deve cobrir a mediana. Scale lida com o topo.

Evite limites que parecem arbitrários (por que 1.000 exatamente?) ou que criam ansiedade (clientes perto do limite param de usar o produto para evitar atingir o cap em vez de fazer upgrade). Visibilidade dentro do produto — mostrando uso atual e em qual tier estão — remove a maior parte dessa ansiedade.

Segundo os benchmarks de preços SaaS da OpenView Partners, produtos com medidores de uso visíveis dentro do produto têm taxas de upgrade significativamente mais altas dos seus planos de entrada.

Passo 3: Decida quais features, se alguma, mudam entre planos

A métrica de valor impulsiona a progressão principal. Diferenças de features devem ser secundárias. Uma página de preços onde a distinção principal entre tiers é um checklist de 20 toggles de features é difícil de entender — os clientes não conseguem rapidamente dizer pelo que estão realmente pagando.

Features que faz sentido dividir por tiers:

Colaboração / assentos de equipe — se trabalho em equipe faz parte do valor do produto, dividir assentos por tier é natural
Profundidade de relatórios ou exports — analytics avançado, views de coorte ou exports de dados podem ficar no Growth/Scale
Integrações — se você tem múltiplos alvos de integração, limitar ao core no Starter é defensável
Nível de suporte — suporte prioritário no Scale é esperado; não bloqueie ajuda básica

Features que devem ficar em todos os tiers:

Funcionalidade core do produto — bloquear features críticas no Starter treina clientes a não confiar no produto
Baseline de segurança — não crie uma “versão segura” do produto
Onboarding básico — se você ajuda usuários do Starter a ter sucesso, eles fazem upgrade; se não, eles cancelam

Passo 4: Defina um gatilho de upgrade claro por tier

Cada fronteira de plano deve ter uma razão óbvia e auto-evidente para subir. O upgrade deve parecer conquistado, não forçado.

Starter → Growth: atingir o limite de uso, ou pronto para usar o produto a sério. No momento em que um cliente pensa “isso é realmente útil para meu trabalho real,” deveria estar a um clique do Growth.

Growth → Scale: crescimento de equipe, volume maior ou operações mais complexas. O gatilho deveria ser algo que o cliente escolheu (contratar um colaborador, lançar um novo produto, escalar uso) — não algo arbitrário.

Para a estrutura de packaging que torna gatilhos de upgrade visíveis e reduz a fadiga, o guia do sistema de 3 tiers cobre isso em detalhe.

Modelos de preços de assinatura SaaS: escolhendo a estrutura certa

O template de 3 tiers acima é packaging. O modelo de precificação por assinatura subjacente é uma escolha separada — ele determina como a receita escala com o crescimento de clientes.

Precificação tiered flat-rate (o que o template mostra): preço fixo por tier com limites definidos. Previsível para clientes, fácil de explicar, bom para self-serve. O modelo mais comum para SaaS bootstrapped e indie.

Precificação baseada em uso: clientes pagam por unidade consumida, com uma taxa base ou puro pay-as-you-go. Alinha custo com valor mas pode criar ansiedade de billing se a métrica é difícil de prever. Funciona bem para ferramentas de API e produtos de infraestrutura onde o uso é visível e estimável. Os guias de billing do Stripe Atlas cobrem a mecânica de implementação para billing baseado em uso.

Precificação por assento: preço escala com o número de usuários. Natural para ferramentas de colaboração e software de equipe. Mais fraco quando um power user gera a maior parte do valor.

Híbrido: uma taxa base de plano que inclui uma franquia de uso, mais um custo por unidade acima desse limite. Reduz ansiedade de billing enquanto mantém alinhamento com uso. Comum em ferramentas de email (base + por envio acima do incluído).

Para a maioria dos produtos SaaS de fundador solo e equipe pequena mirando o mercado indie hacker e estágio inicial: precificação tiered flat-rate é o ponto de partida com menor fricção. É previsível, comparável e direto de comunicar.

Template de modelo de receita SaaS em JSON

Para builders que querem documentar o modelo de preços em código ou docs internos — algo que pode realmente guiar uma config de billing, página de preços ou lógica de onboarding:

{
  "pricing_model": {
    "structure": "tiered_flat_rate",
    "primary_metric": "workflows_completed",
    "billing_intervals": ["monthly", "annual"],
    "annual_discount_pct": 20,
    "plans": [
      {
        "id": "starter",
        "name": "Starter",
        "price_monthly": 19,
        "price_annual_per_month": 15,
        "included_units": 200,
        "best_for": "Fundadores solo / avaliação inicial",
        "upgrade_trigger": "Limite de uso atingido ou pronto para uso sério"
      },
      {
        "id": "growth",
        "name": "Growth",
        "price_monthly": 49,
        "price_annual_per_month": 39,
        "included_units": 2000,
        "best_for": "Usuários pagantes ativos",
        "upgrade_trigger": "Crescimento de volume ou colaboração de equipe necessária",
        "highlighted": true
      },
      {
        "id": "scale",
        "name": "Scale",
        "price_monthly": 99,
        "price_annual_per_month": 79,
        "included_units": 10000,
        "best_for": "Equipes / operações mais pesadas"
      }
    ],
    "overage_policy": "prompt_to_upgrade",
    "downgrade_policy": "allowed_at_renewal"
  },
  "value_metric": {
    "name": "workflows_completed",
    "visible_in_product": true,
    "usage_warning_threshold_pct": 80
  }
}

O campo usage_warning_threshold_pct importa: mostrar aos clientes que estão em 80% do plano cria um momento de upgrade natural e de baixa pressão em vez de uma parede repentina.

NoNoiseMetrics como exemplo vivo

O NoNoiseMetrics usa a mesma estrutura de 3 tiers descrita acima, com contas Stripe conectadas como métrica de valor principal:

Plano	Preço	Contas Stripe	Para quem é
Free	0€/mês	1	Fundadores solo abaixo de 10K€ MRR
Indie	19€/mês	3	Produtos SaaS indie ativos
Pro	49€/mês	Ilimitado	Portfólios multi-produto e equipes

O gatilho de upgrade de Free para Indie é adicionar uma segunda conta Stripe — natural para fundadores que lançam um segundo produto ou querem separar ambientes. O gatilho de Indie para Pro é precisar de mais de 3 contas — o que acontece quando o produto está funcionando bem o suficiente para expandir.

Acesso vitalício a 299€ fica fora da estrutura recorrente e captura uma psicologia específica de comprador: fundadores que preferem posse a assinatura e estão dispostos a pagar antecipadamente por acesso permanente.

A pesquisa de preços do SaaStr confirma que um gatilho de upgrade visível e nativo do produto converte significativamente melhor do que comparações abstratas de plano — que é exatamente o que a métrica de contas conectadas alcança aqui.

Erros comuns em modelos de preços

Planos demais. Seis tiers cria paralisia de comparação. Três tiers cobre a gama completa de clientes — entrada, ativo, power — sem pedir aos visitantes que avaliem mais opções do que conseguem manter na memória de trabalho.

Sem métrica de valor clara. Se os clientes não conseguem dizer o que muda entre Starter e Growth sem ler uma tabela de comparação, o modelo de preços não tem espinha. Uma unidade clara de progressão resolve isso.

Sopa de features em vez de progressão por limites. Quarenta checkmarks numa tabela de preços obscurecem a razão principal para fazer upgrade. Lidere com a métrica; adicione diferenças de features como contexto secundário.

Fazer do Starter um tier de punição. Se o plano mais baixo não demonstra valor real do produto, os clientes não têm razão para confiar no caminho de upgrade. Starter deveria criar valor. Growth deveria expandi-lo.

Gatilhos de upgrade que parecem punitivos. Um limite que parece arbitrário ou injustamente baixo treina clientes a ressentir o preço em vez de esperar crescer para ele. Os melhores upgrades parecem conquistados.

Sem visibilidade de uso dentro do produto. Clientes que conseguem ver seu uso contra o limite do plano fazem upgrade proativamente. Clientes que descobrem que atingiram um limite inesperadamente ficam irritados. Este é um investimento de engenharia que se paga em conversão.

Transformando o template em uma página de preços

O modelo guia a página. Uma vez que o modelo está definido, a página em si é relativamente mecânica.

Headline: para quem é e o benefício principal. Mantenha específico do produto, não genérico (“simples” e “poderoso” não são benefícios).

Grid de preços: nomes dos planos, preço mensal, limite principal, 3–5 diferenças de features, opção de billing anual, um plano padrão destacado.

Copy de lógica de upgrade: uma linha por transição. “Passe para Growth quando precisar de mais de 200 workflows/mês.” Não mais vago que isso.

FAQ ou bloco de confiança: o que conta para o limite de uso, o que acontece quando atinge, se downgrade está disponível, e quais os termos do billing anual. Essas quatro perguntas respondem a maioria dos tickets de suporte sobre preços no estágio inicial.

Copy de CTA em cada plano: verbos, não substantivos. “Comece grátis” bate “Plano gratuito.” “Começar” no Growth. “Fale conosco” apenas se Scale é realmente enterprise — se é self-serve, dê um CTA real.

FAQ

O que é um template de modelo de preços SaaS?

Um template de modelo de preços SaaS é uma estrutura repetível de como um produto de assinatura é precificado — seus planos, a métrica de valor que impulsiona a progressão entre tiers, os limites que definem cada plano e a lógica de upgrade. É a arquitetura econômica por trás da página de preços, não apenas o layout visual.

Quantos tiers de preço um produto SaaS deve ter?

Três tiers é o padrão para SaaS self-serve: um tier de entrada de baixo compromisso, um tier padrão de crescimento e um tier de maior uso ou equipe. Menos de três limita a capacidade de capturar segmentos diferentes; mais de três cria fadiga de comparação.

Qual o melhor modelo de precificação por assinatura para SaaS?

Para a maioria dos produtos SaaS bootstrapped e indie, precificação tiered flat-rate — preço fixo por plano com um limite de uso definido — é o ponto de partida de menor fricção. Precificação baseada em uso funciona bem para produtos de API e infraestrutura onde clientes podem estimar seu consumo. Precificação por assento funciona melhor quando colaboração é o driver de valor principal.

O que deveria mudar entre tiers de preço?

Principalmente o limite da métrica de valor (mais daquilo que os clientes pagam conforme obtêm mais valor), secundariamente um pequeno número de diferenças de features. A razão principal para fazer upgrade deveria ser clara numa frase.

O que é um template de modelo de receita SaaS?

Um template de modelo de receita SaaS documenta como a receita recorrente é estruturada — tiers de preço, a métrica de valor, intervalos de billing (mensal vs anual), política de excedente e gatilhos de upgrade. É a lógica subjacente que uma página de preços apresenta aos clientes e que um sistema de billing implementa. A estrutura JSON neste artigo é um ponto de partida prático.

O que devo evitar numa página de preços?

Nomes vagos de plano (Basic, Pro, Enterprise quando você na verdade não vende enterprise), limites inexplicados, gatilhos de upgrade que parecem arbitrários e tabelas de preços com checkmarks demais obscurecendo a progressão principal. O objetivo é que um visitante novo entenda “pelo que estou pagando e quando deveria pagar mais” em menos de 30 segundos.

Depois de definir seu preço, você precisa saber se funciona. O NoNoiseMetrics rastreia ARPU e MRR por plano automaticamente. Conecte o Stripe →

Free Tool
Try the SaaS Pricing Calculator →
Interactive calculator — no signup required.