Jev AI, confidence e probabilità: quando far intervenire una persona

La confidence di Jev AI aiuta a scegliere quali decisioni revisionare, ma non equivale all’accuratezza. Una soglia utile dipende dall’azione, dal costo di un errore e dai risultati del tuo processo: il numero, da solo, non autorizza l’automazione.

Prima del numero, stabilisci cosa può succedere

Immagina un messaggio che chiede assistenza per un macchinario. Puoi assegnarlo a un reparto, marcarlo come urgente, preparare una risposta oppure autorizzare un intervento a pagamento. Sono quattro decisioni con costi diversi. Riunirle sotto una generica soglia di sicurezza nasconde il vero problema: quanto danno provoca una scelta sbagliata e chi può correggerla.

Nella guida a Jev AI trovi il quadro generale. Qui interessa il momento successivo: il modello ha restituito un risultato e il software deve decidere se usarlo. Il titolare del processo dovrebbe scrivere una frase precisa per ogni azione. Per esempio: un inoltro errato si corregge in pochi minuti; una promessa contrattuale sbagliata può impegnare l’azienda. Le regole operative devono riflettere questa differenza.

Un percorso sensato ha almeno tre uscite: esecuzione consentita, revisione necessaria e informazioni insufficienti. La terza uscita evita di trasformare ogni dubbio in un lavoro manuale completo. A volte manca semplicemente il numero d’ordine: chiedere quel dato può risolvere il caso meglio di un supervisore che prova a indovinarlo.

Il pattern ufficiale di routing guidato dalla confidence separa il risultato dalla decisione di eseguirlo. Le soglie degli esempi non sono standard universali; autorizzazione e azione restano nell’applicazione. Nel progetto, questo significa poter cambiare una soglia senza concedere nuovi permessi al sistema.

Il calcolo che rende visibile la differenza

La documentazione Confidence definisce per Choice la formula (pmax − 1/n) / (1 − 1/n). Con tre opzioni e probabilità ipotetiche 0,8, 0,1 e 0,1, il risultato è 0,7. È un calcolo didattico, non una chiamata osservata. Score usa una formula diversa: quella di Choice non va trasferita agli altri risultati.

Il valore 0,8 del nostro esempio appartiene all’opzione più probabile. Il valore 0,7 deriva dalla formula. Nessuno dei due, in questo esempio costruito a tavolino, dimostra quante assegnazioni corrette otterrebbe un ufficio assistenza italiano. Per saperlo occorrono messaggi reali o rappresentativi, decisioni di riferimento e un confronto registrato.

Questa distinzione conta anche nell’interfaccia interna. Un indicatore etichettato semplicemente “affidabilità” invita il collega a interpretarlo come una garanzia. Meglio mostrare il nome della misura, l’azione proposta e la regola che ha inviato il caso in revisione. Il revisore deve capire perché il sistema si è fermato, senza essere spinto ad approvare dal colore di un numero.

Per Noul, invece, il campo .noul esprime una probabilità da zero a uno rispetto a una proposizione; non esiste un campo confidence separato. Una domanda positiva e una formulata al contrario richiedono regole coerenti. Probabilità di sì e intensità di una caratteristica sono concetti diversi.

Se chiedi se una richiesta contiene un reclamo, una probabilità alta riguarda quella proposizione. Non misura quanto il cliente sia arrabbiato. Per progettare lo smistamento dei ticket, tieni separati la categoria del messaggio, l’urgenza operativa e la necessità di una persona: le tre decisioni non dovrebbero ereditare automaticamente lo stesso trattamento.

Costruire una tabella delle conseguenze

La tabella seguente è una proposta di progettazione. Non contiene soglie raccomandate dal fornitore né prestazioni misurate. Serve a rendere discussioni e responsabilità concrete prima di aggiungere numeri al software.

Nel lead scoring del CRM, una valutazione può servire a ordinare il lavoro del giorno. Non dovrebbe diventare automaticamente un rifiuto commerciale. Una richiesta posizionata in fondo deve avere un tempo massimo di lettura, altrimenti una previsione imperfetta si trasforma in esclusione permanente.

Anche la revisione ha un costo. Se la regola manda quasi tutto a una persona, il sistema aggiunge un passaggio senza liberare capacità. Se manda pochissimo, può nascondere errori. Occorre cercare un equilibrio misurabile: quantità automatizzata, errori residui e carico sostenibile per chi controlla. La soglia è uno strumento per trovare quell’equilibrio, non l’obiettivo del progetto.

Caso ipotetico: un’assistenza tecnica in Brianza

Consideriamo una PMI italiana ipotetica che installa impianti e riceve email miste: manutenzione, fatture, ricambi e richieste commerciali. Il responsabile parte dallo smistamento, perché correggere un reparto è reversibile. Tiene fuori dal pilota l’invio di preventivi e le promesse sulla disponibilità dei tecnici.

Due colleghi classificano un campione separatamente. Quando non concordano, chiariscono prima la regola aziendale. Un messaggio su un ricambio in garanzia appartiene all’assistenza o al magazzino? Se la risposta cambia da persona a persona, il modello non può risolvere l’assenza di una convenzione interna. Il campione corretto diventa anche una piccola guida per i nuovi operatori.

Nel pilota, l’automazione propone il reparto ma non sposta ancora le email. Il gruppo confronta la proposta con l’assegnazione approvata, registra le differenze e distingue gli errori innocui da quelli che ritarderebbero un intervento urgente. Una media unica farebbe perdere questa informazione: sbagliare magazzino e trascurare un fermo impianto non pesano allo stesso modo.

Dopo la valutazione, l’azienda può attivare lo spostamento per una parte dei casi. I messaggi senza impianto identificabile vanno a integrazione; quelli ambigui restano nella coda del responsabile. Un campione delle email spostate viene comunque controllato. Sono scelte ipotetiche di processo: nessuna percentuale di successo è stata misurata da Giallo Studio in questo scenario.

Il principio si ritrova nel confronto con le decisioni probabilistiche sui ticket: il giudizio diventa utile quando ha un percorso operativo definito. Un dashboard che mostra probabilità senza indicare chi deve intervenire lascia intatto il collo di bottiglia.

Caso ipotetico: priorità per un distributore B2B

Una seconda PMI italiana ipotetica distribuisce componenti industriali. Il commerciale vuole leggere prima le richieste pertinenti, ma alcune email brevi arrivano da clienti importanti e non contengono tutti i dettagli. Se il sistema premia soltanto i messaggi ricchi di informazioni, potrebbe penalizzare proprio chi conosce già il catalogo.

Il responsabile separa pertinenza, completezza e urgenza. Per la completezza basta un elenco di dati richiesti dal processo; per la priorità decide quali elementi contano davvero. Il risultato alimenta una lista di lavoro, mentre ogni contatto riceve comunque una lettura entro un termine concordato. L’azione automatizzata resta circoscritta all’ordinamento.

I casi in revisione vengono divisi per motivo: descrizione insufficiente, richiesta fuori catalogo, regole in conflitto. Il commerciale non deve correggere soltanto un punteggio. Può modificare la priorità e annotare un motivo concreto, come cliente già seguito o compatibilità da verificare. Quel motivo aiuta a capire se manca un dato al sistema o se il criterio è scritto male.

Qui una strategia con modelli diversi può servire quando un passaggio richiede un lavoro diverso, per esempio preparare una bozza dopo la scelta. L’escalation non deve però diventare una gara tra modelli fino a ottenere il risultato desiderato. Se due valutazioni divergono, il processo deve conservare il dubbio e assegnarne la risoluzione.

Come scegliere la soglia senza inseguire un numero

Parti da un insieme di valutazione che non usi per riscrivere continuamente i criteri. Se guardi ogni errore e modifichi la domanda sullo stesso gruppo di esempi, puoi migliorare il risultato apparente senza sapere come si comporterà sui messaggi successivi. Tieni separati i casi utili alla progettazione e quelli destinati al controllo finale.

Per ciascuna soglia candidata, conta le decisioni che sarebbero automatiche, gli errori in quel gruppo e i casi inviati a revisione. Non scegliere soltanto la maggiore automazione. Confronta il carico della coda con il tempo disponibile e controlla se gli errori si concentrano in una categoria. Una classe rara può meritare un percorso dedicato anche quando la media complessiva sembra buona.

Se il campione è piccolo, annota il numero assoluto dei casi. Dire che una categoria ha zero errori su quattro messaggi è diverso dal dirlo su quattrocento. Il primo risultato può essere utile per individuare un problema evidente, ma non basta a trattare quella categoria come stabile. Evita anche confronti tra periodi con una composizione di richieste molto diversa.

Il costo di un errore può essere espresso prima in conseguenze concrete: minuti persi, cliente ricontattato, attività ripetuta. Trasformarlo in euro è utile soltanto se l’azienda dispone di stime credibili. Inventare un importo preciso per rendere elegante la tabella renderebbe meno solida la decisione.

Apri una scheda pratica per la revisione

Prima della decisione: mostra il messaggio pertinente, le opzioni ammesse e il motivo della revisione.

Durante il controllo: consenti approvazione, correzione o richiesta di informazioni, senza obbligare a scegliere una categoria inadatta.

Dopo: registra il motivo concreto della modifica e il tempo necessario. Un responsabile rivede periodicamente i criteri che generano più disaccordi.

Dimensionare la coda prima di attivarla

Prendiamo un calcolo organizzativo ipotetico: quaranta casi al giorno in revisione, novanta secondi per caso, significano un’ora di lavoro. Il calcolo non misura Jev e non include interruzioni, richieste di informazioni o pratiche che richiedono un secondo collega. Serve a verificare se la persona indicata come responsabile possiede davvero quella capacità nella giornata.

Il volume medio non basta. Se le richieste arrivano soprattutto in una fascia oraria, una coda gestibile nell’arco del giorno può comunque ritardare le urgenze. Nel progetto, proponiamo di registrare il momento di ingresso, l’inizio della revisione e la chiusura. Il tempo trascorso in attesa è distinto dal tempo impiegato a leggere il caso.

Definisci anche una gestione per assenze e accumuli. Il responsabile può trasferire i casi a un sostituto, restringere temporaneamente il perimetro automatico o tornare al processo precedente. Non dovrebbe alzare la soglia in modo casuale per svuotare la coda, perché cambierebbe il rischio senza una valutazione.

Un revisore sovraccarico tende ad approvare più rapidamente. Per osservare questo problema, confronta i motivi delle correzioni e il numero di casi approvati senza modifiche nelle diverse condizioni di carico. Una differenza non prova da sola disattenzione, ma indica dove approfondire con il collega. Il sistema deve sostenere il suo lavoro, non renderlo un timbro finale.

La decisione di automatizzare una nuova categoria dovrebbe includere questa stima di capacità. Anche con pochi errori, un flusso che genera troppa revisione può non essere utile. Il risultato atteso è un percorso sostenibile per l’ufficio, con qualcuno che sa cosa fare quando il caso non si chiude.

Il controllo continua dopo l’avvio

La coda umana non è un contenitore senza fondo. Deve avere una persona assegnata, un tempo di gestione e una regola per i casi scaduti. Se un dubbio resta fermo per tre giorni, il processo può essere peggiore dello smistamento precedente. L’ufficio dovrebbe poter sospendere l’automazione di una categoria senza fermare tutto il flusso.

Serve inoltre un controllo delle decisioni già eseguite. La revisione dei soli casi dubbi misura il lavoro del revisore, ma non rivela gli errori passati attraverso il percorso automatico. Un campione periodico, scelto anche tra le categorie meno frequenti, permette di vedere quei casi. Conserva la distinzione tra errore del criterio, dato mancante e decisione sbagliata.

Quando cambia una policy commerciale o nasce un reparto, ripeti una valutazione pertinente. Mantieni traccia della versione dei criteri e della configurazione usata, così puoi spiegare perché una decisione di settembre differisce da una di ottobre. La verifica delle citazioni richiede lo stesso principio quando il risultato riguarda il supporto di una fonte.

Prima di usare messaggi aziendali, prepara anche il pilota italiano e la valutazione dei dati. I revisori hanno bisogno degli elementi utili, non di una copia indiscriminata del CRM. Progettare il circuito umano attraverso una consulenza AI significa definire responsabilità e misure prima di mettere una soglia in produzione.

Costruiamo un pilota con criteri, campione di controllo e revisione umana per il tuo processo.