Approfondimenti dal responsabile dell’AI di Hiver
La maggior parte delle persone pensa che sviluppare funzionalità di AI per una piattaforma di assistenza clienti significhi solo pianificare, eseguire e lanciare.
Ma se parli con chi lavora dietro le quinte, capisci quanto la realtà sia in realtà molto diversa.
Anurag Maherchandani, responsabile AI di Hiver, è una di queste persone. Presso Hiver, una piattaforma di servizi clienti potenziata dall’AI e utilizzata da oltre 10.000 team di supporto per gestire le conversazioni con i clienti su larga scala, la pressione di “aggiungere AI” è arrivata presto e si è sentita molto. Ogni casella di posta, ogni ticket, ogni interazione col cliente sembrava un candidato naturale per l’automazione.
Anurag guida tutte le iniziative di Hiver's AI, il che significa che è responsabile di decidere cosa costruire, come farlo e perché dovrebbe essere importante per i clienti. Ecco la sua opinione su ciò che serve davvero per sviluppare funzionalità di AI che funzionano davvero.
Partire dal risultato, non dal modello
Il principio fondamentale dietro ogni decisione AI in Hiver: l’AI non è il prodotto. Il risultato è il prodotto.
In pratica, questo significa che il punto di partenza per qualsiasi funzionalità AI non è mai “cosa può fare questo modello?” ma “dove le persone spendono tempo in decisioni che non dovrebbero prendere?”
Questa distinzione influenza tutto ciò che segue, dalla scelta del problema a come la funzionalità viene presentata nell’interfaccia utente.
“Quando i team dicono che stanno ‘costruendo un prodotto AI’, di solito intendono che hanno integrato un modello, lo hanno esposto tramite una UI e hanno ottenuto numeri di accuratezza alti. Ma nulla di tutto ciò garantisce valore. Gli utenti non acquistano l’intelligenza. Acquistano sollievo: dal lavoro ripetitivo, dall’incertezza, dall’attrito operativo”, dice Anurag.
Anche se un modello sembra eccellente nei test, il vero banco di prova è se cambia davvero il modo di lavorare degli utenti.
Inferenza o regole: scegli prima lo strumento giusto
Prima che qualsiasi problema arrivi alla fase di scelta del modello o valutazione dei dati, sorge una domanda più fondamentale: serve davvero l’inferenza?
Per inferenza si intende che il sistema deve generalizzare da schemi che non ha visto esplicitamente, prendendo decisioni che non possono essere completamente definite in anticipo.
Le regole invece consentono di scrivere la logica in modo esplicito: se X, allora Y. Le due cose non sono intercambiabili e utilizzare l’inferenza quando basterebbero le regole aggiunge costi, latenza e imprevedibilità senza alcun beneficio.
Quando il team di Hiver ha dovuto impostare l’instradamento per email provenienti da segmenti specifici di clienti come account VIP, alcuni settori o domini particolari, l’istinto era quello di costruire un modello AI che li identificasse automaticamente.
Invece, Hiver ha sviluppato oggetti regola configurabili. Questi utilizzano logiche esplicite basate su domini, parole chiave e metadati. Il risultato è prevedibile, facile da gestire e configurabile dagli utenti finali senza coinvolgere il team AI di Hiver.
Per esempio, se un’azienda vuole che tutte le email da @enterprise.com o messaggi contenenti la parola “contratto” vadano in una casella prioritaria, può configurare una regola in pochi minuti. Non serve nessuna AI, e non c’è ambiguità su come le email vengono gestite.
Come dice Anurag: “Se puoi scrivere le regole, scrivi le regole. Riserva l’AI per i problemi in cui le regole sarebbero impossibili da elencare, dove hai bisogno che il sistema generalizzi da schemi che non ha visto esplicitamente.”
Valutare i problemi che richiedono davvero inferenza
Quando un problema richiede effettivamente inferenza, Hiver lo valuta rispetto a quattro criteri prima di decidere di procedere:
- Frequenza. L’IA ha veri costi aggiuntivi: costo di inferenza, latenza aggiunta e modalità di errore imprevedibili. Questo costo ha senso solo quando il compito è abbastanza frequente da giustificare l’automazione. Un’attività che si verifica solo alcune volte a settimana raramente giustifica tale complessità. Un’attività che gli operatori svolgono centinaia di volte al giorno, invece sì.
- Prevedibilità. Alcune classificazioni si basano sulle informazioni presenti nell’input (contenuto dell’email, oggetto, metadati) invece che sull’apprendimento dai dati disponibili. Altre dipendono da un contesto che il modello non possiede: livello del cliente, politiche interne di escalation, giudizio dell’agente maturato nel tempo. Prima di impegnarsi nello sviluppo, il team esegue controlli di fattibilità sui dati storici per determinare se la previsione sia possibile con un livello di affidabilità utile. Se il segnale non c’è, nessuna scelta architetturale può cambiarlo.
- Richiesta da parte dei clienti. Si sta risolvendo un problema che i clienti hanno effettivamente segnalato, o uno che il team presume abbiano? Il primo caso ha una probabilità di adozione molto più alta. Il secondo tende a portare a funzionalità ben fatte ma ignorate poi nella realtà.
- Rischio e reversibilità. Cosa succede se il modello sbaglia? Un tag errato che un operatore corregge con un clic ha un profilo di rischio molto diverso da una risposta sbagliata inviata a un cliente, o un’escalation mancata. Le previsioni a basso rischio e facilmente reversibili sono ottime candidate per l’automazione. Le decisioni ad alto rischio necessitano invece di una revisione umana o soglie di affidabilità molto più elevate prima di essere attuate.
La funzione di auto-tagging di Hiver funziona perché soddisfa tutti e quattro i criteri. Usa un modello per assegnare il tag più rilevante a una conversazione in arrivo. Gli operatori non devono più categorizzare manualmente ogni ticket.
I team definiscono un insieme di tag nel pannello di amministrazione, come “Fatturazione” o “Supporto tecnico.” Questi fungono da obiettivi di previsione. Il modello apprende i pattern dal contenuto dell’email, oggetto e metadati. Vengono inclusi solo i tag con segnali chiari.
Gli operatori svolgono questa attività su quasi tutte le conversazioni, il che la rende ad alta frequenza. Il segnale è presente nei contenuti delle email per i tag inclusi, rendendola prevedibile. I clienti di Hiver hanno espressamente richiesto di ridurre il triage manuale, il che favorisce l’adozione. Quando il modello sbaglia, il tag può essere corretto con un clic, mantenendo rischio e reversibilità bassi.
L’analisi del sentiment segue lo stesso schema. Analizza il tono di ogni conversazione per identificare se un cliente è frustrato, neutrale o positivo. I team lo vedono in ogni interazione, quindi è ad alta frequenza. Il tono è presente nel testo, quindi è prevedibile.
I team vogliono una visione precoce dei clienti frustrati, il che genera una domanda chiara. Se il modello sbaglia, gli operatori possono correggere la valutazione senza influire sul risultato, mantenendo così il rischio basso.
Test di Fattibilità Prima dello Sviluppo
Una delle parti più rigorose del processo di Hiver: eseguire test di fattibilità sull’accuratezza prima di scrivere qualunque codice di produzione.
La funzionalità di suggerimento dei tag è un esempio illuminante. Ad esempio, se un’email dice: “Mi è stato addebitato due volte,” il modello dovrebbe scegliere “Fatturazione.” Ma cercava anche di suggerire tag come “Cliente VIP” o “Escalate to Manager,” che non possono essere dedotti dal solo contenuto dell’email. La precisione ne risentiva, e gli operatori hanno smesso di fidarsi dei risultati.
Il problema di fondo era la mancata distinzione tra tag prevedibili e non prevedibili. I tag di categoria come “Fatturazione,” “Supporto tecnico,” e “Resi” corrispondono a schemi linguistici nei contenuti delle email. Sono apprendibili.
I tag operativi come “Cliente VIP,” “In attesa di parere legale,” e “Escalate to Manager” dipendono da un contesto esterno all’input: storico account, regole aziendali interne, coordinamento tra team. Nessun modello addestrato sulle email dei clienti può prevederli in modo affidabile.
La soluzione è stata strutturale: prima che qualsiasi tipo di tag venga considerato come obiettivo di previsione, deve superare un controllo di fattibilità. I dati storici supportano una previsione affidabile di quel risultato? Se no, viene escluso dall’ambito operativo, a prescindere da quanto sarebbe utile l’automazione di quel tag.
“La disciplina di dire ‘questo tipo di tag non è adatto all’automazione’ è stata più difficile che costruire il modello. Ma così abbiamo distribuito solo previsioni di cui gli operatori potessero fidarsi.”
Incorporare l’IA nel flusso di lavoro, non sopra di esso
Dove l’IA si inserisce nel prodotto è importante tanto quanto ciò che fa.
Una funzione che costringe gli utenti a fermarsi, inserire un prompt e controllare l’output prima di agire aggiunge un passaggio al processo, invece di toglierlo. Questo ha un impatto negativo netto anche se l’IA è accurata. Gli utenti che lavorano rapidamente, gestendo ticket in successione, tenderanno a evitare qualsiasi cosa interrompa quel ritmo.
La direzione progettuale efficace: IA che agisce prima che l’utente abbia bisogno di pensarci. Con Hiver:
- Le email vengono etichettate prima che gli operatori le aprano.
- Il sentiment viene calcolato e segnalato prima che un operatore apra la conversazione: un cliente frustrato è già emerso in cima alla coda.
- L’ordinamento della coda riflette le priorità senza che gli operatori debbano configurare nulla.
- Le bozze delle risposte appaiono in linea come suggerimenti.
- I casi in cui la fiducia del modello scende sotto una soglia vengono sottoposti a revisione umana invece di essere gestiti automaticamente.
L’interfaccia non è costruita attorno al chiedere aiuto all’IA. Gli operatori non devono attivarla. Le email vengono etichettate e prioritarizzate prima che le aprano. L’IA elimina il lavoro prima che l’operatore debba pensarci.
La metrica interna per capire se funziona: "Se gli utenti notano l’IA, probabilmente l’hai costruita nel modo sbagliato."
Quando funziona, gli utenti smettono di parlare della funzione IA. Parlano di tempi di risoluzione più rapidi, meno backlog, onboarding più semplice per i nuovi operatori. L’IA è passata dall’essere visibile all’essere strutturale.
| 📌 Istanza Cliente: Come Si Traduce Nella Pratica |
|---|
| 📌 Istanza Cliente: Come Si Traduce Nella PraticaIn ITS Logistics, i team gestivano le conversazioni con i clienti tramite caselle di posta sparse, indirizzando manualmente le richieste e spesso pestandosi i piedi con risposte duplicate o mancati follow-up. Dopo il passaggio a Hiver, tutto è cambiato rapidamente. In sole tre settimane, il tempo medio di emissione dei preventivi è diminuito del 61% e la maggior parte delle richieste in arrivo veniva automaticamente indirizzata alla persona giusta. Ancora più importante, ogni conversazione aveva un responsabile chiaro e i manager avevano finalmente visibilità sui progressi del lavoro. Il risultato è stato un sistema capace di gestire la domanda crescente senza aggiungere complessità o personale, perché il lavoro stesso è diventato più strutturato e prevedibile. “Hiver ha trasformato richieste sparse in un sistema strutturato di assistenza clienti. Ogni richiesta è tracciata, assegnata e risolta più velocemente.” — Alejandro Arboleda, Direttore Operativo, ITS Logistics. |
Accuratezza e Fiducia Sono Problemi Diversi
Un sistema può raggiungere il 95% di accuratezza e fallire comunque in produzione se gli utenti non hanno un modello mentale affidabile di quando potrebbe sbagliare.
La fiducia deriva dalla prevedibilità e dal controllo. Gli utenti devono capire il comportamento del sistema abbastanza bene da sapere quando farci affidamento e quando invece intervenire. Se non riescono a sviluppare quel modello mentale, o smetteranno di usare la funzione o smetteranno di controllarne i risultati, entrambe modalità di fallimento.
L’approccio di Hiver è rendere la correzione una parte integrante del design invece che un ripiego in caso di errore. Gli operatori possono sovrascrivere qualsiasi previsione con un solo clic. Il sistema acquisisce le modifiche come segnali di feedback. Soglie basate sulla fiducia determinano cosa viene applicato automaticamente e cosa invece viene sottoposto a revisione.
Con le parole di Anurag, "Invece di trattare le correzioni come fallimenti, le abbiamo costruite come funzionalità. Così lasciamo il controllo agli operatori e creiamo un ciclo di apprendimento senza mai allenarci sui dati dei clienti. Il sistema migliora osservando gli esiti."
Questo risolve anche una questione di dati. Poiché le correzioni ritornano come segnali di feedback, il modello migliora osservando i risultati invece di richiedere accesso ai dati grezzi dei clienti.
Il confine della privacy rimane intatto mentre il sistema diventa sempre più preciso.
Due Domande Prima di Rilasciare Qualsiasi Funzione di IA
Prima di approvare qualsiasi nuova funzione IA, due domande:
"Se questa funzione fosse rimossa domani, gli utenti si lamenterebbero?"
Se la risposta è no, la funzione è un’aggiunta ma non è essenziale. Non ha ancora cambiato il modo in cui le persone lavorano. Quello è il livello da raggiungere.
"Questa funzione riduce una decisione o ne crea una nuova?"
Se gli utenti devono decidere se fidarsi dell’IA, configurarla o interpretare il suo output prima di agire, l’IA ha aggiunto carico cognitivo invece di ridurlo.
Quello è un fallimento, indipendentemente dalla performance tecnica.
Il Vero Lavoro Dietro le Funzioni di IA
Costruire soluzioni di IA che funzionano davvero in produzione riguarda meno la scelta del modello e più la scelta del problema, i test di fattibilità e la progettazione basata su come lavorano realmente le persone. L’IA in sé è la parte minore del problema.
"Il prodotto non era mai la classificazione, l’analisi del sentiment, le bozze o la sintesi. Il prodotto era: meno decisioni per operatore, risultati più rapidi, carico cognitivo ridotto, operazioni scalabili. L’IA era il meccanismo, e un meccanismo funziona solo se applicato al problema giusto, con dati che supportano realmente la soluzione."
Se stai riflettendo su come l’IA può inserirsi nelle tue operazioni di supporto, parla con noi su Hiver. Ti mostreremo come possiamo aiutarti a offrire un supporto empatico.