Triage AI delle segnalazioni: cosa si chiude da solo e cosa no

Nel nostro CRM c'è un pulsante che non sparisce mai, in qualunque schermata ci si trovi: serve a segnalare un problema. L'abbiamo voluto sempre visibile per una ragione banale. Se per segnalare qualcosa bisogna prima cercare dove si fa, la segnalazione non arriva. Chi lavora ha in testa una trattativa, una visita, un documento da mandare, non il nostro software. Il pulsante deve costare un clic e niente di più.

Quello che succede dopo il clic, invece, è la parte su cui abbiamo ragionato di più. Ogni segnalazione finisce in una tabella, e da lì parte un triage automatico fatto con l'AI. Qui raccontiamo come funziona e, soprattutto, una regola che abbiamo deciso di non mettere mai in discussione.

Cosa fa il triage appena arriva una segnalazione

Nel momento in cui la segnalazione viene creata, il triage fa tre cose.

1. Scrive una prima diagnosi. Non è la verità rivelata: è un'ipotesi leggibile su cosa possa essere andato storto, messa per iscritto accanto alla descrizione di chi ha segnalato. Serve a chi la prenderà in mano dopo, per non partire da zero.
2. Classifica il problema. Dare un tipo a ogni segnalazione permette di distinguere a colpo d'occhio, per esempio, un'operazione da rifare da un difetto vero del software.
3. Cerca segnalazioni simili già risolte. È il passaggio più utile. Un CRM che si usa tutti i giorni tende a produrre gli stessi inciampi, e capita che qualcuno segnali una cosa già successa e già sistemata.

Quando una segnalazione si chiude da sola

Se il triage trova un precedente, guarda com'era stato risolto. Ogni rimedio può essere marcato come riusabile oppure no. Riusabile vuol dire che si può applicare di nuovo, tale e quale: per esempio un'operazione da ripetere.

In quel caso la segnalazione si chiude da sola, applicando lo stesso rimedio. Chi ha segnalato non resta in attesa per una cosa che conosciamo già, e noi non perdiamo tempo a ridiagnosticare un problema che ha già una risposta.

Detta così sembra la parte facile. In realtà è la parte che va recintata meglio, perché un sistema che chiude le cose da solo è comodo esattamente fino al giorno in cui chiude quella sbagliata.

La regola che non si negozia

Abbiamo fissato due vincoli, e li trattiamo come non negoziabili.

Il primo: ogni chiusura scrive il rimedio. Nessuna segnalazione viene chiusa senza che resti traccia di cosa è stato fatto. Non basta «risolto». Se manca il rimedio, il prossimo triage non ha niente da riconoscere, e la memoria del sistema si svuota proprio dove servirebbe.

Il secondo: un rimedio che è una correzione di codice non è mai riusabile. Mai, nemmeno quando sembrerebbe comodo.

Il motivo è questo. Un'operazione da ripetere è per sua natura qualcosa che può servire di nuovo: rifarla è la cura. Una correzione di codice, invece, dovrebbe chiudere il problema una volta per tutte. Se lo stesso guasto si ripresenta dopo che il codice è stato corretto, non siamo davanti a un caso noto: siamo davanti a una regressione. Qualcosa che avevamo sistemato si è rotto di nuovo, oppure la correzione non era quella giusta.

Se quel rimedio fosse marcato riusabile, il triage farebbe la cosa più ragionevole dal suo punto di vista: riconoscerebbe il precedente, vedrebbe che era stato risolto e chiuderebbe la nuova segnalazione. In silenzio. Il registro direbbe che va tutto bene e il difetto resterebbe nel software, con l'aggravante di sembrare già affrontato. È il genere di errore che non fa rumore, e per questo è il più costoso.

Per questo la regressione deve restare visibile. Una segnalazione che ricorda una correzione di codice non si chiude da sola: resta aperta, con il precedente accanto, e qualcuno la deve guardare.

Chi tocca il codice, e come

Le correzioni di codice le facciamo in una sessione di lavoro con Claude, seguendo una procedura scritta. La procedura va letta prima di toccare le segnalazioni, non dopo e non a metà.

Non è burocrazia. La procedura è il posto dove abbiamo messo per iscritto proprio le regole di questo articolo: come si chiude una segnalazione, che cosa si scrive nel rimedio, quando un rimedio può essere marcato riusabile e quando no. Una sessione che parte senza averla letta rischia di fare la cosa più naturale, cioè sistemare il problema e chiudere, magari marcando il rimedio come riusabile perché «ha funzionato». È esattamente il comportamento che vogliamo escludere.

Leggerla prima vuol dire che chi lavora sul codice, persona o modello che sia, parte con lo stesso contratto: la correzione si fa, il rimedio si scrive, e la porta della chiusura automatica per quel tipo di guasto resta chiusa.

Cosa ci portiamo a casa

Tre cose, che valgono anche fuori dal nostro CRM.

• L'automazione va bene per ciò che si ripete per natura. Un'operazione da rifare è un ottimo candidato alla chiusura automatica. Un difetto del software no: se torna, è una notizia.
• La memoria vale solo se si scrive. Il triage riconosce i precedenti perché ogni chiusura lascia un rimedio. Senza quel rimedio scritto, la ricerca di casi simili non trova niente di utile.
• Le regole che contano vanno scritte dove si lavora. Una procedura da leggere prima di cominciare costa pochi minuti e toglie di mezzo l'errore più probabile, che non è quello tecnico ma quello di chiudere troppo in fretta.

Il pulsante resta sempre lì, in ogni schermata. Quello che abbiamo imparato a curare è cosa succede dopo, e soprattutto che cosa non deve mai succedere da solo.