Il tasso di risoluzione di un agente AI indica una quota di richieste che il sistema considera risolte. Per usarlo nella scelta di un fornitore o nel rinnovo di un pilota, serve sapere quali richieste entrano nel conto, quale evento vale come risoluzione e quanto si aspetta prima di assegnare l’esito.
Quaranta richieste etichettate come risolte possono produrre un tasso del 66,7% oppure dell’80%, anche mantenendo gli stessi esiti. Basta cambiare il perimetro su cui si calcola la percentuale. Le definizioni dei fornitori aiutano a capire il motivo; un esempio su cento richieste permette di vedere che cosa chiedere prima di confrontare due numeri.
Prima del valore, identifica la metrica
Il denominatore è la popolazione su cui si calcola il rapporto. Può comprendere tutte le richieste ricevute, soltanto quelle affidate all’AI o le conversazioni in cui l’agente ha effettivamente potuto rispondere. Anche l’unità conta: una richiesta del cliente può proseguire in più conversazioni.
Intercom ha documentato nel 2026 una modifica a Fin Involved: vengono escluse le conversazioni in cui Fin era attivo ma non aveva avuto l’opportunità di rispondere, per esempio a causa di un vincolo configurato. Il resolution rate rapporta le risoluzioni alle conversazioni coinvolte; l’involvement rate rapporta queste ultime al totale delle conversazioni. Nell’aggiornamento citato, l’automation rate è la quota di risoluzioni sul totale. Escludere i casi senza opportunità può quindi alzare il resolution rate e abbassare l’involvement rate, lasciando invariati numero di risoluzioni, automation rate e fatturazione. Aggiornamento delle metriche Fin.
Un aumento dovuto a questa definizione non basta a sostenere un miglioramento del servizio. Può rendere il report più adatto a una domanda diversa: quanto risolve Fin quando ha l’opportunità di rispondere?
Anche il prodotto e il modello dell’account vanno identificati prima del confronto. I resolution tiers di Zendesk sono categorie con cui il servizio classifica gli esiti delle conversazioni. Nel relativo modello il tasso riportato include Contained + Verified, ma soltanto Verified è fatturato. Contained comprende conversazioni senza richieste di chiarimento, feedback sulla risposta o richieste di un operatore, che non hanno superato la verifica del fornitore. Verified richiede che il cliente non chieda ulteriore assistenza e che la conversazione superi quella verifica, svolta da un LLM, un modello linguistico.
La categoria Verified non equivale necessariamente a una conferma esplicita del cliente. Gli account ancora sulla piattaforma pre-tier vanno distinti da quelli migrati e dalla separata funzionalità legacy Essential: per scegliere la definizione applicabile occorre identificare il modello effettivo dell’account. Cambiamento del reporting, tier e verifica, identificare il modello dell’account.
Per ogni percentuale conviene farsi consegnare una definizione breve ma completa:
| Campo | Domanda da risolvere |
|---|---|
| Popolazione e unità | Si contano richieste, conversazioni o clienti? Quali casi sono esclusi? |
| Evento contato | Basta una risposta, il silenzio, una valutazione automatica o serve una prova dell’esito? |
| Finestra | Da quale evento parte? Quando il risultato diventa osservabile? |
| Versione | Quale definizione, modello dell’account e data di estrazione descrive il report? |
Chiusura, risoluzione e addebito hanno regole proprie
Nel catalogo Intercom una risoluzione presunta viene descritta con un’autochiusura dopo tre minuti. La pagina di pricing Fin per l’uso con un helpdesk esterno parla invece di 24 ore dall’ultima risposta senza ulteriore interazione. Queste pagine si riferiscono a contesti d’uso e finalità differenti; non chiariscono il raccordo operativo fra i due timer. Per applicarli a un acquisto serve la regola dell’account interessato. Catalogo Intercom, pricing e outcome Fin.
Nei tier Zendesk, la fine della conversazione usata per la valutazione decorre dalla prima email o dal primo messaggio: 72 ore per l’email; due ore per il messaging, con estensione documentata tramite supporto. Chiamarle ore di inattività cambierebbe l’ancora del conteggio. Regole dei tier.
L’outcome fatturato può inoltre comprendere un passaggio intenzionalmente configurato a una persona o a un workflow. Fin distingue questi Procedure handoffs dalle escalation predefinite o di workspace. Un addebito per outcome non può quindi essere letto direttamente come numero di problemi risolti senza intervento umano. Outcome Intercom.
Gli stessi cento casi, tre rapporti diversi
L’esempio seguente usa richieste ed etichette interamente inventate. Serve a verificare il ragionamento e i calcoli; non riproduce i classificatori o le dashboard di Intercom e Zendesk.
La coorte comprende cento richieste iniziali, ciascuna associata a un problema. Per sessanta l’AI ha un’opportunità di risposta. Quaranta ricevono una generica etichetta simile a “risolto”. Separatamente, il dataset assegna ventotto esiti autonomi positivi con osservazione completa.
| Quantità costruita | Conteggio |
|---|---|
| Richieste iniziali, N | 100 |
| Opportunità AI, E | 60 |
| Etichette simili a “risolto”, R | 40 |
| Esiti autonomi positivi con finestra completa, G | 28 |
| Evidenza insufficiente nel perimetro AI | 4 |
| Follow-up ancora incompleto | 1 |
| Casi noti non autonomi nel perimetro AI | 27 |
Le ultime quattro righe ripartiscono le sessanta opportunità: 28 + 4 + 1 + 27. R è un’altra classificazione degli stessi casi e non va sommato a queste righe. Le quaranta richieste fuori dal perimetro AI non sono classificate da questa ripartizione.
I rapporti rispondono a domande diverse:
- R/E = 40/60 = 66,7%: quante opportunità AI hanno ricevuto l’etichetta?
- R/N = 40/100 = 40%: quale quota delle richieste iniziali ha ricevuto quell’etichetta?
- G/N = 28/100 = 28%: quale quota ha l’esito autonomo positivo assegnato nell’esempio, con finestra completa?
Per vedere l’effetto del perimetro, escludiamo dieci opportunità che non avevano né l’etichetta R né l’esito G. E scende a cinquanta: R/E sale all’80%, mentre R/N resta al 40% e G/N al 28%. La copertura AI, E/N, scende dal 60% al 50%.
La regola di selezione può essere sensata: otto dei dieci casi esclusi hanno un passaggio al reparto corretto accettato entro la scadenza prevista dall’esempio. Il tasso più alto descrive però una popolazione più ristretta. Per decidere sul pilota servono anche copertura ed esiti sul totale.
Questi rapporti usano una popolazione didattica comune. Il catalogo Fin include nel resolution reporting le risoluzioni ottenute tramite Custom Answers, comprese le conversazioni risolte da una Procedure, la cui risposta viene classificata come Custom Answer. L’automation esclude Custom Answers e Procedure handoffs. Prima di combinare percentuali del prodotto occorre controllare che numeratori e denominatori coprano le stesse categorie. Definizioni e condizioni del catalogo Fin.
Quale prova rende l’esito credibile?
Nel dataset, il caso C015 non contiene una conferma del cliente ma ha un esito positivo costruito. C029 contiene una conferma e un successivo ritorno per lo stesso problema ancora aperto. Il segnale visibile e la prova del risultato possono divergere in entrambe le direzioni.
In un pilota reale bisogna definire prima come controllare l’obiettivo del cliente: per esempio, verificare che una modifica richiesta sia stata applicata correttamente. Dove la prova manca, l’esito resta ignoto. L’assenza di un ricontatto, da sola, non colma quel vuoto. È lo stesso problema di fondo della verifica delle affermazioni di un agente: il resoconto deve corrispondere al risultato controllato.
Anche il tempo richiede un contratto esplicito. Nell’esempio la finestra W è di sette giorni dalla prima risposta AI, una scelta didattica. La raccolta comprende richieste del 1° ottobre e viene congelata il 9. C060 riceve la prima risposta soltanto il 4 ottobre alle 11 UTC: completa i sette giorni l’11 ottobre alle 11 UTC e al congelamento resta in osservazione. Aspettare sette giorni dalla raccolta delle richieste non assicura lo stesso follow-up per tutte.
I ritorni si contano per richiesta iniziale. Sei riaperture e sette nuove conversazioni riguardano dieci richieste, perché tre compaiono in entrambi i gruppi: 6 + 7 − 3 = 10. Il rapporto 10/40 = 25% descrive richieste inizialmente etichettate R con un ritorno sul problema ancora aperto entro W. Non coincide con le metriche native di recontact di Intercom, che hanno proprie finestre e denominatori. Metriche di ricontatto.
Il registro da chiedere per il pilota
Un confronto controllabile conserva una riga per richiesta iniziale e collega a quella riga conversazioni e ritorni. La definizione del problema e l’unione fra canali richiedono lavoro: vanno riesaminati i collegamenti dubbi, non soltanto esportati gli ID.
| Informazione | Che cosa permette di controllare |
|---|---|
| ID richiesta, cliente/problema e conversazioni collegate | Unità di conteggio e ritorni sullo stesso problema |
| Inclusione nel perimetro AI e motivo di esclusione | Copertura e selezione dei casi |
| Etichetta nativa e relativa versione | Ricostruzione del report del fornitore |
| Obiettivo, prova dell’esito e bisogno di intervento umano | Esito autonomo, non autonomo o ignoto |
| Prima risposta AI, fine finestra e data di congelamento | Follow-up completo o ancora aperto |
| Reparto, richiesta di passaggio e accettazione | Presa in carico corretta entro il termine concordato |
La presa in carico va misurata separatamente dalla risoluzione autonoma. Nell’esempio quindici richieste richiedono un passaggio; dodici raggiungono il reparto corretto e vengono accettate entro 24 ore dalla richiesta. Il 12/15 = 80% misura quella presa in carico, non la soluzione finale del problema.
L’export deve comprendere il denominatore, non soltanto gli eventi addebitati. La documentazione Zendesk descrive viste di usage e report analytics distinti; prima di ricostruire il tasso, occorre verificare quali categorie e periodi contiene l’export disponibile sull’account. Usage, export analytics.
Per decidere se proseguire il pilota, concorda i criteri e la selezione del campione prima della valutazione. Fai riesaminare una parte degli esiti senza mostrare l’etichetta del fornitore, registrando disaccordi, prove mancanti e collegamenti incerti. Tieni separati i controlli sul campione da quelli mirati su ignoti e richieste ad alto rischio.
Accanto al consumo software, conta il tempo per configurare le fonti, correggere risposte, valutare gli esiti, gestire escalation e ricontatti e mantenere l’integrazione. Un confronto economico utile riguarda il lavoro necessario per ottenere il risultato del servizio. Se una differenza fra percentuali scompare allineando popolazioni e criteri, quella differenza non sostiene più la graduatoria iniziale.
Rifare i conti
I due allegati contengono il dataset sintetico completo e il programma per ricalcolarlo. Scaricali nella stessa cartella; dal secondo documento copia il blocco Python in un file chiamato recalculate-support.py. Servono Python 3.10 o successivo e la libreria standard.
Dalla cartella che contiene dataset e programma:
python3 recalculate-support.py support-cohort.json --self-checkL’output atteso riporta N=100, E=60, R=40, G=28, quattro casi senza evidenza sufficiente, un follow-up incompleto, dieci richieste con ritorno e dodici passaggi corretti accettati su quindici. I nove controlli del pacchetto riguardano questa aritmetica e le etichette costruite, inclusi ritorni duplicati e finestre ancora aperte. Il pacchetto è stato eseguito con Python 3.15.2.
La distinzione fra denominatori, risoluzione e ricontatti è già discussa nell’analisi di Communicate. Il registro qui proposto riunisce questi controlli prima della decisione sul pilota.