In un articolo del mese scorso abbiamo approfondito i casi in cui serve implementare un Chatbot e quali sono i punti di attenzione nella "costruzione" di un bot. Una lezione che abbiamo sicuramente imparato è che non possono essere i clienti stessi a fare il training a un Chatbot già rilasciato e, teoricamente, pronto all'uso.
Per garantire l’efficacia di un chatbot è infatti essenziale che questo riesca ad identificare gli argomenti di cui i clienti hanno necessità di risposta e che sia capace di comprendere le loro esigenze, il tutto senza essere influenzato dalle strutture linguistiche degli interlocutori. Per ottenere questo risultato il chatbot viene sottoposto ad un processo di learning: cliente e sviluppatore identificano gli argomenti e le relative parole chiave, stimando quelle che saranno le richieste degli interlocutori ed il modo in cui saranno poste.
Ma proprio perché sono stime create da un gruppo chiuso, generalmente non sono esaustive e, una volta che il chatbot è pubblico, la fase di learning entra nel vivo. Si scoprono così tutti gli argomenti che non erano stati preventivati, ma che gli utenti ritengono utili e cercano. Inizia quindi un nuovo processo di addestramento: vengono aggiunte nuove parole chiave e relative risposte, tutto mentre il prodotto è live. Accade quindi che il chatbot, nelle prime interazioni, offra un basso livello dell’esperienza utente, elemento che può portare a frustrazione, fastidio e persino abbandono per gli early adopters. Questi utenti solitamente rappresentano i clienti più fedeli, sui quali vi è stato un lungo e costoso lavoro di custom relationship che rischia di venire meno a causa di un prodotto troppo acerbo per essere immesso sul mercato. Un chatbot allenato in modo incompleto rischia di abbattere la retention del cliente, nasce così la necessità di anticipare la fase di learning, di rendere il chatbot effettivamente pronto e competente già al suo rilascio.
Come arrivare sul mercato senza che siano i clienti a fare da trainer? E come riuscire in questo processo nei tempi, senza allungare lo sviluppo?
Da questa necessità nasce la progettualità che UNGUESS ha ideato assieme ad INNAAS, per supportare il processo di sviluppo di un chatbot rendendolo più efficace, rapido e completo prima del suo pubblico rilascio. Si è partiti dal problema (fase di learning a valle, quando il prodotto è sul mercato) per identificare quali fossero i processi di sviluppo che potevano essere rivisti per migliorare in particolar modo la fase di learning di un chatbot. È immediatamente emerso che non vi era un singolo, specifico, aspetto sul quale bisognava lavorare, ma era necessario integrare il crowd-testing in diverse fasi dello sviluppo dall’identificazione degli argomenti alla gestione delle forme lessicali.
Fase 1: identificare gli argomenti
In primo luogo, è apparso evidente che andava potenziata l’attività di identificazione degli argomenti a cui il chatbot avrebbe dovuto rispondere prontamente. Questa fase è solitamente demandata ad analisi di customer care ed esperienza personale dello sviluppatore, che assieme stilano una serie di FAQ in base alle domande che si aspettano di ricevere. Tuttavia, soprattutto per un prodotto nuovo, è difficile che l'ideatore, con una profonda conoscenza dello strumento, riesca a mettersi nell’ottica di un cliente esterno, che si approccia per la prima volta al servizio e necessita quindi di informazioni.
Serviva quindi identificare cosa avrebbero chiesto i clienti e per farlo era fondamentale capire quali sarebbero stati gli utenti di questo chatbot, e quindi del servizio offerto. Il reparto marketing del cliente ha condiviso una stima della distribuzione demografica, del livello culturale e della compatibilità tecnologica dei suoi clienti. UNGUESS, all’interno del suo crowd di circa 100.000 tester, ha identificato un cluster di 25 tester che replicasse il cliente tipo ed ha chiesto loro di interagire con il chatbot, ancora in una fase embrionale. Nello specifico, in questo primo test, al tester veniva detto di immaginare di aver visto la pubblicità di una nuova banca e di voler avere informazioni sui suoi servizi. L’obiettivo era quello di capire cosa l’utente possa voler chiedere alla propria banca.
La banca e lo sviluppatore avevano già provato ad anticipare le richieste a cui il chatbot avrebbe dovuto dare risposta, identificando 187 argomenti, nati dall’esperienza del customer care e del reparto marketing. L’output del test ha in realtà dimostrato quanto questo fosse ancora acerbo e limitato negli argomenti, sono stati infatti identificate ben 132 nuove FAQ a cui si aggiungono 13 processi già identificati, ma per i quali gli utenti chiedevano dettagli non ancora predisposti. In termini percentuali vuol dire +78% di argomenti identificati con il supporto del crowd-testing in tre giorni di test!
Per quanto previsto, non era nelle aspettative un incremento così significativo degli argomenti, elemento che ha comportato un notevole impegno da parte dello sviluppatore e del cliente bancario per integrare le nuove domande e scrivere le risposte, per ognuno dei 132 argomenti. Se questa attività, come era solito accadere, fosse avvenuta a valle del rilascio del chatbot, sarebbe stata di maggiore complessità gestionale, richiedendo continuo supporto ed interazione, con un costo in termini di tempo e risorse decisamente più alto.
Una volta inserite le risposte alle domande individuate dai tester l’obiettivo si è spostato verso la corretta identificazione dell’argomento. Non basta infatti sapere che in molti chiedono informazioni sulle carte di credito. Fondamentale, per una migliore esperienza utente, è identificare correttamente le domande su questo argomento, limitando al minimo la non risposta o l’incomprensione da parte del chatbot.
Fase 2: ampliare il lessico
Identificati quindi gli argomenti e strutturate le domande tipo per ognuno di essi, la seconda fase di allenamento si è concentrata nell’identificare più forme lessicali e costrutti logici per ogni domanda. C’è infatti chi usa un linguaggio più colloquiale (“ciao, come faccio per avere una carta di credito?”), chi più sintetico (“richiesta carta di credito”) o chi più prolisso (“se apro il conto con voi in quanti mesi posso avere una carta di credito non ricaricabile?”). È evidente quanto flessibile deve quindi essere il chatbot nel gestire linguaggi diversi, ma anche efficace nell’identificare il macro-argomento: in questo esempio, il processo di attivazione di una carta di credito.
UNGUESS ha quindi preso il set di domande pre-definite ed ha chiesto al proprio crowd, già precedentemente identificato così da essere affine al cliente della banca, di riscriverle, ogni tester con il proprio stile. In questa fase era necessario raggiungere un’alta numerosità così da coprire il maggior numero possibile di stili, forme lessicali ed uso di sinonimi. In questa seconda fase, in meno di una settimana, 50 tester hanno stressato il chatbot arrivando a definire più di 8.000 diverse interazioni, di cui ben 5.000 sono state successivamente validate ed integrate nel learning del chatbot.
Questo ha permesso di costruire un ramo informativo di, mediamente, 25 diverse strutture logiche afferenti ad ogni singolo argomento, permettendo al chatbot di confrontare la domanda ricevuta con una di queste strutture per identificare correttamene la richiesta e selezionare la corrispondente risposta.
Appare evidente come non sarà possibile porre la parola “fine” alla fase di learning di un chatbot, è un continuo bilanciamento tra l’obiettivo di soddisfare le domande più probabili e la necessità di gestire le specificità che possono emergere. Il chatbot deve quindi essere limitato per essere efficace, il supporto del crowd permette da un lato di spostare questi limiti, dall’altro di garantire, a pari dimensione di competenza, una maggiore capacità di risposta.
Utilizzando il crowdtesting nella fase pre-rilascio il cliente è riuscito a:
- identificare con maggiore completezza e ragionevole precisione la quasi totalità delle domande a cui il chatbot deve essere preparato a rispondere;
- rendere più indipendente la comprensione della domanda dalla sua struttura, dalla forma lessicale e dall’uso di sinonimi propri di ogni persona.
Come si allena, quindi, un chatbot?
Integrazione, collaborazione e crowd. La flessibilità della struttura di gestione della propria community ha permesso ad AppQuality di gestire una progettualità specifica, a primo impatto lontana dal concetto classico di testing, ma in realtà molto vicina all’obiettivo di ogni test: rilasciare sul mercato un prodotto di qualità. L’accesso ad una base di tester numerosa ha permesso di identificare un cluster completamente sovrapponibile al cliente tipo della banca e di attivarne grande numerosità in poco tempo, così da condividere con lo sviluppatore output di valore in pochi giorni.
Si può fare User Experience Analysis di un Chatbot?
Sì. È una declinazione della UX o User Experience classica, che non è focalizzata sull’interfaccia grafica ma su quella testuale, dove l’esperienza è data principalmente dal contenuto e non dal contenitore. Questo in generale, ma vi sono dei chatbot con interfaccia grafica di supporto al cliente, interfaccia nata per velocizzare l’interazione, come ad esempio quello di Milan Airports.
Nel caso del chatbot bancario, questo era capace di fornire anche altre informazioni, ad esempio quelle sul meteo. Le valutazioni emerse dai nostri test hanno evidenziato diversi problemi di design di questa feature che forniva un risultato visivo, sintetico, con indicazione di temperatura ed umidità. L’esperienza di questa feature è stata criticata in quanto l’immagine usata era molto semplice e non in linea con lo stile complessivo, l’icona non rendeva chiaro se quello che si vedeva era il meteo attuale o quello previsionale; inoltre l’indicazione dell’umidità era poco utile, in molti avrebbero preferito avere indicazione della probabilità di pioggia.
Cosa abbiamo imparato?
Il crowd testing può essere usato anche come strumento di allenamento di un chatbot, ma per rendere efficace il suo utilizzo va integrato nel processo di sviluppo e vanno identificati con precisione gli obiettivi per ogni stadio di avanzamento, oltre ad analizzare in profondità i feedback condivisi dai tester. Testare un chatbot a fine sviluppo è sì fattibile, ma poco proficuo perché comporterebbe un notevole re-work ed un’integrazione di informazioni e strutture logiche, a quel punto, date per definitive.
L’integrazione del crowd, oltre che migliorare la qualità finale, riduce anche i tempi di release: lo sviluppo infatti si concentra sulla parte tecnica senza dedicarsi alla gestione delle informazioni, che vengono invece demandate al crowd che fornisce l’output su cui lavorare. Raggiungere 8.000 iterazioni in 3 giorni non è effettivamente fattibile per nessuna struttura aziendale che volesse svolgere, al suo interno, un’attività analoga. Ma anche ipotizzando di voler provare a farlo dovrebbe creare una struttura di supporto per memorizzare e razionalizzare tali informazioni e dovrebbe mettere in atto un'opportuna politica di gestione dei singoli utenti. Il vantaggio di rivolgersi ad UNGUESS risiede proprio nella possibilità di esternalizzare un processo complesso, time consuming ed estremamente oneroso in termini di gestione delle informazioni; ottenendo un output chiaro, organizzato e strutturato per essere inserito efficacemente nei processi aziendali.