Le stime ottimistiche non sopravvivono alla terza domanda del CFO. Ecco come si costruisce un business case dell’AI che regge, compresa la parte in cui non si nascondono i limiti.
La riunione con il CFO dura solo ventidue minuti: sulla slide c’è scritto che l’Agente AI porterà il 60% di risparmio sui costi del servizio clienti e il CFO chiede da dove esce quel 60%, su quale volume è calcolato e in quanti mesi si manifesta. Non c’è una risposta pronta a nessuna delle tre, e il progetto viene rimandato al budget dell’anno prossimo.
Questa scena si ripete molto più spesso di quanto si racconti. In questo articolo vediamo perché la maggior parte dei business case AI si sgretola davanti a chi controlla i numeri, quali sono le sei voci che rendono un business case difendibile, quali costi vengono sistematicamente dimenticati e come preparare le risposte alle tre domande che arrivano sempre.
Perché i business case dell’AI si sgretolano davanti al CFO
Il numero finale non è quasi mai il problema. È che il numero arriva senza una catena di ipotesi verificabili dietro. Un CFO non sta cercando di bocciare il progetto, ma sta cercando di capire quale parte della stima sopravvive se una delle ipotesi si rivela sbagliata.
C’è poi un problema di credibilità di settore che nessuno può ignorare. Nel giugno 2025 Gartner ha previsto che oltre il 40% dei progetti di AI agentica verrà cancellato entro la fine del 2027, indicando tra le cause i costi in crescita, il valore di business poco chiaro e controlli di rischio inadeguati. È, certa, una previsione del 2025 che viene spesso ricitata come se fosse una rilevazione di oggi, quindi vale la pena maneggiarla con la data corretta. Ma il punto resta: chi approva budget spesso lo ha letto e arriva alla riunione già scettico.
Un business case AI credibile lavora quindi su due fronti insieme: dimostrare il beneficio e dimostrare di aver capito dove il progetto può fallire.
Le sei voci di un business case AI difendibile
1. La baseline, cioè quanto costa oggi
Senza baseline non esiste risparmio, esiste solo una promessa. Per preparare un business case valido bisogna conoscere alcuni numeri: il volume annuo di contatti diviso per canale, il tempo medio di gestione e il costo pieno per contatto. Non basta infatti solo il costo del personale, ma anche formazione, turnover, supervisione, licenze degli strumenti, eventuale outsourcing nei picchi. Se questo dato non esiste, il primo deliverable del progetto è costruirlo, e va detto apertamente.
2. Il volume realmente indirizzabile
Non tutti i contatti e le richieste sono automatizzabili e fingere il contrario è il modo più rapido per perdere credibilità. Conviene classificare un campione reale di conversazioni (poche centinaia bastano) in tre categorie: automatizzabile subito, automatizzabile dopo un’integrazione, non automatizzabile. Solo la prima e la seconda entrano nel calcolo, e con tempi diversi.
3. Il beneficio atteso, espresso come intervallo
Un numero singolo comunica una precisione che è impossibile da avare. Un intervallo con scenario prudenziale, atteso e favorevole, comunica invece un’attenta riflessione sulla variabilità. Sul piano operativo il beneficio si costruisce a partire dal deflection rate e dal tasso di risoluzione, non da percentuali generiche di risparmio.
4. Il costo totale, non il canone
Anche se il canone della piattaforma è la voce più visibile, allo stesso tempo è raramente la più pesante. Nel business case è fondamentale che siano messi a bilancio setup e configurazione, integrazioni con i sistemi esistenti, preparazione della knowledge base, consumo dei modelli linguistici, ambienti di test, ma anche, e soprattutto il presidio interno continuativo. Torniamo sui costi dimenticati tra poco.
5. Una curva temporale, non una media annua
I benefici non arrivano il primo mese e i costi sì. Presentare il risparmio come media annua nasconde esattamente la parte che interessa al CFO: la cassa nei primi due trimestri. Meglio una curva mese per mese, con il punto di pareggio segnato in modo esplicito e il momento in cui il progetto smette di assorbire liquidità.
6. Rischi, con la contromisura accanto
Infine, elencare i rischi senza contromisura fa sembrare il progetto fragile; ometterli fa sembrare ingenuo chi lo presenta. Per ogni rischio rilevante (adozione più lenta del previsto, integrazione più complessa, qualità dei contenuti insufficiente) serve una riga con impatto stimato e azione di mitigazione.
Calcola il tuo ROI con Userbot →
I costi che quasi tutti dimenticano
Arriviamo quindi a quelle voci che non compaiono in quai nessun preventivo e che poi spiegano perché il consuntivo non assomiglia al piano.
- Manutenzione dei contenuti. Una knowledge base non aggiornata degrada le risposte in modo silenzioso. Qualcuno deve occuparsene, e quel qualcuno costa.
- Presidio e osservabilità. Rivedere le conversazioni andate male è la principale fonte di miglioramento. Va previsto come attività ricorrente, non come sforzo iniziale.
- Consumo variabile dei modelli. Cresce con i volumi e con la complessità dei prompt. È l’unica voce che può sorprendere al rialzo dopo il go-live.
- Cambiamenti nei sistemi collegati. Ogni migrazione di CRM o gestionale si ripercuote sulle integrazioni dell’agente.
- Gestione del cambiamento sul team. Gli operatori devono imparare a lavorare con l’agente, non accanto. È tempo di persone, quindi è costo.
Se state ancora decidendo se sviluppare internamente o adottare una piattaforma, molte di queste voci pesano in modo molto diverso nei due scenari: ne abbiamo parlato nell’analisi Build vs Buy.
Le tre domande del CFO a cui arrivare preparati
- «Il risparmio è cassa o è capacità liberata?» Se nessuno lascia l’organizzazione, il beneficio è tempo che il team dedica ad altro. È un beneficio reale, ma va chiamato con il suo nome e collegato a un obiettivo (più contatti gestiti, tempi di risposta più bassi, meno straordinari nei picchi).
- «Cosa succede se il beneficio è la metà di quello stimato?» Va calcolato prima: a quale livello di risultato il progetto resta comunque conveniente. Se il punto di pareggio regge anche nello scenario prudenziale, la discussione cambia tono.
- «Come lo verifichiamo tra sei mesi?» Servono metriche decise in anticipo, con la loro definizione scritta, e un momento fissato in cui rileggerle. Un business case senza data di verifica è una previsione, non un impegno.
🚩 Red flag: un business case in cui il beneficio cresce ogni anno e i costi restano piatti. Nella realtà crescono entrambi, solo con pendenze diverse.
Un business case onesto dice anche quando non conviene
Ci sono situazioni in cui la risposta corretta è aspettare. Per esempio, se i volumi di contatto sono troppo bassi perché il risparmio superi il costo del progetto, oppure se i processi cambiano ogni mese e renderebbero obsoleta qualunque configurazione, o ancora, se la documentazione interna è talmente frammentata che il primo investimento sensato è riordinarla e non automatizzarla.
Dirlo apertamente nel documento non indebolisce la proposta: la rende credibile su tutto il resto. Ed è anche il modo più efficace per far capire che il perimetro scelto non è stato deciso a caso.
Il documento non serve a convincere
Il business case migliore che abbiamo visto passare non era quello con il ROI più alto. Era quello che chiariva in una pagina quali ipotesi reggevano il risultato e quale sarebbe stato il segnale, dopo sei mesi, per fermarsi. Chi approva budget non compra ottimismo: compra la sensazione che qualcuno abbia già pensato a cosa fare se le cose vanno storte.
Domande frequenti sul business case dell’AI
Su quale orizzonte temporale va costruito?
Tre anni è l’orizzonte più comune, perché copre l’ammortamento dei costi iniziali. Ma il dettaglio mensile serve almeno sui primi dodici mesi, che sono quelli in cui il progetto viene giudicato.
Vanno inclusi i benefici non economici?
Sì, ma separati e senza convertirli in euro con moltiplicatori arbitrari. Disponibilità continua, tempi di risposta, tracciabilità delle decisioni e riduzione degli errori sono argomenti forti presentati per quello che sono.
Meglio partire da un progetto pilota?
Quasi sempre, a due condizioni: che il perimetro sia abbastanza ampio da produrre dati significativi, e che i criteri di successo siano definiti prima di iniziare. Un pilota senza soglie decise in anticipo tende a non finire mai.
possiamo aiutarti?
il nostro team è a tua disposizione.
