Classificare i ticket di assistenza con l’AI: categorie, astensione e revisione umana

Parliamo del tuo progetto →

Usa l’AI come classificatore preliminare, non come motore di routing: definisci una tassonomia minima, fai astenere il modello sui casi ambigui e manda i ticket sensibili a revisione umana. È questo il punto pratico di questa guida, che si distingue dalla prova introduttiva Smistare i ticket con l’AI perché qui trovi un laboratorio completo: batch simulato, prompt copiabile, JSON atteso, registro e matrice di confronto.

L’impostazione è coerente con NIST AI RMF e OECD AI Principles: supervisione umana, tracciabilità e accountability non sono opzionali quando l’output può influire su decisioni operative.

Risultato finale atteso

Alla fine del laboratorio avrai:

una tassonomia minima di lavoro;
un CSV con 9 ticket fittizi T01–T09;
un prompt rigido che limita il modello al perimetro definito;
un JSON atteso per ciascun ticket;
un registro riutilizzabile per annotare esecuzione e controlli;
una matrice di confronto tra atteso e osservato;
una definizione separata di copertura e correttezza.

A chi serve

Questa guida è utile a:

team di customer support e service desk;
responsabili IT, operations o qualità;
PMI che vogliono un triage assistito senza automatizzare il routing;
chi deve impostare una prima policy di revisione umana.

Strumenti

Ti servono solo:

un foglio di calcolo o un editor CSV;
un ambiente in cui provare il modello AI;
un file di registro, anche in CSV;
una persona responsabile della revisione umana.

Prerequisiti

Prima di iniziare, chiarisci quattro punti:

l’AI assegna una categoria, ma non instrada il ticket;
l’AI può astenersi quando i dati non bastano;
i casi ambigui o sensibili passano a revisione umana;
il test usa solo dati simulati, mai ticket reali con contenuti riservati.

Materiale fornito nel laboratorio

Lavoreremo su un unico caso, coerente dall’inizio alla fine:

9 ticket fittizi T01–T09;
4 categorie: ACCOUNT, FATTURAZIONE, ERRORE_TECNICO, ASTENSIONE;
3 esiti operativi: classified, abstention, human_review.

Gli esempi sotto sono simulati: servono per verificare il processo, non per dichiarare risultati reali già ottenuti.

1. Definisci la tassonomia e le regole di astensione

Lavora prima sul documento di lavoro, non sul modello. La tassonomia minima è questa:

ACCOUNT: accesso, credenziali, account bloccato, autenticazione, reset password.
FATTURAZIONE: importi, ricevute, addebiti, rinnovi, metodi di pagamento, fatture.
ERRORE_TECNICO: crash, bug, errore applicativo, 500, blocco del sistema, malfunzionamento.
ASTENSIONE: testo troppo vago, informazioni insufficienti, due richieste simili o equivalenti, priorità non chiara.

Regole operative:

se una richiesta è chiaramente primaria, il modello può classificare;
se il testo è troppo vago, il modello deve astenersi;
se il ticket contiene due problemi di peso simile, il modello deve astenersi;
se il ticket contiene segnali di rischio o richiesta impropria, la categoria può restare quella più probabile, ma l’esito deve essere human_review.

Risultato atteso: il team usa le stesse parole per leggere i ticket.

Se qualcosa diverge: se compaiono etichette come “login”, “billing” o “bug” fuori standard, fermati e normalizza prima di eseguire il test.

2. Copia il batch T01–T09 senza il gold standard

Copia questo CSV in un file separato e non inviare al modello le colonne di atteso.

id,subject,body,expected_category,expected_outcome,notes
T01,Accesso bloccato,"Non riesco ad accedere da stamattina: dopo il reset la password viene accettata ma il sistema dice account bloccato.",ACCOUNT,classified,"Caso chiaro"
T02,Ricevuta errata,"La ricevuta di febbraio mostra un importo diverso dal piano attivo e non capisco il calcolo.",FATTURAZIONE,classified,"Caso chiaro"
T03,Errore dopo aggiornamento,"Dopo l'ultimo aggiornamento la pagina ordini va in errore 500 quando apro un dettaglio.",ERRORE_TECNICO,classified,"Caso chiaro"
T04,Password nel ticket,"Un collega mi ha chiesto di scrivere la password nel ticket perché non riesce a entrare.",ACCOUNT,human_review,"Segnale di rischio; non automatizzare"
T05,Problema generico,"Il servizio non funziona bene, credo sia lento ma non so dire quando succede o da quale area.",ASTENSIONE,abstention,"Dati insufficienti"
T06,Fattura o accesso?,"Non riesco a entrare nell'area clienti e inoltre la fattura mostra una doppia riga di addebito.",ASTENSIONE,abstention,"Due problemi equivalenti"
T07,Documento mancante e accesso,"Manca il PDF allegato e la mia utenza risulta disattivata da ieri.",ASTENSIONE,abstention,"Due richieste non separabili"
T08,Pagamenti,"Ho cambiato carta ma il rinnovo automatico continua a prendere il vecchio metodo di pagamento.",FATTURAZIONE,classified,"Tema prevalente: fatturazione/pagamento"
T09,Crash su mobile,"Su smartphone l'app si chiude appena apro il menu impostazioni.",ERRORE_TECNICO,classified,"Caso chiaro"

Risultato atteso: ogni riga ha un ID unico e i testi sono abbastanza brevi da essere letti dal modello.

Se qualcosa diverge: se il modello vede le colonne expected_*, il test è contaminato e va rifatto.

3. Usa un prompt rigido e ottieni solo JSON

Copia questo prompt così com’è. Serve a bloccare il modello dentro un formato verificabile.

Sei un classificatore di ticket di assistenza.
Obiettivo: assegnare una sola categoria tra ACCOUNT, FATTURAZIONE, ERRORE_TECNICO oppure ASTENSIONE.
Non prendere decisioni operative, non instradare automaticamente il ticket, non chiudere la richiesta e non scrivere messaggi al cliente.

Regole di classificazione:
1. ACCOUNT se il problema riguarda accesso, credenziali, reset, blocco account o autenticazione.
2. FATTURAZIONE se il problema riguarda importi, addebiti, ricevute, rinnovi, metodi di pagamento o fatture.
3. ERRORE_TECNICO se il problema principale è un errore del sistema, crash, bug, 500, malfunzionamento o blocco applicativo.
4. ASTENSIONE se i dati sono insufficienti, il testo è troppo vago, oppure il ticket contiene due richieste di peso simile e non c'è una richiesta primaria chiara.
5. Se il ticket contiene segnali di rischio, abuso, frode o richiesta impropria di credenziali, segnala comunque la categoria più probabile ma imposta outcome = human_review.
6. La confidenza è un supporto alla lettura, non una probabilità calibrata e non autorizza nessuna automazione.

Output richiesto: solo JSON valido con questi campi:
{
  "id": "T01",
  "category": "ACCOUNT | FATTURAZIONE | ERRORE_TECNICO | ASTENSIONE",
  "outcome": "classified | abstention | human_review",
  "secondary": null,
  "confidence": 0,
  "reason": "",
  "missing_fields": [],
  "human_checks": [""],
  "route": "manual queue only"
}

Vincoli:
- Se scegli ASTENSIONE, imposta outcome = abstention.
- Se scegli una categoria ma noti un rischio, imposta outcome = human_review.
- Non inventare dati mancanti.
- Non aggiungere testo fuori dal JSON.

Esempio normale e casi con errore o dato mancante

Qui sotto trovi tre esempi utili da confrontare con l’output del modello.

Caso normale: T01

{
  "id": "T01",
  "category": "ACCOUNT",
  "outcome": "classified",
  "secondary": null,
  "confidence": 96,
  "reason": "Problema di accesso con account bloccato dopo reset password.",
  "missing_fields": [],
  "human_checks": ["Verificare sblocco account", "Controllare eventuale lock policy"],
  "route": "manual queue only"
}

Caso con dato mancante: T05

{
  "id": "T05",
  "category": "ASTENSIONE",
  "outcome": "abstention",
  "secondary": null,
  "confidence": 88,
  "reason": "Descrizione troppo vaga: manca tempo, area, sintomo verificabile.",
  "missing_fields": ["quando succede", "area impattata", "frequenza", "sintomo preciso"],
  "human_checks": ["Chiedere dettagli minimi", "Non instradare automaticamente"],
  "route": "manual queue only"
}

Caso con revisione umana: T04

{
  "id": "T04",
  "category": "ACCOUNT",
  "outcome": "human_review",
  "secondary": null,
  "confidence": 78,
  "reason": "Richiesta impropria di credenziali nel ticket.",
  "missing_fields": [],
  "human_checks": ["Non chiedere la password nel ticket", "Escalare a revisione umana"],
  "route": "manual queue only"
}

Risultato atteso: il modello produce solo JSON e non decide il passaggio operativo.

Se qualcosa diverge: se il modello aggiunge testo libero, una seconda categoria o un campo inventato, scarta l’output e rilancia con il prompt corretto.

4. Compila il registro di esecuzione

Il registro serve a dimostrare che il test è stato fatto e controllato. Usa questo schema.

run_id,run_date,model_name,input_batch,records_total,records_classified,records_abstained,records_human_review,coverage,accuracy,notes,reviewed_by
R001,2026-10-13,"<nome_modello>","T01-T09",9,0,0,0,0,0,"Compilare dopo l'esecuzione","<nome_operatore>"

Compilalo così:

records_classified: ticket con outcome classified;
records_abstained: ticket con outcome abstention;
records_human_review: ticket da rivedere manualmente;
coverage e accuracy: calcolate solo dopo il confronto con il riferimento.

Risultato atteso: il test ha una traccia leggibile e riusabile.

Se qualcosa diverge: se il registro non distingue i tre esiti, non potrai misurare il comportamento reale del processo.

5. Confronta atteso e osservato senza confondere categoria e outcome

Usa una matrice separata per il confronto. La categoria può essere corretta mentre l’esito è sbagliato, oppure il contrario.

id,expected_category,expected_outcome,model_category,model_outcome,match_category,match_outcome,notes
T01,ACCOUNT,classified,,,,,
T02,FATTURAZIONE,classified,,,,,
T03,ERRORE_TECNICO,classified,,,,,
T04,ACCOUNT,human_review,,,,,
T05,ASTENSIONE,abstention,,,,,
T06,ASTENSIONE,abstention,,,,,
T07,ASTENSIONE,abstention,,,,,
T08,FATTURAZIONE,classified,,,,,
T09,ERRORE_TECNICO,classified,,,,,

Compila così:

model_category: cosa ha scelto il modello;
model_outcome: classified, abstention o human_review;
match_category: yes o no;
match_outcome: yes o no.

Come leggere i casi più delicati

T05: deve restare in astensione perché mancano i dettagli minimi.
T06: deve restare in astensione perché ci sono due problemi equivalenti.
T07: deve restare in astensione perché i due elementi non sono separabili con sicurezza.
T04: può avere categoria giusta, ma l’esito corretto è human_review.

Risultato atteso: il team vede subito se l’errore riguarda l’etichetta, l’escalation o entrambi.

Se qualcosa diverge: se controlli solo la categoria, perdi i casi in cui l’AI sembra “indovinare” ma sbaglia la gestione operativa.

6. Calcola copertura e correttezza sul piccolo set

Qui è fondamentale non usare una sola metrica generica. Su questo set conviene separare due domande diverse.

Copertura

La copertura misura quanti ticket ricevono un esito utilizzabile.

Puoi calcolarla in due modi, ma devi sceglierne uno e dichiararlo:

copertura automatica = ticket con outcome classified / ticket totali
copertura operativa = ticket con outcome classified o human_review / ticket totali

Sul gold standard simulato del batch T01–T09:

classified = 5 ticket;
human_review = 1 ticket;
abstention = 3 ticket.

Quindi:

copertura automatica = 5/9 = 55,6%;
copertura operativa = 6/9 = 66,7%.

Correttezza

La correttezza misura se il modello ha scelto la risposta giusta rispetto al riferimento.

Conviene separare anche qui:

correttezza di categoria = categorie corrette / ticket valutati
correttezza di outcome = esiti corretti / ticket valutati

Se il modello coincide con il gold standard simulato su tutti i 9 ticket, allora il valore massimo del set è:

correttezza di categoria = 9/9;
correttezza di outcome = 9/9.

Questo non significa che il modello sia “perfetto” in generale: significa solo che ha replicato il riferimento simulato su questo piccolo lotto.

Perché la distinzione conta

una copertura alta con correttezza bassa produce rumore veloce;
una correttezza alta con copertura troppo bassa produce un sistema prudente ma poco utile;
il rapporto tra i due numeri dice se il modello è pronto per un uso assistito o solo per una prova interna.

Risultato atteso: il report distingue bene tra “quanti ticket posso trattare” e “quanto spesso li tratto bene”.

Se qualcosa diverge: se scrivi un’unica percentuale senza definizione, il dato non è confrontabile e non aiuta la decisione.

7. Troubleshooting, prova finale e criteri di accettazione

Chiudi sempre con un controllo ripetibile. Se il modello o il processo non passano questi punti, non andare in produzione.

Troubleshooting rapido

Problema: il modello restituisce testo libero

Causa probabile: prompt troppo aperto.
Rimedi: chiedi JSON puro, vieta testo extra, usa validazione automatica del formato.

Problema: il modello inventa dati mancanti

Causa probabile: il prompt non vieta esplicitamente l’inferenza.
Rimedi: aggiungi la regola “non inventare dati mancanti” e verifica missing_fields.

Problema: troppe classificazioni forzate

Causa probabile: la soglia di astensione è troppo bassa.
Rimedi: alza il peso dell’astensione su testi vaghi o doppi.

Problema: i casi sensibili non arrivano a revisione umana

Causa probabile: il workflow considera solo la categoria.
Rimedi: controlla outcome oltre a category.

Prova finale ripetibile

Il test si può considerare valido solo se tutti questi punti sono veri:

il batch T01–T09 è stato caricato senza le colonne di atteso;
il modello ha restituito solo JSON valido;
T05, T06 e T07 sono stati gestiti con astensione;
T04 è passato a revisione umana;
nessun ticket è stato instradato automaticamente;
il registro è compilato;
la matrice di confronto mostra categoria e outcome separati;
le metriche sono state calcolate con la definizione dichiarata.

Criteri di accettazione minimi

Accetta il laboratorio solo se:

ogni output è leggibile e validabile;
il sistema non confonde astensione e classificazione;
la revisione umana entra davvero nei casi giusti;
il team sa spiegare perché un ticket non è stato forzato in una categoria.

Collegamenti interni utili

Se vuoi portare questo schema oltre il laboratorio e trasformarlo in processo governato, questi approfondimenti sono coerenti con la stessa logica:

Il passaggio pratico è sempre lo stesso: descrivi il processo che vuoi migliorare, non il modello che vorresti provare.