Aggiungere metriche non migliora necessariamente la comprensione. Molte dashboard contengono diverse misure dello stesso comportamento sottostante. Le metriche sono più utili per la diagnosi se abbinate in coppie reciprocamente distruttive: costo e qualità, contenimento e sentiment oppure accuratezza e latenza.
Le coppie più adatte cambiano man mano che un prodotto di IA passa dal progetto pilota alla produzione. La misurazione deve seguire le decisioni che il team deve prendere in ogni fase.
Il monitoraggio operativo e la misurazione strategica hanno finalità diverse. I team possono monitorare centinaia di segnali di sistema, ma usare solo poche coppie per orientare le decisioni sul prodotto.
Le metriche principali possono raccontare una storia convincente lasciando irrisolta un'importante decisione sul prodotto.
L'assistente IA di Klarna è stato pubblicamente associato a una maggiore capacità di elaborazione, costi inferiori e punteggi di soddisfazione dei clienti paragonabili a quelli degli agenti umani. L'anno seguente, l'azienda ha deciso di ampliare l'accesso all'assistenza umana e il suo amministratore delegato ha riconosciuto che era stata data troppa importanza alla riduzione dei costi.
Non si è trattato di un rifiuto dell'assistente IA o della tecnologia su cui si basa. È stato un adeguamento dell'equilibrio tra automazione e servizio umano, mentre l'azienda imparava dall'utilizzo del prodotto. Man mano che l'automazione gestiva un numero maggiore di richieste semplici e ad alto volume, gli agenti umani di cui Klarna aveva bisogno erano quelli preparati a gestire casi complessi e delicati.
Dopo aver definito fin dall'inizio gli obiettivi di un prodotto, quasi tutte le organizzazioni che sviluppano prodotti di IA finiscono per porsi la stessa domanda: funziona davvero?
Se la risposta non è chiara, spesso la reazione istintiva è aggiungere altre metriche. Da tre si passa a 10, poi da 10 a 30. La dashboard si arricchisce, ma la comprensione del team potrebbe non migliorare.
Il problema non risiede sempre nella qualità delle singole misure, bensì nel rapporto tra loro. Soddisfazione dei clienti, Net Promoter Score, recensioni e percentuali di valutazioni positive possono fornire segnali utili, ma potrebbero riflettere variazioni simili nel sentiment complessivo. Quando si muovono insieme, confermano che è accaduto qualcosa senza necessariamente spiegarne il motivo.
I team di IA dovrebbero quindi guardare oltre le metriche concordanti e individuare misure che mettano in luce risultati in conflitto. Queste coppie reciprocamente distruttive rivelano e aiutano a monitorare l'impatto dei compromessi alla base delle prestazioni del prodotto, consentendo decisioni migliori.
In un'implementazione precedente al lancio, il team congiunto stava sviluppando un agente vocale di IA in tempo reale per le chiamate in entrata all'assistenza clienti. Una delle domande più difficili non riguardava la scelta o l'orchestrazione del modello. Riguardava il modo in cui l'organizzazione avrebbe stabilito se il prodotto funzionava una volta adottato su larga scala dai clienti.
Il quadro iniziale utilizzava tre misure:
Tasso di contenimento: frequenza con cui l'IA risolve una chiamata senza trasferirla a una persona.
Tasso di escalation: frequenza con cui una chiamata viene trasferita a un agente umano.
Tasso di risoluzione: frequenza con cui il problema del cliente viene infine risolto.
Ogni misura era ragionevole. Nel loro insieme, tuttavia, non potevano rispondere a una domanda ovvia: se le escalation aumentano, cosa possiamo dedurne?
Il team ha suddiviso le escalation in otto sottotipi. Ha poi aggiunto misure relative ad abbandono, percorso e tempistiche, punteggi di comprensione linguistica e risoluzione per tipo di richiesta. Il quadro è arrivato infine a comprendere 31 metriche in sei categorie.
Poteva descrivere le escalation in dettaglio, ma non riusciva ancora a diagnosticarne in modo affidabile la causa. La maggior parte delle metriche era costituita da varianti dello stesso comportamento, quindi si muovevano insieme anziché verificare spiegazioni concorrenti.
La dashboard era diventata uno strumento di osservazione anziché di diagnosi.
Al team non serviva un ulteriore livello di scomposizione. Servivano metriche che si limitassero a vicenda.
Le chiamiamo coppie reciprocamente distruttive: due misure per cui il miglioramento isolato dell'una può danneggiare il risultato rappresentato dall'altra. Il nome descrive la modalità di errore prodotta da un'ottimizzazione unilaterale, non lo stato desiderato.
Quando entrambi gli aspetti restano solidi, il prodotto può funzionare in modo sostenibile. Quando divergono, la direzione della divergenza aiuta il team a decidere dove indagare.
Cosa avevamo | Coppia reciprocamente distruttiva | Cosa può rivelare la coppia |
|---|---|---|
Tasso di escalation suddiviso in otto sottotipi | Tasso di escalation ↔ tempo prima dell'escalation | Un'escalation immediata può indicare un problema di fiducia o di impostazione; una più tardiva può indicare che il sistema non riesce a completare l'attività. |
Tasso di contenimento e tasso di risoluzione riportati separatamente | Tasso di contenimento ↔ sentiment del cliente | Se il contenimento rappresenti una risoluzione soddisfacente o l'abbandono del tentativo da parte del cliente. |
Tasso di risoluzione per tipo di intento | Tasso di risoluzione ↔ profondità della conversazione | Se la risoluzione efficace sia efficiente o richieda un'interazione estenuante. |
Per approfondire come ciò emerge e come sfruttare questa informazione, consideriamo il tasso di escalation e il tempo prima dell'escalation. Il team non saprà come si comportano i clienti finché non arriveranno chiamate reali, ma può definire le ipotesi da verificare.
Se aumenta il numero di chiamate trasferite e i clienti abbandonano l'esperienza con l'IA nei primi 30 secondi, il team dovrebbe esaminare fiducia, trasparenza, tono e interazioni iniziali. Se i clienti richiedono l'escalation dopo aver tentato per diversi minuti di completare un'attività, è più probabile che il problema riguardi le funzionalità o la copertura del flusso di lavoro.
Il dato principale sulle escalation è lo stesso. La decisione sul prodotto è diversa.
Una coppia utile non dimostra da sola la causa. Restringe l'ambito dell'indagine e rende più chiara la decisione successiva.
L'esempio di Klarna presentato in precedenza mostra come applicare questo principio quando costi e qualità del servizio interagiscono. Mostra come un modello operativo basato sull'IA possa evolversi mentre un'azienda monitora l'impatto dei compromessi e impara dall'implementazione.
Nel febbraio 2024, l'azienda ha dichiarato che il suo assistente IA aveva gestito 2,3 milioni di conversazioni nel primo mese, svolto un lavoro equivalente a quello di 700 agenti a tempo pieno e ottenuto punteggi di soddisfazione dei clienti paragonabili a quelli degli agenti umani. Klarna stimava che l'assistente avrebbe contribuito a incrementare gli utili di 40 milioni di dollari nel 2024. Si trattava di risultati dichiarati dalla stessa Klarna, non di una valutazione indipendente.
Nel maggio 2025, l'amministratore delegato di Klarna ha affermato che l'azienda aveva dato troppa importanza alla riduzione dei costi nell'assistenza clienti e ha descritto i piani per ampliare l'accesso al supporto umano. Ciò rappresentava un adeguamento dell'equilibrio tra servizio automatizzato e umano, non un rifiuto dell'assistente IA o della tecnologia su cui si basa.
I dati pubblici mostrano perché le misure di efficienza vadano considerate insieme alle esigenze dei diversi clienti e tipi di interazione. Un sistema di IA può ottenere buoni risultati in media, mentre alcuni casi complessi, delicati o insoliti continuano a beneficiare di un canale umano facilmente accessibile.
Monitorare entrambi gli aspetti di questo rapporto aiuta un'azienda a decidere dove l'automazione crea valore, dove il supporto umano resta importante e come adeguare l'equilibrio all'emergere di nuovi dati.
Altre coppie reciprocamente distruttive nei prodotti di IA possono includere:
Coppia reciprocamente distruttiva | Rischio che aiuta a evidenziare |
|---|---|
Accuratezza della risposta ↔ latenza della risposta | Un sistema tecnicamente accurato, ma troppo lento per il flusso di lavoro. |
Completamento dell'attività ↔ tasso di intervento dell'utente | Un flusso di lavoro di IA che completa attività poi ripetute più volte dagli utenti. |
Costo per interazione ↔ qualità valutata dell'output | Risparmi ottenuti peggiorando l'esperienza di clienti o dipendenti. |
Adozione ↔ tempo necessario per ottenere valore | Aumento delle registrazioni non accompagnato da un valore corrispondente per gli utenti. |
L'obiettivo non è far aumentare entrambe le misure all'infinito. È rendere visibile il compromesso prima che un'ottimizzazione unilaterale generi un problema operativo.
Una difficoltà analoga è emersa nell'implementazione di un servizio di assistenza ai giocatori per un'azienda di giochi per dispositivi mobili. Il sistema gestiva problemi ad alto volume, come perdita dei progressi, contestazioni di pagamenti e accesso all'account.
Le misure di efficienza erano importanti perché il sistema operava su larga scala. L'assistenza ai giocatori, tuttavia, non è una semplice coda operativa. I giocatori spesso arrivano frustrati perché qualcosa è già andato storto in un'altra fase della loro esperienza.
Questo punto di partenza cambia il modo in cui vanno interpretati i dati sulla soddisfazione dei clienti. Un giocatore il cui problema viene risolto correttamente può comunque dichiararsi poco soddisfatto perché ha perso i progressi inizialmente. Leggere questo punteggio senza contesto può penalizzare l'interazione con l'assistenza a causa di una frustrazione nata in precedenza nel percorso del cliente.
Il team doveva quindi distinguere il sentiment iniziale del cliente dall'effetto dell'esperienza di assistenza. La domanda più utile non era: «Il giocatore era soddisfatto?» Era invece: «L'interazione ha migliorato la situazione rispetto al punto di partenza del giocatore?»
Questo confronto può aiutare a distinguere la frustrazione legata al prodotto dalla qualità dell'assistenza, purché il team disponga di un metodo affidabile per misurare entrambe.
I prodotti di IA cambiano, ma spesso le relative metriche rimangono fisse.
Durante un progetto pilota, la domanda centrale può essere se il sistema sia abbastanza affidabile da giustificare ulteriori investimenti:
Completa in modo affidabile l'attività principale?
Gli utenti si fidano abbastanza da continuare a usarlo?
Come si comporta al di fuori degli scenari più comuni?
È possibile individuare gli errori e ripristinare il funzionamento in sicurezza?
Queste domande favoriscono coppie come:
successo dell'attività principale ↔ prestazioni nei casi limite;
tasso di automazione ↔ tasso di intervento umano; e
velocità di completamento ↔ fiducia dell'utente.
Quando il prodotto acquista importanza operativa, le domande cambiano:
Può crescere su larga scala senza ridurre la qualità?
La sua redditività migliora con l'utilizzo?
Le prestazioni restano stabili con l'aumentare dell'adozione?
Gli interventi umani avvengono nei punti giusti?
Le coppie corrispondenti possono orientarsi verso:
costo per interazione ↔ qualità valutata dell'output;
ampiezza dell'adozione ↔ profondità d'uso; e
tasso di automazione ↔ esposizione al rischio operativo.
Le metriche iniziali non sono necessariamente sbagliate. Rispondono alle domande rilevanti in una fase precedente.
Il rischio emerge durante la transizione. Le metriche del progetto pilota spesso persistono perché i team sanno come presentarle e nessuno è responsabile della decisione di eliminarle. Misure che un tempo favorivano l'apprendimento possono trasformarsi gradualmente in metriche di vanità.
Le coppie dovrebbero quindi avere un ciclo di vita. I team dovrebbero introdurle per una decisione specifica, verificare se continuano a evidenziare un compromesso rilevante ed eliminarle quando cambiano il prodotto o la decisione.
I sistemi di IA richiedono osservabilità dettagliata, avvisi, controllo qualità e valutazione. Eliminare questi segnali renderebbe più difficile gestire il prodotto in sicurezza. Il monitoraggio operativo, tuttavia, non equivale alla misurazione a supporto della dirigenza.
Il monitoraggio aiuta i team a rilevare incidenti, ricostruire gli errori e comprendere il comportamento del sistema. Le metriche decisionali aiutano i responsabili di prodotto e aziendali a decidere se investire, intervenire, cambiare direzione o accettare un compromesso.
Un'organizzazione può monitorare centinaia di segnali tecnici e operativi, mettendo in evidenza solo due o tre coppie reciprocamente distruttive per una specifica decisione sul prodotto. Mantenere snello questo livello decisionale facilita la definizione delle priorità.
La frequenza di revisione appropriata dipende dal prodotto. Un sistema nuovo o in rapida evoluzione può richiedere revisioni decisionali settimanali, mentre per un prodotto maturo può bastare una frequenza mensile o trimestrale. Il principio conta più dell'intervallo: occorre riesaminare la coppia abbastanza spesso da intervenire prima che il compromesso diventi costoso o pericoloso.
Una coppia diventa utile solo quando l'organizzazione concorda cosa fare in caso di peggioramento.
Non basta definire una soglia critica per la divergenza. I team dovrebbero considerare tre condizioni:
Fallimento assoluto: una misura supera una soglia inaccettabile, indipendentemente dall'altra.
Divergenza: una misura migliora mentre quella che la controbilancia peggiora.
Peggioramento congiunto: entrambi gli aspetti peggiorano, suggerendo un problema più ampio del prodotto o delle attività operative.
Ogni coppia dovrebbe avere:
un responsabile designato;
una decisione chiara da supportare;
soglie o criteri di valutazione concordati;
un percorso di indagine; e
una serie di possibili interventi.
Senza questi elementi, l'organizzazione osserva il prodotto anziché gestirlo.
Prima di aggiungere un'altra misura, scegliete una decisione importante sul prodotto e affrontate queste domande. Annotate le risposte affinché la revisione si concluda con un passo successivo condiviso.
1. Quale decisione devono aiutarci a prendere queste metriche?
Siate specifici: dobbiamo decidere se ampliare l'automazione, cambiare modello o migliorare il passaggio a un operatore umano? Definite la decisione prima di scegliere le misure.
2. Se questo valore migliora, cosa potrebbe peggiorare?
Individuate il risultato da proteggere e una misura che riveli eventuali danni. Ad esempio, abbinate il costo per interazione alla qualità valutata dell'output per verificare se le risposte meno costose restano utili.
3. Cosa potrebbero nascondere i dati principali?
Analizzate entrambe le misure per gli stessi utenti, attività e periodi, quindi cercate i gruppi che ottengono risultati peggiori. Considerate anche le condizioni iniziali: una scarsa soddisfazione può riflettere una frustrazione precedente all'interazione con l'assistenza.
4. Cosa ci indurrebbe ad agire e chi è responsabile della risposta?
Definite criteri d'intervento per i casi in cui una misura superi un limite inaccettabile, una migliori mentre l'altra peggiora oppure entrambe peggiorino. Concordate chi condurrà l'indagine, cosa verificherà per prima cosa e quando riferirà i risultati.
5. Questa coppia è ancora adatta alla fase attuale del prodotto?
Decidete se mantenerla, sostituirla o eliminarla. Un progetto pilota può concentrarsi sull'affidabilità delle attività e sulla fiducia degli utenti; un servizio operativo può richiedere un esame più attento di costi e qualità. Fissate una data per riesaminare la scelta.
La misurazione dei prodotti di IA non dovrebbe limitarsi a descriverne le prestazioni. Dovrebbe evidenziare i compromessi accettati dall'organizzazione e rendere più chiara la decisione successiva.