Modello Prezzi SaaS: Template con Tier Che Vendono

La maggior parte dei problemi di pricing SaaS non sono problemi di prezzo. Sono problemi di struttura — troppi piani, nessuna metrica di valore chiara, trigger di upgrade che sembrano arbitrari e una pricing page che spiega tutto tranne perché qualcuno dovrebbe pagare di più.

Questa pagina ti dà la struttura. Un template di modello prezzi SaaS a 3 tier che puoi copiare, adattare e spedire — con il ragionamento dietro ogni decisione così capisci cosa cambiare quando il tuo prodotto non si adatta al default. Per il contesto sulla gamma completa dei modelli di pricing disponibili, la guida minimalista copre ogni approccio con esempi reali.

Il template: modello prezzi SaaS a 3 tier

Questa è la struttura di pricing minima fattibile per la maggior parte dei prodotti SaaS self-serve.

Tabella prezzi

Piano	Ideale per	Prezzo	Limite core	Trigger upgrade
Starter	Uso singolo / prima valutazione	€19/mese	Cap volume basso	Primo milestone di utilizzo raggiunto
Growth	Utenti paganti attivi	€49/mese	Cap volume medio	Crescita volume / più automazione
Scale	Team / utilizzo più intenso	€99/mese	Cap volume alto	Collaborazione / scala avanzata

Evidenzia Growth come default. Dovrebbe essere visivamente distinto — la maggior parte dei visitatori che valutano seriamente atterreranno qui. Starter è l’entry a basso impegno. Scale è per gli account che hanno già trovato valore e hanno bisogno di più.

Come i tier dovrebbero sembrare ai clienti

Starter: “Posso ottenere valore reale da questo prima di decidere di pagare di più.” Non un piano punizione. Non una demo menomata. Abbastanza per dimostrare che il prodotto funziona.

Growth: “Questo è il piano per chi usa davvero questo strumento.” Il miglior rapporto valore per unità. Chiaramente la scelta giusta per chiunque sia serio. La maggior parte della tua revenue viene da qui.

Scale: “Per quando lo sto usando a piena capacità.” Limiti più grandi, opzionalmente feature di team o collaborazione. Dovrebbe sembrare un passo naturale successivo, non un salto di prezzo improvviso.

Ti chiedi se il tuo ultimo cambio di prezzo ha realmente spostato l’ARPU? Vedi il breakdown MRR per piano →

Il modello di pricing sottostante: come compilare il template

La tabella sopra è l’output. Le scelte sotto determinano se converte realmente.

Step 1: Scegli una metrica di valore

La metrica di valore è l’unità per cui i clienti pagano di più man mano che ottengono più valore. Guida il limite che cambia tra i tier e crea il trigger di upgrade.

Buoni esempi di metrica di pricing SaaS per tipo di prodotto:

Tipo di prodotto	Opzioni forti di metrica di valore
Tool analytics / metriche	Account connessi, revenue tracciata, sorgenti dati
Tool AI / automazione	Workflow completati, esecuzioni automazione, documenti processati
Tool API / developer	Richieste API, minuti di compute, esecuzioni pipeline
Tool email / outreach	Contatti, email inviate al mese
Tool progetto / operations	Progetti attivi, seat attivi, board
Tool billing / finance	Fatture inviate, subscription gestite

Il test: riesci a completare questa frase? “Facciamo pagare di più quando i clienti [fanno più X], perché [più X significa più valore].” Se no, la metrica non è abbastanza chiara.

Per il framework completo sulla scelta di una metrica di valore, vedi la guida dedicata sulla scelta di un’unità che rende tutto ovvio.

Step 2: Imposta limiti che creano momenti di upgrade naturali

I limiti in ogni tier dovrebbero essere calibrati così che:

Starter è sufficiente per raggiungere un primo risultato reale (non solo configurare l’account)
Growth copre un cliente che usa attivamente il prodotto a ritmo normale
Scale è dove i clienti finiscono naturalmente man mano che il loro business cresce

Un’euristica utile: guarda i tuoi dati di utenti attivi e trova i cluster naturali di utilizzo. Lo Starter dovrebbe coprire il quartile inferiore dell’uso attivo. Growth dovrebbe coprire la mediana. Scale gestisce il top.

Evita limiti che sembrano arbitrari (perché esattamente 1.000?) o che creano ansia (i clienti vicini al limite smettono di usare il prodotto per evitare di raggiungere il cap piuttosto che fare upgrade). La visibilità in-product — mostrare l’utilizzo attuale e su quale tier si trovano — rimuove la maggior parte di quell’ansia.

Secondo i benchmark di pricing SaaS di OpenView Partners, i prodotti con misuratori di utilizzo visibili in-product vedono tassi di upgrade significativamente più alti dai loro piani entry.

Step 3: Decidi quali feature, se ce ne sono, cambiano tra i piani

La metrica di valore guida la progressione primaria. Le differenze di feature dovrebbero essere secondarie. Una pricing page dove la distinzione principale tra i tier è una checklist di 20 toggle di feature è difficile da interpretare — i clienti non riescono a capire velocemente per cosa stanno realmente pagando.

Feature che ha senso differenziare per tier:

Collaborazione / seat team — se il lavoro di team è parte del valore del prodotto, differenziare i seat è naturale
Profondità di reporting o export — analytics avanzati, viste per coorte o export dati possono vivere in Growth/Scale
Integrazioni — se hai multiple target di integrazione, limitare al core in Starter è difendibile
Livello di supporto — supporto prioritario in Scale è atteso; non bloccare l’aiuto base

Feature che dovrebbero restare in tutti i tier:

Funzionalità core del prodotto — bloccare feature critiche nello Starter insegna ai clienti a non fidarsi del prodotto
Baseline di sicurezza — non creare una “versione sicura” del prodotto
Onboarding base — se aiuti gli utenti Starter a avere successo, fanno upgrade; se non lo fai, fanno churn

Step 4: Imposta un trigger di upgrade chiaro per tier

Ogni confine di piano dovrebbe avere una ragione ovvia e auto-evidente per salire. L’upgrade dovrebbe sembrare guadagnato, non forzato.

Starter → Growth: raggiunto il limite di utilizzo, o pronto a usare il prodotto seriamente. Il momento in cui un cliente pensa “questo è davvero utile per il mio lavoro reale”, dovrebbe essere a un click da Growth.

Growth → Scale: crescita del team, volume più alto, o operazioni più complesse. Il trigger dovrebbe essere qualcosa che il cliente ha scelto (assumere un collaboratore, lanciare un nuovo prodotto, scalare l’utilizzo) — non qualcosa di arbitrario.

Per la struttura di packaging che rende i trigger di upgrade visibili e riduce la fatica, la guida al sistema a 3 livelli copre questo in dettaglio.

Modelli di pricing a subscription SaaS: scegliere la struttura giusta

Il template a 3 tier sopra è packaging. Il modello di pricing a subscription sottostante è una scelta separata — determina come la revenue scala con la crescita dei clienti.

Pricing a tier flat-rate (quello che mostra il template): prezzo fisso per tier con limiti definiti. Prevedibile per i clienti, facile da spiegare, buono per il self-serve. Il modello più comune per SaaS bootstrapped e indie.

Pricing usage-based: i clienti pagano per unità consumata, con una fee base o puro pay-as-you-go. Allinea il costo con il valore ma può creare ansia di billing se la metrica è difficile da prevedere. Funziona bene per tool API e prodotti infrastrutturali dove l’utilizzo è visibile e stimabile. Le guide di billing di Stripe Atlas coprono la meccanica di implementazione per il billing usage-based.

Pricing per-seat: il prezzo scala con il numero di utenti. Naturale per tool di collaborazione e software per team. Più debole quando un power user genera la maggior parte del valore.

Ibrido: una fee di piano base che include un’allowance di utilizzo, più un costo per-unità sopra quella soglia. Riduce l’ansia di billing mantenendo l’allineamento all’utilizzo. Comune nei tool email (base + per-invio sopra il limite incluso).

Per la maggior parte dei prodotti SaaS solo-founder e piccoli team che puntano al mercato indie hacker e fasi iniziali: il pricing a tier flat-rate è il punto di partenza con meno frizione. È prevedibile, confrontabile e diretto da comunicare.

Template del modello di revenue SaaS in JSON

Per i builder che vogliono documentare il modello di pricing in codice o documentazione interna — qualcosa che può realmente guidare una config di billing, pricing page o logica di 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": "Founder singoli / prima valutazione",
        "upgrade_trigger": "Limite utilizzo raggiunto o pronto per uso serio"
      },
      {
        "id": "growth",
        "name": "Growth",
        "price_monthly": 49,
        "price_annual_per_month": 39,
        "included_units": 2000,
        "best_for": "Utenti paganti attivi",
        "upgrade_trigger": "Crescita volume o collaborazione team necessaria",
        "highlighted": true
      },
      {
        "id": "scale",
        "name": "Scale",
        "price_monthly": 99,
        "price_annual_per_month": 79,
        "included_units": 10000,
        "best_for": "Team / operazioni più intense"
      }
    ],
    "overage_policy": "prompt_to_upgrade",
    "downgrade_policy": "allowed_at_renewal"
  },
  "value_metric": {
    "name": "workflows_completed",
    "visible_in_product": true,
    "usage_warning_threshold_pct": 80
  }
}

Il campo usage_warning_threshold_pct conta: mostrare ai clienti che sono all’80% del loro piano crea un momento di upgrade naturale, a bassa pressione, piuttosto che un muro improvviso.

NoNoiseMetrics come esempio live

NoNoiseMetrics usa la stessa struttura a 3 tier descritta sopra, con gli account Stripe connessi come metrica di valore primaria:

Piano	Prezzo	Account Stripe	Per chi è
Free	€0/mese	1	Founder singoli sotto €10K MRR
Indie	€19/mese	3	Prodotti SaaS indie attivi
Pro	€49/mese	Illimitati	Portfolio multi-prodotto e team

Il trigger di upgrade da Free a Indie è aggiungere un secondo account Stripe — naturale per i founder che lanciano un secondo prodotto o vogliono separare gli ambienti. Il trigger da Indie a Pro è aver bisogno di più di 3 account — che succede quando il prodotto funziona abbastanza bene da espandersi.

L’accesso lifetime a €299 sta fuori dalla struttura ricorrente e cattura una psicologia d’acquisto specifica: founder che preferiscono la proprietà alla subscription e sono disposti a pagare in anticipo per un accesso permanente.

La ricerca sul pricing di SaaStr conferma che un trigger di upgrade visibile e nativo nel prodotto converte significativamente meglio rispetto a confronti astratti tra piani — che è esattamente quello che la metrica degli account connessi raggiunge qui.

Errori comuni nel modello di pricing

Troppi piani. Sei tier creano paralisi da confronto. Tre tier coprono la gamma completa di clienti — entry, attivo, power — senza chiedere ai visitatori di valutare più opzioni di quante possano tenere in memoria.

Nessuna metrica di valore chiara. Se i clienti non riescono a capire cosa cambia tra Starter e Growth senza leggere una tabella di confronto, il modello di pricing non ha una spina dorsale. Un’unità chiara di progressione risolve questo.

Zuppa di feature invece di progressione dei limiti. Quaranta checkmark su una tabella prezzi oscurano la ragione principale per fare upgrade. Parti dalla metrica; aggiungi le differenze di feature come contesto secondario.

Rendere lo Starter un tier punizione. Se il piano più basso non riesce a dimostrare valore reale del prodotto, i clienti non hanno ragione di fidarsi del percorso di upgrade. Lo Starter dovrebbe creare valore. Growth dovrebbe espanderlo.

Trigger di upgrade che sembrano punitivi. Un limite che sembra arbitrario o ingiustamente basso insegna ai clienti a risentirsi del pricing piuttosto che aspettarsi di crescerci dentro. I migliori upgrade sembrano guadagnati.

Nessuna visibilità dell’utilizzo in-product. I clienti che possono vedere il loro utilizzo rispetto al limite del piano fanno upgrade proattivamente. I clienti che scoprono di aver raggiunto un limite inaspettatamente si irritano. Questo è un investimento di engineering che ripaga in conversione.

Trasformare il template in una pricing page

Il modello guida la pagina. Una volta che il modello è impostato, la pagina stessa è relativamente meccanica.

Headline: per chi è e il beneficio primario. Tienilo specifico al prodotto, non generico (“semplice” e “potente” non sono benefici).

Griglia prezzi: nomi dei piani, prezzo mensile, limite primario, 3–5 differenze di feature, opzione billing annuale, un piano default evidenziato.

Copy logica upgrade: una riga per transizione. “Passa a Growth quando hai bisogno di più di 200 workflow/mese.” Non più vago di così.

FAQ o blocco fiducia: cosa conta verso il limite di utilizzo, cosa succede quando lo raggiungi, se il downgrade è disponibile, e quali sono i termini del billing annuale. Queste quattro domande rappresentano la maggior parte dei ticket di supporto relativi al pricing nelle fasi iniziali.

Copy CTA su ogni piano: verbi, non sostantivi. “Inizia gratis” batte “Piano Free.” “Inizia ora” su Growth. “Contattaci” solo se Scale è realmente enterprise — se è self-serve, dagli una CTA vera.

FAQ

Cos’è un template di modello prezzi SaaS?

Un template di modello prezzi SaaS è una struttura ripetibile per come un prodotto a subscription è prezzato — i suoi piani, la metrica di valore che guida la progressione dei tier, i limiti che definiscono ogni piano e la logica di upgrade. È l’architettura economica dietro la pricing page, non solo il layout visuale.

Quanti tier di pricing dovrebbe avere un prodotto SaaS?

Tre tier è lo standard per SaaS self-serve: un tier entry a basso impegno, un tier growth default e un tier per utilizzo più alto o team. Meno di tre limita la capacità di catturare segmenti diversi; più di tre crea fatica da confronto.

Qual è il miglior modello di pricing a subscription per SaaS?

Per la maggior parte dei prodotti SaaS bootstrapped e indie, il pricing a tier flat-rate — prezzo fisso per piano con un limite di utilizzo definito — è il punto di partenza con meno frizione. Il pricing usage-based funziona bene per prodotti API e infrastrutturali dove i clienti possono stimare il loro consumo. Il pricing per-seat funziona meglio quando la collaborazione è il driver di valore core.

Cosa dovrebbe cambiare tra i tier di pricing?

Principalmente il limite della metrica di valore (più della cosa per cui i clienti pagano man mano che ottengono più valore), secondariamente un numero ridotto di differenze di feature. La ragione principale per fare upgrade dovrebbe essere chiara in una frase.

Cos’è un template di modello di revenue SaaS?

Un template di modello di revenue SaaS documenta come la revenue ricorrente è strutturata — tier di pricing, metrica di valore, intervalli di billing (mensile vs. annuale), policy di overage e trigger di upgrade. È la logica sottostante che una pricing page presenta ai clienti e che un sistema di billing implementa. La struttura JSON in questo articolo è un punto di partenza pratico.

Cosa dovrei evitare su una pricing page?

Nomi di piani vaghi (Basic, Pro, Enterprise quando non vendi realmente enterprise), limiti non spiegati, trigger di upgrade che sembrano arbitrari e tabelle prezzi con troppe checkmark che oscurano la progressione primaria. L’obiettivo è che un nuovo visitatore capisca “per cosa sto pagando e quando dovrei pagare di più” in meno di 30 secondi.

Dopo aver impostato il prezzo, devi sapere se funziona. NoNoiseMetrics traccia ARPU e MRR per piano automaticamente. Connetti Stripe →

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