Modellazione Scenari SaaS: Stress-Test in 15 Min

Una singola previsione non è un piano. È una storia — la storia dove la crescita resta grosso modo in pista, il churn si comporta, i costi non sorprendono e niente di importante va storto. Quella storia è comoda da credere e storicamente inaffidabile.

La modellazione scenari è l’abitudine di far girare le storie scomode insieme a quella comoda. Non perché il disastro sia probabile, ma perché la distanza tra il caso base e il caso downside rivela quali ipotesi sono portanti — e quelle sono esattamente le ipotesi che un founder bootstrapped deve mettere sotto pressione prima che la runway si stringa.

Per un bootstrapper con capitale limitato e nessun fallback esterno, lo scenario downside non è un esercizio accademico. È la domanda operativa: se qualcosa di normale va storto — il nuovo MRR rallenta, il churn sale, un costo infrastrutturale aumenta — quanto tempo viene tolto alla runway, e quali decisioni diventano urgenti prima che succeda?

Cos’è la modellazione scenari?

La modellazione scenari è il processo di testare come le metriche chiave del business cambiano sotto ipotesi diverse — specificamente, cosa succede quando gli input più importanti sono migliori o peggiori del caso base.

La distinzione dal forecasting è importante. Il forecasting chiede: cosa pensiamo che succederà? Produce un numero — la miglior stima date le informazioni attuali. La modellazione scenari chiede: cosa succede se quella stima è sbagliata, e in che direzione? Produce un range — tre versioni del futuro che racchiudono lo spazio di risultati realistici.

Il forecasting dà sicurezza. La modellazione scenari calibra quella sicurezza contro i modi in cui potrebbe essere mal riposta. Entrambi sono necessari; la modellazione scenari è la parte che la maggior parte dei bootstrapper salta. La guida finanziaria per startup di Y Combinator enfatizza costantemente il far girare scenari multipli piuttosto che impegnarsi in una singola stima puntuale — l’obiettivo è sapere come le decisioni cambiano sotto condizioni diverse, non predire il futuro esattamente.

Ogni previsione ha bisogno di un MRR pulito come base. Ottieni il tuo da Stripe in 90 secondi →

Perché la modellazione scenari conta di più per i bootstrapper che per le aziende finanziate

Un’azienda finanziata con 24 mesi di runway e relazioni con investitori può assorbire un brutto trimestre, ricalibrarsi e continuare. Un founder bootstrapped con 8 mesi di runway no. Un mese inaspettatamente brutto — churn più veloce, un esperimento di pricing andato male, il lancio di un competitor che ha rubato pipeline — può comprimere la timeline decisionale da “abbiamo tempo per capirlo” a “dobbiamo agire questa settimana.”

La modellazione scenari non previene i mesi brutti. Impedisce che il mese brutto sia una sorpresa. Se lo scenario downside è stato fatto girare onestamente tre mesi fa, il founder sa già: se il churn raggiunge €700/mese invece di €500/mese, la runway si comprime da 9 mesi a 6. Quel calcolo, fatto in anticipo, produce una postura decisionale diversa nel mese uno del deterioramento rispetto allo stesso calcolo fatto nel panico al mese tre.

L’obiettivo non è predire l’avversità. È avere già deciso cosa fare se arriva.

I 3 scenari che ogni founder dovrebbe far girare

Scenario 1: Caso base

La previsione operativa. Non ottimistica, non pessimistica — la proiezione realistica basata sui trend recenti e il momentum attuale. Questa è la previsione che il founder darebbe se gli chiedessero “cosa ti aspetti il mese prossimo?” senza pressione per impressionare o proteggersi.

Un caso base che richiede che cose significative vadano bene non è un caso base — è un caso upside che è stato etichettato male. Il caso base dovrebbe essere raggiungibile attraverso un’esecuzione normale senza fortuna significativa.

Scenario 2: Caso upside

La versione buona realistica. Nuovo MRR leggermente migliore (conversione migliore o pipeline più qualificata), espansione leggermente più forte (il packaging sta funzionando, il tasso di upgrade è sano), churn leggermente più basso (la retention sta migliorando). Questo dovrebbe essere raggiungibile attraverso un’esecuzione eccellente ma realistica — non un mese eccezionale basato su un singolo grande deal.

Il caso upside è utile perché mostra come appare “fare bene” in numeri concreti. Se il gap tra base e upside è molto piccolo, il business ha leva limitata — migliorare l’esecuzione non muove molto l’ago. Se il gap è grande, c’è upside significativo dal miglioramento dell’esecuzione, il che dovrebbe focalizzare l’attenzione del founder.

Scenario 3: Caso downside

Lo scenario più importante, e quello più comunemente evitato. Il caso downside non è un fallimento catastrofico — è la versione realistica di un periodo normalmente brutto. Il nuovo MRR rallenta del 20–30%. Il churn sale del 30–40%. I costi variabili aumentano leggermente. Non succede niente di inusuale — solo i modi ordinari in cui un business SaaS sotto-performa il suo caso base.

Il caso downside dovrebbe produrre una sensazione leggermente scomoda quando viene rivisto. Se non lo fa — se il risultato downside sembra quasi buono quanto il caso base — le ipotesi downside non sono oneste. Se produce forte allarme, le ipotesi downside potrebbero essere troppo pessimistiche. Calibra finché il caso downside sembra una descrizione onesta di un mese brutto ma non catastrofico.

Il setup in 15 minuti: step per step

Step 1: Ancora al MRR e cash attuali

Parti dai fatti, non dalle stime.

MRR attuale: €10.000
Cash disponibile: €45.000
Costi mensili (fissi + variabili): €8.000

Step 2: Imposta i tre input per scenario

Gli input che contano di più in un modello di scenari SaaS sono: nuovo MRR, MRR espansione, MRR churned e costi (per un modello più completo). Per uno scenario puramente di revenue, i primi tre sono sufficienti.

Input	Base	Upside	Downside
Nuovo MRR	€1.500	€1.800	€1.100
MRR espansione	€600	€750	€400
MRR churned	€500	€420	€720

Step 3: Calcola il MRR finale per ogni scenario

Formula: MRR Attuale + Nuovo MRR + Espansione − Churned

Base:

10.000 + 1.500 + 600 − 500 = 11.600

Upside:

10.000 + 1.800 + 750 − 420 = 12.130

Downside:

10.000 + 1.100 + 400 − 720 = 10.780

Step 4: Confronta gli output side by side

Scenario	MRR Finale	vs Base	Cosa significa
Base	€11.600	—	Esecuzione normale, traiettoria attuale
Upside	€12.130	+€530	Buona conversione + retention forte
Downside	€10.780	−€820	Acquisizione rallentata + aumento churn

Step 5: Estendi il caso downside per 3 mesi

Questo è lo step che converte la modellazione scenari da accademica a operativa. Far girare il caso downside per un mese mostra il costo mensile del deterioramento. Farlo girare per tre mesi mostra se la runway raggiunge una soglia decisionale.

Mese 1 downside: €10.780 Mese 2 downside (partendo da €10.780): €10.780 + 1.100 + 400 − 720 = €11.560 Mese 3 downside: €11.560 + 1.100 + 400 − 720 = €12.340

In questo esempio, anche lo scenario downside produce crescita del MRR su tre mesi — il business sta generando abbastanza nuova revenue per compensare il churn aumentato. La domanda sulla runway dovrebbe includere il confronto con la struttura dei costi per valutare l’urgenza.

Se invece il caso downside avesse prodotto MRR piatto o in calo su tre mesi, questo attiva decisioni immediate: ridurre la spesa variabile, prioritizzare la retention sull’acquisizione, accelerare la revisione del pricing.

Un esempio completo di modellazione scenari

Un prodotto di analytics SaaS bootstrapped, mese cinque. Contesto completo:

MRR attuale: €10.000
Costi mensili: €8.000
Cash disponibile: €45.000
Burn netto attuale: circa −€2.000 (la revenue supera i costi)

Output tre scenari:

Metrica	Base	Upside	Downside
Nuovo MRR	1.500	1.800	1.100
MRR espansione	600	750	400
MRR churned	500	420	720
MRR finale	11.600	12.130	10.780
Crescita mensile implicita	16%	21,3%	7,8%
Costi	8.000	8.000	8.200
Burn netto	−3.600	−4.130	−2.580

Cosa rivela il caso downside:

Nello scenario downside, il burn netto scende da −€3.600 (base) a −€2.580 — il business è ancora cash-flow positivo, ma genera €1.020 in meno al mese del previsto. Su sei mesi di downside sostenuto, sono circa €6.120 in meno di accumulazione di cash rispetto al caso base. Nessuna crisi — ma un segnale chiaro che un downside sostenuto dovrebbe attivare una revisione del pricing e un’indagine sulla retention piuttosto che continuare a sperimentare con nuove feature. I dati della SaaS Survey di KeyBanc Capital Markets mostrano che le aziende bootstrapped con pianificazione scenari proattiva superano materialmente i peer nella gestione del cash attraverso periodi difficili.

Cosa cambierebbe concretamente:

Se lo scenario downside apparisse nei consuntivi del primo mese reale, il founder non aspetterebbe di vedere tre mesi uguali. La risposta corretta al downside del mese uno è: indaga le fonti del churn immediatamente (è pagamento fallito o volontario?), blocca la spesa variabile, e sposta la revisione del pricing da “prossimo trimestre” a “questo mese.”

Quali variabili stress-testare per prime

Non ogni input merita uguale attenzione. Per la maggior parte dei prodotti SaaS nelle fasi iniziali:

Alta leva per lo stress-test:

MRR churned — l’input più comunemente sottostimato, e quello con il maggior impatto sulla sostenibilità della runway
Nuovo MRR — specialmente se una porzione significativa dipende da un canale specifico o da pochi grandi prospect
Costi variabili — se i costi infra o API scalano con l’utilizzo, uno scenario di crescita può produrre aumenti di costo inaspettati

Priorità più bassa a meno che non siano materiali:

MRR espansione — vale la pena modellarlo una volta che il comportamento di upgrade è consistente, ma meno critico del churn nelle fasi iniziali
Costi fissi — relativamente stabili; vale la pena fare stress-test annualmente piuttosto che mensilmente
Cambi di prezzo — modella separatamente quando un esperimento di pricing è pianificato, non come parte del modello di scenari permanente

Il principio generale: fai stress-test sugli input dove un cambiamento del 30% cambierebbe materialmente una decisione. Se un oscillazione del 30% nel MRR espansione non cambia cosa fai questo mese, non deve essere nel modello di scenari ancora. Il report State of the Cloud di Bessemer identifica il churn come la singola variabile con la più alta sensibilità nei modelli finanziari SaaS nelle fasi iniziali — una scoperta consistente attraverso fasce di ARR da €1M a €10M.

Errori comuni nella modellazione scenari

Rendere il caso downside troppo comodo. Il fallimento più frequente. Un downside che è il 5% peggio del base non è uno stress test — è un caso base con un’etichetta diversa. Il caso downside dovrebbe riflettere un periodo genuinamente plausibile di difficoltà: acquisizione più lenta del previsto (non fallimento catastrofico), churn più alto del previsto (non cancellazione di massa), costi leggermente più alti. Dovrebbe sembrare scomodo a guardarlo, non rassicurante.

Far girare scenari e non cambiare niente. Un modello di scenari che produce un caso downside preoccupante e non provoca nessun cambio decisionale è intrattenimento, non pianificazione. Ogni revisione degli scenari dovrebbe finire con un impegno specifico: “se il caso downside si materializza al mese uno, faremo X prima del mese due.” Definisci il trigger e la risposta in anticipo.

Cambiare troppe variabili contemporaneamente. Se ogni input cambia in ogni scenario, il modello non può insegnare nulla — non c’è modo di identificare quale variabile guida il maggior rischio. Parti con i due o tre input che contano di più (di solito nuovo MRR e MRR churned), fai girare scenari puliti, poi aggiungi complessità solo se variabili aggiuntive creano rami decisionali distinti.

Nessuna vista side-by-side. Scenari in tab separate o documenti separati vengono raramente usati insieme. Metti i tre scenari su uno schermo, side by side. Il valore della modellazione scenari è il confronto, non i numeri individuali.

Confrontare solo con il caso base, non con i consuntivi del mese scorso. Dopo che ogni mese si chiude, verifica quale scenario era più vicino alla realtà e perché. Questo è il ciclo di calibrazione che rende i modelli di scenari più accurati nel tempo. Un founder che ha fatto girare dodici revisioni mensili di scenari con confronti dei consuntivi ha un modello significativamente meglio calibrato rispetto a un founder che ha costruito un modello e non ha mai aggiornato le ipotesi.

Come la modellazione scenari cambia le decisioni

Un modello di scenari utile dovrebbe influenzare direttamente almeno una decisione operativa ogni mese. Esempi delle decisioni che gli scenari dovrebbero attivare:

Churn downside significativamente più alto del base → indaga lo split volontario vs pagamento fallito immediatamente; implementa o rafforza la sequenza di dunning; anticipa la revisione dell’onboarding.

Nuovo MRR downside significativamente sotto il base → riduci la spesa variabile proporzionalmente; de-prioritizza il lavoro su nuove feature a favore dell’ottimizzazione della conversione; rivedi le ipotesi sui canali di acquisizione.

Il downside rivela runway che si comprime sotto 6 mesi entro 3 mesi → inizia la revisione del pricing immediatamente; valuta la riduzione del lavoro contractor; valuta se un esperimento di pricing dovrebbe essere anticipato nella roadmap.

L’upside mostra espansione che guida più del previsto → accelera l’investimento nel packaging; valuta se il flusso di upgrade potrebbe essere migliorato per catturare più di quel potenziale.

Questi non sono ipotetici. Ogni output di scenario dovrebbe mappare a un’azione nominata e tempificata. Se non lo fa, gli scenari vengono usati come comfort piuttosto che come intelligence operativa.

Per gli strumenti che rendono gli input degli scenari più accurati, vedi:

Modello di Previsione SaaS: Prevedi il MRR con 3 Input — il layer di previsione che produce gli input per le esecuzioni degli scenari
Budget vs Reale: Il Ciclo Settimanale Che Ti Mantiene in Vita — il ciclo di confronto che calibra le ipotesi degli scenari nel tempo
Modello Finanziario per Startup: La Guida Minimalista per Founder — il modello completo che incorpora gli scenari in un contesto di costi e runway

Modello JSON per output a tre scenari

{
  "scenario_model": {
    "period": "2026-05",
    "currency": "EUR",
    "current_mrr": 10000,
    "cash_on_hand": 45000,
    "monthly_costs": 8000,
    "scenarios": {
      "base": {
        "new_mrr": 1500,
        "expansion_mrr": 600,
        "churned_mrr": 500,
        "ending_mrr": 11600,
        "net_burn": -3600,
        "label": "Esecuzione normale, traiettoria attuale"
      },
      "upside": {
        "new_mrr": 1800,
        "expansion_mrr": 750,
        "churned_mrr": 420,
        "ending_mrr": 12130,
        "net_burn": -4130,
        "label": "Buona conversione e retention forte"
      },
      "downside": {
        "new_mrr": 1100,
        "expansion_mrr": 400,
        "churned_mrr": 720,
        "ending_mrr": 10780,
        "net_burn": -2580,
        "label": "Acquisizione rallentata e aumento churn"
      }
    },
    "decision_triggers": {
      "downside_churn_exceeds_base_by_30pct": "Indaga fonti churn; rafforza sequenza dunning",
      "downside_new_mrr_below_1200": "Blocca spesa variabile; rivedi mix canali acquisizione",
      "runway_below_6mo_in_3mo_downside": "Inizia revisione pricing; valuta spesa contractor"
    }
  }
}

FAQ

Cos’è la modellazione scenari?

La modellazione scenari è il processo di testare come le metriche chiave del business — MRR, burn, runway — cambiano sotto ipotesi diverse. Invece di affidarsi a una singola previsione, produce tre versioni del futuro (base, upside, downside) che racchiudono lo spazio di risultati realistici e rivelano quali ipotesi guidano il maggior rischio.

Perché la modellazione scenari è utile per i bootstrapper?

I bootstrapper tipicamente hanno capitale limitato e nessun fallback di finanziamento esterno. Un brutto trimestre che un’azienda finanziata può assorbire potrebbe comprimere la runway di un bootstrapper abbastanza da forzare cambi di priorità immediati. La modellazione scenari fa emergere queste compressioni prima che accadano, permettendo al founder di definire le azioni di risposta in anticipo piuttosto che nel panico.

Quali scenari dovrebbero modellare i founder?

Come minimo: base (ipotesi operative realistiche), upside (esecuzione leggermente migliore) e downside (deterioramento normale — acquisizione più lenta, churn più alto, costi leggermente più alti). Il caso downside dovrebbe sembrare scomodo ma non catastrofico. Se non crea nessuna urgenza, le ipotesi sono troppo gentili.

Quali variabili dovrei stress-testare per prime in un modello di scenari SaaS?

MRR churned e nuovo MRR, in quest’ordine. Il MRR churned è l’input più consequenziale e più comunemente sottostimato. Il nuovo MRR è il più sensibile alla concentrazione dei canali di acquisizione o alle condizioni della pipeline. Fai stress-test sui costi variabili se scalano con l’utilizzo; mantieni i costi fissi stabili nella maggior parte delle esecuzioni.

Qual è la differenza tra forecasting e modellazione scenari?

Il forecasting produce una stima di cosa succederà — la miglior ipotesi date le informazioni attuali. La modellazione scenari produce un range di tre stime che testano come il business performa quando le ipotesi chiave sono migliori o peggiori del caso base. Il forecasting dà un numero; la modellazione scenari dà l’intervallo di confidenza attorno a quel numero.

Cos’è la modellazione finanziaria nel contesto SaaS?

La modellazione finanziaria per SaaS si riferisce tipicamente alla costruzione di un modello strutturato che proietta revenue ricorrente, costi, cash burn e runway nel tempo. La modellazione scenari è un layer all’interno della modellazione finanziaria — il layer che testa la sensibilità di quelle proiezioni ai cambiamenti delle ipotesi chiave. Per scopi pratici, il modello finanziario di un founder bootstrapped è in gran parte un modello di scenari con un layer di costi attaccato.

Quanti scenari dovrei modellare?

Tre è il numero giusto per la maggior parte dei founder bootstrapped: base, upside e downside. Due scenari (solo base e downside) perdono l’intuizione della leva upside. Quattro o più scenari creano rumore di confronto senza migliorare significativamente la qualità decisionale. Il valore viene dallo spread tra i tre casi, non dall’aggiungere più granularità a ciascuno.

Quali input contano di più in un modello di scenari SaaS?

MRR churned e nuovo MRR sono i due input a più alta leva per il SaaS nelle fasi iniziali. Un oscillazione del 30% in uno dei due tipicamente cambia almeno una decisione operativa — se prioritizzare la retention o l’acquisizione, se mantenere o aumentare la spesa variabile, se accelerare o ritardare un cambio di pricing. Il MRR espansione e i costi variabili contano una volta che il business ha un comportamento di upgrade consistente o infrastruttura usage-based, ma nelle fasi iniziali sono secondari rispetto all’accuratezza del churn e dell’acquisizione.

Quanto spesso i founder dovrebbero far girare i modelli di scenari?

Mensilmente è la cadenza giusta per la maggior parte dei prodotti SaaS nelle fasi iniziali. Prima che il mese inizi, imposta i tre scenari. Dopo che il mese si chiude, confronta i consuntivi con ogni scenario e calibra le ipotesi. Questo ciclo di dodici mesi produce previsioni significativamente meglio calibrate rispetto a revisioni trimestrali o annuali degli scenari.

Fare previsioni con un MRR sporco significa sbagliare. Inizia con numeri di cui ti puoi fidare →