Misurare il ROI di un progetto AI con metriche operative fissate prima del lancio

Misurare il ROI di un progetto AI significa confrontare ciò che il progetto costa con ciò che cambia, in modo verificabile, nel lavoro quotidiano dell'azienda. Il problema pratico è che quasi nessuno registra com'era il lavoro prima. Senza quel punto di partenza, qualsiasi numero raccolto dopo il go-live resta un'impressione.

La tesi di questo articolo è semplice. Il ritorno di un progetto AI si dimostra con poche metriche operative, scelte e misurate prima del lancio, che descrivono il processo che l'AI deve cambiare. In un service desk sono, per esempio, la percentuale di ticket instradati correttamente al primo tentativo e il tempo che il personale dedica a smistare le richieste.

Solo dopo aver misurato questi indicatori ha senso tradurli in euro. L'ordine conta: prima il processo, poi la metrica, poi la baseline, infine il valore economico. Chi inverte la sequenza finisce spesso a giustificare a posteriori una spesa già fatta, invece di decidere se estenderla, correggerla o fermarla.

Nelle sezioni che seguono trova come scegliere le metriche, come registrare la situazione di partenza, come leggere i costi reali di strumenti come Claude e come valutare con prudenza i benchmark pubblicati dai fornitori.

Il divario tra percezione e misura è documentato. Secondo le discussioni del Think Circle Q4 2025 di IBM, riportate nell'analisi di IBM sul ROI dell'AI, solo circa il 29% dei dirigenti afferma di poter misurare il ROI dell'AI con sicurezza, mentre il 79% riscontra un aumento della produttività. Molte aziende, quindi, vedono un beneficio ma non sanno quantificarlo.

Lo stesso articolo cita uno studio IBM sui CEO secondo cui solo circa il 25% delle iniziative di AI genera il ROI atteso e solo il 16% ha raggiunto una scala aziendale completa. Richiama inoltre un rapporto del MIT dell'estate 2025 secondo cui il 95% dei progetti pilota di AI generativa sta fallendo.

Il punto più utile per chi decide, però, è un altro. IBM indica che la sfida principale non è tecnologica ma organizzativa, e individua in cultura, governance, progettazione dei workflow e strategia dei dati i principali vincoli alla realizzazione del ROI. Tradotto in pratica: il modello raramente è il collo di bottiglia. Lo è il modo in cui il progetto viene definito, misurato e inserito nel processo.

Questo sposta la responsabilità della misurazione dal fornitore tecnologico alla direzione. Decidere quali metriche contano, chi le raccoglie e con quale frequenza è una scelta di gestione, non di ingegneria.

Una distinzione utile, proposta anche da IBM, è quella tra hard ROI e soft ROI. L'hard ROI riguarda gli effetti tangibili direttamente correlati alla redditività: costi risparmiati o profitti ottenuti. Il soft ROI comprende benefici non immediatamente collegati ai profitti ma comunque positivi, come il morale dei dipendenti e l'esperienza del cliente.

I KPI del soft ROI sono meno semplici da misurare nel breve periodo e, secondo IBM, vengono spesso rilevati con sondaggi e ricerca qualitativa. Non vanno ignorati, ma vanno tenuti separati. Se nello stesso numero mescola ore risparmiate e soddisfazione percepita, il risultato non è verificabile da nessuno.

Come usarla nella pratica

• Hard ROI: metriche che si leggono da un sistema, come ticket, tempi di gestione, riassegnazioni, errori corretti a valle.
• Soft ROI: indicatori raccolti con questionari brevi e ripetuti, per esempio la soddisfazione degli utenti interni prima e dopo il lancio.
• Regola di decisione: la prosecuzione del progetto si giustifica sull'hard ROI; il soft ROI serve a scegliere tra due alternative con ritorno simile.

Questa separazione protegge anche il progetto. Un direttore finanziario accetta più facilmente un numero piccolo ma solido che una stima ampia costruita su ipotesi.

Una buona metrica operativa descrive il comportamento di un processo, si legge da un sistema che l'azienda usa già e cambia in modo visibile se l'AI funziona. Due o tre metriche bastano. Una lista di quindici indicatori non viene mantenuta e, dopo qualche mese, nessuno la guarda più.

Il service desk è un buon esempio perché ogni richiesta lascia una traccia. La tabella riassume le metriche più adatte a un progetto di instradamento o di prima risposta.

Per altri reparti la logica è identica: si cerca il punto in cui il lavoro si ferma, si ripete o viene corretto. La guida su come ogni azienda può usare l'AI aiuta a individuare questi punti per funzione.

La baseline è la fotografia del processo prima dell'intervento. Va raccolta sugli stessi dati e con le stesse definizioni che userà dopo il lancio. Se oggi considera "corretto" un ticket mai riassegnato, domani non può cambiare definizione solo perché il nuovo sistema sembra lavorare meglio.

Nella maggior parte dei casi i dati esistono già. Un sistema di ticketing come Zoho Desk conserva lo storico delle assegnazioni, dei tempi di risposta e delle riaperture. Con uno strumento di reportistica come Zoho Analytics si possono estrarre le serie storiche e fissarle come riferimento prima che il progetto parta.

Tre accorgimenti che evitano contestazioni

1. Periodo rappresentativo: scelga un intervallo che includa i picchi abituali di lavoro, non solo settimane tranquille.
2. Misure manuali dichiarate: il tempo di smistamento raramente è registrato; lo stimi con un campione di ticket cronometrati e annoti il metodo.
3. Firma della baseline: faccia approvare i valori di partenza dal responsabile del reparto e dalla funzione finanziaria prima del lancio.

Una baseline approvata trasforma la discussione successiva. Non si dibatte più se il progetto "sembra" funzionare, ma di quanto si è spostato un numero che tutti avevano già accettato.

Le metriche descritte finora non sono teoriche. Per Asset Services Group (Message Direct) abbiamo costruito un assistente per il service desk IT su Claude dentro Microsoft Teams, collegato a Zoho Desk, che ha raggiunto il 99,7% di instradamento corretto al primo tentativo e un guadagno di efficienza del 40%, dati citati nel caso studio pubblicato dal loro Head of Technology con l'approvazione scritta del cliente.

Il valore dell'esempio sta nella natura delle metriche scelte. Entrambe si leggono da un sistema operativo, entrambe hanno un significato immediato per chi gestisce il reparto e nessuna delle due richiede ipotesi sul comportamento dei clienti o sul mercato.

La precisione di instradamento, in particolare, è una metrica che trascina con sé altri effetti misurabili. Ogni ticket che arriva subito al gruppo giusto elimina una riassegnazione, riduce il tempo alla prima risposta e libera il personale che prima faceva da smistatore. Per questo conviene sceglierla come metrica principale quando l'AI interviene all'ingresso del processo.

Se intende applicare lo stesso approccio, il passo decisivo è lo stesso: fissare la definizione di "instradamento corretto" e misurarla sullo storico prima che l'assistente entri in funzione.

Una volta che la metrica si è spostata, va tradotta in euro. Il calcolo di base è lineare: ore liberate moltiplicate per il costo orario pieno del personale coinvolto, più eventuali costi evitati, meno il costo complessivo del progetto nello stesso periodo. Il risultato va letto su un orizzonte definito, per esempio dodici mesi.

La guida al consumo di Claude Enterprise propone un modo di ragionare utile anche fuori dal codice: confrontare il costo di ogni singola esecuzione con il valore che produce. Il documento di Anthropic sul consumo porta l'esempio di una skill di preparazione alle chiamate che costa 0,90 dollari per esecuzione a fronte di 20 dollari di valore, e che quindi rende 20 volte a ogni utilizzo.

Rendere esplicite le ipotesi

Il valore di un'ora risparmiata è sempre un'ipotesi, e va dichiarata. Anthropic adotta la stessa trasparenza nella scheda Value dell'analisi di Claude Code: ogni formula è mostrata in chiaro e gli input possono essere modificati per riflettere le ipotesi dell'organizzazione. È un buon modello anche per un foglio di calcolo interno.

Un ultimo accorgimento: le ore liberate diventano risparmio reale solo se vengono riassegnate a lavoro utile. Indichi fin dall'inizio dove andrà il tempo recuperato, altrimenti il beneficio resta sulla carta.

Il ROI ha un denominatore, e con i modelli linguistici il costo non è fisso. Claude Enterprise è tariffato con un modello per postazione basato sull'uso, con un pool di consumo condiviso da tutti gli utenti dell'organizzazione. La guida di Anthropic avverte che alcune superfici, in particolare Claude Code e Cowork, consumano token a un ritmo significativamente superiore rispetto alla chat standard.

Gli amministratori possono impostare limiti di spesa a livello di organizzazione, di gruppo e di singolo utente, oltre a budget di gruppo condivisi. Vale una regola da ricordare: se un membro non ha un limite individuale e nessuno dei suoi gruppi ne ha uno, la sua spesa non è limitata.

Quando fidarsi dei numeri

• Secondo la pagina di analisi dell'utilizzo per i piani Team ed Enterprise, gli amministratori possono esportare un report CSV con token e spesa stimata per utente e per modello, aggiornato ogni giorno, con un ritardo di un giorno e fino a 90 giorni indietro.
• La stessa pagina indica che i report di spesa esportati e l'Analytics API dovrebbero corrispondere da vicino alla fattura.
• I dati di costo dell'Analytics API arrivano di norma entro circa quattro ore, ma possono essere rivisti fino a 30 giorni: per totali utilizzabili a fini contabili Anthropic consiglia di interrogare date vecchie di almeno 30 giorni.

Nel calcolo del ROI, quindi, usi i dati consolidati del mese chiuso e non le cifre del giorno.

Nelle presentazioni commerciali compaiono spesso percentuali di ritorno molto alte. SAP, per esempio, cita un report di Enterprise Strategy Group secondo cui l'integrazione dell'AI nei sistemi CX ed ERP può garantire un ROI conservativo del 214% in cinque anni, fino al 761% nello scenario migliore. Sono dati utili per capire l'ordine di grandezza possibile, non per prevedere il risultato della Sua azienda.

Più istruttivi sono i casi in cui il fornitore riporta una metrica operativa precisa. Nella guida di SAP sul ROI dell'AI, SA Power Networks ha risparmiato 1 milione di dollari in un anno con un'app supportata dall'AI e ha raggiunto un tasso di successo del 99% nell'identificare i pali a rischio di corrosione. Qui il valore economico poggia su una misura di accuratezza, esattamente come nel caso del service desk.

Occorre prudenza anche con le metriche di attribuzione automatica. La documentazione di Anthropic sulle metriche di contributo di Claude Code le definisce deliberatamente conservative e una sottostima dell'impatto reale. Un dato prudente è preferibile a uno gonfiato, ma va dichiarato come tale.

Infine, IBM osserva che il pagamento del debito tecnico dei sistemi legacy può migliorare il ROI dell'AI fino al 29%, perché riduce attriti e rilavorazioni. Se i dati di partenza sono disordinati, parte del ritorno dipende dal sistemarli prima.

Se sta valutando un progetto AI o deve giustificarne uno già avviato, questa è una sequenza di lavoro realistica, che non richiede strumenti nuovi.

1. Scelga un solo processo. Individui il punto in cui il lavoro si ferma o si ripete, per esempio lo smistamento delle richieste. La valutazione della prontezza all'AI aiuta a capire da dove partire.
2. Definisca due o tre metriche operative. Scriva la definizione esatta di ciascuna e il sistema da cui verrà letta.
3. Registri e faccia approvare la baseline. Coinvolga il responsabile del reparto e la funzione finanziaria prima del go-live.
4. Imposti i controlli di costo. Configuri limiti di spesa per gruppo e per utente e decida quale report userà come fonte ufficiale.
5. Fissi le date di verifica. Confronti metriche e costi a mesi chiusi, usando i dati consolidati.
6. Decida in base ai numeri. Estenda, correggi o fermi il progetto secondo lo scostamento dalla baseline, non secondo le impressioni.

Se il sistema interviene su decisioni che riguardano persone, verifichi anche gli obblighi applicabili consultando il quadro normativo sull'AI in Italia prima del lancio. È più semplice progettare la registrazione dei dati una volta sola, all'inizio, che ricostruirla dopo.