Tre mesi di disastri e quello che è venuto dopo: la storia operativa di Audin.AI.

Il problema, prima di pensare alla soluzione

Nel customer care di uno dei nostri e-commerce nel settore hair care, ogni operatore passava in media il sessanta per cento del proprio tempo a rispondere a tre tipi di richiesta: stato dell'ordine, domande sui prodotti, modifiche all'abbonamento. Il problema non era il volume in sé — i numeri tenevano. Il problema era cosa quel volume ci impediva di fare.

Il team commerciale, sulla carta, doveva chiamare i clienti per il cross-sell e il recupero del carrello. Sulla carta. Nella pratica, finiva sempre per rispondere all'ennesima richiesta di tracking di una spedizione. Le chiamate commerciali venivano fatte negli ultimi venti minuti della giornata, quando ormai chi rispondeva al telefono era già stanco di parlare. I numeri di vendita telefonica erano fermi da mesi.

Avremmo potuto assumere altre persone. Lo abbiamo escluso quasi subito. Aumentare il personale per gestire più richieste ripetitive avrebbe peggiorato il problema strutturale, non risolto: rispondere di più non significa rispondere meglio, e il vero collo di bottiglia non era la quantità di risposte, ma il fatto che le persone giuste stavano facendo il lavoro sbagliato.

Perché abbiamo scelto l'AI vocale (e non chat o email)

La scelta del canale vocale, contro ogni ragionevolezza, è stata la prima decisione coraggiosa. Tutti i nostri fornitori ci avevano consigliato di partire da una chat AI sul sito: più semplice da implementare, meno rischiosa, meno costosa.

Il problema è che la maggior parte delle richieste ripetitive non arrivava da web. Arrivava dal telefono. I nostri clienti, soprattutto la fascia 45-60, preferivano chiamare. E un agente di chat sul sito non avrebbe alleggerito niente del lavoro reale del customer care.

Così abbiamo deciso di prendere il problema al pezzo più difficile per primo: agente vocale, con riconoscimento dell'intent, in italiano, 24 ore su 24, integrato con il gestionale degli ordini e con il sistema di abbonamenti.

I primi tre mesi: un disastro continuo

Il primo giorno in cui abbiamo messo l'agente in produzione, dopo undici settimane di sviluppo e test interni, abbiamo ricevuto trentasette segnalazioni di malfunzionamento nelle prime sei ore. Il numero non scende a un livello accettabile per circa novanta giorni.

Ecco una lista parziale di quello che è andato storto, da chi era in trincea ogni giorno:

• Allucinazioni sui numeri d'ordine. L'agente leggeva i codici fiscali al posto dei codici ordine. Si inventava date di consegna. Confermava al cliente che il pacco sarebbe arrivato martedì quando il sistema diceva venerdì.
• Escalation continue. Ogni volta che l'agente non capiva qualcosa, scalava all'operatore umano. Nelle prime settimane, scalava il 70% delle chiamate. Il personale era sommerso più di prima, perché adesso doveva anche capire cosa l'agente aveva già detto.
• La voce metallica. Il modello vocale che avevamo scelto era tecnicamente buono ma timbricamente inquietante. I manager dell'azienda lo facevano notare in continuazione nelle riunioni. Quasi tutte le obiezioni interne riguardavano il timbro della voce. I clienti, sul campo, non se ne lamentavano quasi mai.
• Risposte fuori contesto. A volte l'agente partiva con un saluto cordiale e poi rispondeva a una domanda che il cliente non aveva fatto. Era come parlare con qualcuno che ha sentito un'altra conversazione.

Il punto in cui abbiamo capito (e non era quello che pensavamo)

A novanta giorni dal go-live, c'è stata una riunione interna in cui qualcuno ha proposto di staccare la spina. Era la posizione ragionevole: il sistema non funzionava, costava ore di lavoro al team di sviluppo, e la qualità percepita era inferiore al precedente customer care interamente umano.

Abbiamo deciso di non spegnerlo. Per una ragione precisa, che merita di essere raccontata: quando guardavamo le metriche del manager, il sistema era un fallimento; quando guardavamo le metriche del cliente, no.

Le valutazioni di soddisfazione del cliente, raccolte alla fine di ogni chiamata, erano scese di un punto e mezzo su dieci nei primi trenta giorni, ma erano già risalite di un punto nei sessanta successivi. Le chiamate che l'agente gestiva interamente, senza escalation, ricevevano valutazioni medie quasi identiche a quelle gestite dall'operatore umano. Il vero problema delle valutazioni basse era il pasticcio dell'escalation a metà chiamata, non l'agente in sé.

Il manager guardava la voce metallica. Noi guardavamo i KPI. È la differenza tra valutare un sistema dal punto di vista di chi lo guarda da fuori e da chi lo usa davvero.

La decisione operativa è stata: continuare, ma cambiare due cose. Riscrivere il blocco di routing dell'escalation per fare in modo che, una volta partita la conversazione con l'agente, l'operatore umano subentrasse silenziosamente senza riassumere quello che era stato detto (era proprio il riassunto, fatto male, a fare la peggior figura). E migliorare il riconoscimento dell'intent sui tre tipi di richiesta più comuni, anche a costo di peggiorare quello sugli altri.

I numeri di oggi

Dodici mesi dopo il go-live, questi sono i dati medi degli ultimi tre trimestri:

Il customer care umano ha smesso di essere il collo di bottiglia. Le chiamate che arrivano agli operatori sono mediamente più complesse — perché le semplici le risolve l'agente — e questo ha permesso al team di concentrare la giornata sul cross-sell e sul recupero dei carrelli abbandonati, che è il lavoro per cui erano stati assunti in origine. Il +22% sulle vendite telefoniche per operatore è quasi interamente lì.

Cosa è successo dopo: il salto a Audin.AI

Una volta che il sistema funzionava in produzione su un'azienda del gruppo, ci siamo accorti che la stessa architettura risolveva problemi molto simili in altri due settori. In Farmakom, il nostro SaaS per le farmacie, la gestione delle richieste dei farmacisti era saturando il customer success. In MeetingHub, il sistema di booking di sale eventi, la qualifica delle richieste in ingresso era lenta e veniva fatta a mano.

Lo abbiamo replicato. Funzionava — con qualche tuning specifico. A quel punto era diventato qualcosa di diverso da un progetto interno: era un prodotto. Lo abbiamo chiamato Audin.AI, e oggi è in produzione anche su grandi imprese esterne al gruppo.

La cosa importante da capire è il percorso, non il prodotto: è nato risolvendo un problema concreto su una sola azienda, è stato debuggato in tre mesi di disastri sui nostri soldi, è stato validato a regime sui nostri numeri, e solo dopo è uscito fuori. Nessun cliente esterno ha mai pagato un solo euro per i tre mesi di disastri iniziali — perché quei tre mesi li abbiamo pagati noi.

Cosa portarsi a casa, se stai valutando AI nei processi

Tre cose ci hanno permesso di non spegnere il sistema quando era ragionevole farlo:

1. Distinguere chi giudica da chi usa. Le metriche del manager e quelle del cliente non sono la stessa cosa. Il manager guarda la voce metallica; il cliente guarda se il problema è stato risolto. Quasi sempre, è quello del cliente il dato che decide se andare avanti.
2. Saper rinunciare alla copertura completa. Coprire bene tre intent comuni vale più che coprire male venti intent. Abbiamo perso nei test su casi rari per guadagnare nella produzione sui casi più frequenti.
3. Non valutare un sistema nuovo con i KPI di un sistema vecchio. Misuravamo le chiamate gestite dall'agente come fossero chiamate gestite da un operatore umano: numero di risoluzioni al primo contatto, tempo medio, escalation. Le metriche giuste sono diverse, e parte del lavoro è stato capirle.

Se stai valutando di mettere AI in un processo della tua azienda, l'errore più comune che vediamo è partire chiedendo a un fornitore quale soluzione vendere. È esattamente l'unico modo per essere certi di sbagliare. Il fornitore ha una sola domanda in testa: come faccio a essere scelto. Tu ne hai dieci, e la prima è capire se quello che stai facendo è davvero un problema vero, o solo un'aspirazione manageriale.