Una software house conosce il proprio prodotto alla perfezione: architettura, funzioni, mesi di sviluppo. Ma chi in un'azienda da 50 milioni firma un progetto, un CFO, un direttore IT, un consiglio, non compra funzioni. Compra un ritorno che può difendere davanti a chi gli chiede conto del budget. Tra questi due linguaggi c'è una distanza, ed è lì che le trattative si bloccano.
Il tuo prodotto parla di funzioni. Chi firma ragiona in ritorno.
«Gestionale personalizzato», «e-commerce integrato», «agenti AI su misura» sono descrizioni di cosa fa il software. A chi deve deliberare la spesa non dicono nulla di decidibile. La stessa soluzione tradotta in ore risparmiate, margine recuperato, ordini gestiti senza personale aggiuntivo diventa un argomento che il tuo interlocutore può ripetere in consiglio. La domanda a cui rispondere non è «cosa fa il prodotto?», ma quanto fa guadagnare o risparmiare, in quanto tempo rientra, e cosa costa non farlo.
In un'azienda da 50 milioni, chi hai davanti non è chi decide
Più l'azienda è grande, più la decisione è collettiva. Il tuo referente, spesso un responsabile IT o un direttore operativo, raramente ha l'ultima parola su una spesa rilevante: deve portarla a un CFO, a un amministratore delegato, a volte a un consiglio. Se gli lasci entusiasmo e una bella demo, gli lasci un rischio da spiegare in una riunione a cui tu non partecipi. Se gli lasci numeri difendibili, gli lasci una copertura. Il tuo lavoro non è convincere lui: è armarlo perché convinca gli altri.
Riformula la domanda: non «rischiare un progetto», ma «smettere di regalare margine»
L'errore più comune è vendere la soluzione rispondendo bene alla domanda sbagliata. In un caso reale, un consiglio prudente doveva decidere se finanziare un canale e-commerce diretto. Finché la domanda era «conviene rischiare un progetto digitale nuovo?», la risposta istintiva era no. Riformulata in «conviene continuare a lasciare a rivenditori terzi un margine che è già nostro?», la stessa spesa è diventata votabile. Il prodotto non era cambiato: era cambiata la domanda a cui rispondeva.
È lo stesso metodo con cui trasformiamo qualsiasi offerta in una decisione difendibile, ed è il cuore del caso reale che raccontiamo sul sito.
La stessa logica, applicata a un produttore estero che vuole entrare in Italia senza distributore, è in vendere prodotti asiatici in Italia.
Il rischio, ridotto a un numero solo
Un consiglio non approva ciò che non riesce a delimitare. Per questo il rischio va quantificato prima della decisione, non lasciato come sensazione. Qual è l'esposizione massima se il progetto fallisce del tutto? Messa accanto al fatturato dell'azienda, quella cifra smette di essere «un progetto rischioso» e diventa una decisione delimitata.
Nota metodologica. Numeri a scopo di esempio. In un caso reale ogni cifra va ancorata ai dati dell'azienda cliente: costi interni, margini, volumi, costo del capitale.
Mai un numero solo: tre scenari
Un numero singolo suona come una promessa, e in consiglio le promesse vengono smontate. Tre scenari con le ipotesi dichiarate sotto suonano invece come un'analisi. Mostri il caso prudenziale prima di quello ottimistico: chi decide si fida di chi nomina per primo il rischio.
Esempio illustrativo. Anche nello scenario prudenziale il ritorno annuo supera l'investimento. È questo confronto, non la cifra ottimistica, a rendere l'approvazione una conseguenza logica.
Il costo dell'inazione: cosa genera davvero un progetto
Il costo di rimandare non è il prezzo del progetto diviso per i mesi: è il profitto che il canale avrebbe già iniziato a generare. Prendiamo un e-commerce, uno dei progetti più richiesti a una software house. I dati di settore lo descrivono bene: margine lordo medio intorno al 60%, margine netto tra il 10% e il 20%, con i costi di acquisizione che per un canale diretto rientrano in genere entro 6–12 mesi. Da lì in poi il profitto smette di inseguire i costi e li supera. Ogni mese di attesa non è neutro: è un mese di quel sorpasso rimandato.
Ricerca di base. Su un e-commerce medio il margine lordo si aggira sul 60% e quello netto tra il 10% e il 20%; per un canale diretto i costi di acquisizione rientrano tipicamente in 6–12 mesi. Fonti: Onramp Funds, Eightx, Glencoyne (benchmark 2025–2026).
Un caso comparabile che valida la direzione
Quando raccomandi una direzione, mostra qualcuno che l'ha già percorsa. Non per copiarlo, ma per dimostrare che non stai proponendo un salto nel buio. Un consiglio prudente approva più facilmente una scelta quando vede che un attore credibile del suo stesso mondo l'ha già fatta e ne ha tratto vantaggio. Il caso comparabile non prova che funzionerà: prova che la direzione è sensata.
Il metodo, in quattro passi
- Riformula il problema nei termini di chi delibera. Non «cosa fa il software», ma quale margine protegge o recupera per l'azienda.
- Delimita il rischio in un numero solo. L'esposizione massima, rapportata al fatturato, così la decisione ha un confine.
- Costruisci tre scenari con le ipotesi dichiarate. Prudenziale, base, ottimistico, ognuno con la sua nota su come è stato calcolato.
- Scrivi la decisione in una riga. Una frase che il tuo referente può portare in consiglio senza riscriverla.
Il rischio massimo del progetto è lo 0,24% del fatturato; il ritorno lo supera già nello scenario prudenziale, e ogni mese di rinvio costa più che decidere.
Domande frequenti
Perché una grande azienda non compra un software anche se è valido?
Perché la spesa non la decide chi hai davanti: deve essere approvata da un CFO, da un amministratore delegato o da un consiglio. Se al tuo referente lasci solo entusiasmo, gli lasci un rischio da difendere. Il sì arriva quando la spesa è tradotta in ritorno annuo, tempo di rientro ed esposizione massima delimitata.
Come si presenta il ritorno di un gestionale, un e-commerce o di agenti AI a un consiglio?
Tradotto in numeri difendibili: ore e costi risparmiati, margine recuperato, ordini gestiti senza personale aggiuntivo, il tutto in tre scenari con le ipotesi dichiarate. Non «cosa fa il software», ma quale risultato porta a chi deve deliberare la spesa.
Cos'è il costo dell'inazione per un progetto software?
È il valore che l'azienda perde finché non decide: clienti che passano ai canali di un concorrente, efficienza non recuperata, dati e recensioni che si accumulano altrove. È reale anche quando non è scritto a bilancio, e cresce ogni mese di rinvio.