Nuove interfacce per il canale telefonico di un contact center

Sergio Caserta - Vanguard

Sergio Caserta – Vanguard

L’ottimizzazione del trattamento delle chiamate prima della risposta di un operatore è sempre stato nei pensieri del call center manager, sia per ridurre i costi che per migliorare la qualità del servizio e l’esperienza del cliente. Nei primi call center di fatto, nati con la diffusione presso il grande pubblico del telefono, non era possibile reindirizzare automaticamente una chiamata e l’unica possibilità era quella di assegnare numeri diversi a servizi diversi.Si potrebbe fissare la data di svolta verso il call center moderno agli inizi degli anni ’60, contestualmente al lancio commerciale da parte della Bell della segnalazione in banda, cioè nella gamma di frequenze che vanno da 300 Hz a 3400 Hz, attraverso la tecnologia DTMF (Dual Tone Multi Frequency)  in sostituzione del disco combinatore. Col DTMF vennero i telefoni a tastiera in cui digitando per comporre un numero venivano prodotti toni udibili dal chiamante e che consentivano di “comandare” la selezione telefonica delle centrali, che si avviavano ad essere elettroniche.

Alle origini dei call center
Già verso la fine degli anni ’60 c’erano sistemi PBX con le funzionalità di ACD, ma per gran parte degli anni ‘70 coloro che chiamavano un call center potevano ascoltare semplici messaggi per gestire l’attesa, eventualmente modificati per gestire situazioni particolari quali un’attesa eccessivamente lunga, e le modifiche di questi messaggi comportavano costi elevati perché i sistemi sottostanti erano complessi per l’epoca. Il chiamante era passivo e non poteva far altro che attendere o agganciare. Con la tecnologia del DTMF lo scenario poteva essere cambiato se la soluzione fosse stata cost effective.
Il passo successivo alla riproduzione di messaggi durante l’attesa in coda, concepibile con lo sviluppo dell’elettronica e la diffusione del computer che consentivano di memorizzare tanti messaggi complessi a costi più contenuti, fu quello di sviluppare soluzioni che mettessero in grado al chiamante di usare la tastiera del telefono per comandare con i toni un’applicazione vocale che rendesse interattiva l’attesa recitando messaggi di informazioni e consentendo al chiamante di scegliere tra una serie di opzioni anche a cascata. Questa tecnologia venne chiamata sistema di risposta vocale interattiva (IVR system) con interfaccia DTMF (toni multifrequenza). In questo modo venne anche sostenuto il principio del single point of contact: un unico numero di accesso al customer care per ogni macro-tipologia di cliente. Quindi sebbene un IVR fosse tecnologicamente possibile già durante gli anni ‘60, solo alla fine degli anni ‘70 con l’abbattimento dei costi fu possibile implementare un sistema commerciale di IVR per le aziende che facilitasse il routing delle chiamate (evitando trasferimenti successivi ad opera degli operatori con risparmio del loro tempo e quindi di FTE, o di obbligare il chiamante ad agganciare e chiamare un altro numero), accedesse a mailbox di informazioni, acquisisse messaggi del chiamante, ecc.
Per precisione, nacquero due applicazioni principali sulla medesima tecnologia del voice processing: i sistemi di voice mail (di messaggistica o di messaggeria vocale) per le comunicazioni in differita da persona a persona attraverso mailbox e i sistemi di risposta vocale interattiva che trovarono un largo impiego nei call center per la capacità di gestire tante situazioni diverse.
Naturalmente anche i sistemi di voice mail vennero usati nei call center, ma solo in strutture di customer service piuttosto piccole perché la applicazione di voice mail arrivava confezionata col PBX aziendale e si potevano fare poche modifiche, come cambiare i messaggi di accoglienza, le regole di call coverage (se l’interno è occupato, fare l’azione X; se non risponde, fare l’azione Y), gestire situazioni di distribuzione di informazioni attraverso lettura di mailbox con messaggi preregistrati e consentire un routing piuttosto semplice.
L’IVR ha avuto successo nei call center perché è stato usato anche per consentire al chiamante l’accesso a informazioni presenti nel sistema informativo aziendale, quindi l’ascolto di informazioni dinamiche e legate, ad esempio, al conto corrente, carta di credito, polizza, contratto.

L’avvento degli IVR
La possibilità di personalizzare l’IVR ha comportato l’esigenza di dover realizzare applicazioni di risposta vocale interattiva usabili e gradite dal chiamante. Raggiungere questo traguardo non è stato e non è ancora affatto facile: anche nei paesi anglosassoni, non solo in Italia, ci sono state innumerevoli lamentele e critiche feroci dei consumatori contro l’uso pervasivo dei sistemi vocali nei call center e fuori.
Sono stati formulati allora dei principi di pratiche ottimali di progettazione di applicazioni di risposta vocale interattiva. Ecco il decalogo della Vanguard concepito durante gli anni ’80:
1. Conosci i clienti che ti chiamano e progetta le applicazioni tenendoli presenti rendendo l’uso del sistema il più facile e naturale possibile
2. Per il successo dell’applicazione sviluppata, fa in modo che chi chiama senta di avere il controllo della stessa; ciò determina il successo dell’applicazione
3. Cura l’interfaccia e rendila omogenea lungo tutta l’applicazione
4. Fornisci sia modi per uscire dal sistema che per accedere a particolari nodi del sistema
5. Poiché parliamo in modo diverso da come scriviamo, i copioni da recitare non devono essere testi da leggere ma da ascoltare. Ciò incoraggia il chiamante a usare l’applicazione.
6. Non annoiare i chiamanti con messaggi lunghi e complessi
7. Personalizza l’esperienza del chiamante; usa pertanto una tecnologia che lo consenta
8. Sfrutta tutte le capability dell’IVR per rendere l’applicazione facile da usare e robusta
9. Comunica con i chiamanti e coinvolgili
10. Esegui un monitoraggio delle prestazioni del sistema a cadenza regolare.
Per ognuno dei suddetti punti sono dati suggerimenti pratici e criteri di qualità.

Le voci sintetizzate
Con l’IVR a toni (DTMF) nacque l’esigenza di sintetizzare vocalmente le informazioni presenti nel DB gestionale, quali date, importi, anagrafiche, o comunque situazioni dinamiche per cui non è possibile l’uso di messaggi registrati e digitalizzati.
Per dare alcune informazioni si seguì la tecnica di concatenare segmenti di parole digitalizzate cercando di fare rassomigliare alla voce umana il messaggio concatenato. Rimaneva l’esigenza di gestire facilmente vocabolari molto vasti e quindi si sviluppò la c.d. sintesi da testo (text-to-speech), tecnologia che è evoluta grandemente nel corso degli anni e che oggi ha raggiunto livelli molto avanzati di qualità diventando un’alternativa all’uso della voce di doppiatori in situazioni semplici. I doppiatori sono raccomandabili in circostanze caratterizzate da esigenza di una qualità molto elevata della voce e dal dover usare un tono particolare nel contatto col cliente.
Quindi la digitalizzazione della voce dà una resa assolutamente migliore della sintesi on line di un testo, e per superare questo problema oggi sono disponibili soluzioni, basate su una generazione di prompt da un testo scritto con digitalizzazione dell’audio. I messaggi registrati o generati da testo possono essere combinati con musiche di sottofondo per aumentare la tolleranza all’attesa.

Speech and Speaker recognition
Negli anni ’90 si svilupparono le tecnologie dello speech recognition per consentire al chiamante di interagire con le applicazioni predisposte. Agli inizi l’obiettivo era molto limitato: si voleva aprire l’applicazione IVR ai telefoni a impulsi ancora utilizzati in tante zone rurali o non collegati a centrali moderne. Poi si passò ad arricchire il vocabolario e verso la metà degli anni ’90 c’era già questa classificazione della tecnologia del riconoscimento del parlato che spaziava dal controllo remoto di apparati elettronici fino al call center:

• riconoscimento di parole isolate e frasi attraverso l’addestramento del sistema alla voce del parlatore
• riconoscimento indipendente dal parlatore di parole tra loro connesse, come i numeri di una carta di credito
• riconoscimento del parlato continuo, sia indipendente che dipendente dal parlatore.

Lo sforzo della ricerca applicata è stato quello di facilitare sempre di più il riconoscimento del parlato per consentire di automatizzare l’acquisizione di codici con lettere (in Italia una complicazione ulteriore venne dal fatto che il codice fiscale è piuttosto lungo e alfanumerico), di tante parole utilizzabili nei diversi contesti per rendere possibile il disegno di interfacce molto fluenti. Quindi si è passati da un riconoscimento del parlato continuo al riconoscimento del parlato naturale.
Parallelamente c’è stato l’affermarsi dello speaker recognition: la verifica attraverso la voce dell’identità del chiamante che si è identificato attraverso un codice, per completare e rendere ancora più sicuro il processo di identificazione dell’interlocutore attraverso il telefono.
Oggi lo speech recognition indipendente dal parlatore è una realtà consolidata ma resta da curare lo sviluppo di applicazioni robuste e usabili se si vuole ottimizzare la prestazione del sistema IVR: nei grandi call center un miglioramento del 5-10% dell’efficacia di contenimento dell’IVR significa realmente tanto.
È importante tener presente che il riconoscimento del parlato è un’applicazione fortemente centrata sul dominio applicativo: ad esempio le applicazioni di centralino automatico funzionano molto bene perché ben curate, una compilazione di un modulo può funzionare bene. Inoltre, un’applicazione di riconoscimento del parlato si affianca all’uso dei toni, perché per alcuni task (digitazione di codici numerici) conviene usare i toni.

Le nuove esigenze
Purtroppo i progressi sul versante delle tecnologie del trattamento della voce sono stati in parte resi vani da cambiamenti nelle abitudini del pubblico. La diffusione di telefoni mobili ha aumentato il rumore di fondo, la qualità della voce è più bassa e l’uso della tastiera è facile solo se la persona usa un auricolare. Ciò ha portato però anche alla diffusione di interfacce di riconoscimento del parlato sul dispositivo stesso (ad es. SIRI della Nuance per Apple e Android) e anche alla proposta del cosiddetto Video/visual IVR in cui un cliente chiama un call center e alla risposta gli si visualizza sul proprio cellulare una sequenza di videate con cui può interagire attraverso la voce o con i toni della tastiera telefonica (il visual IVR non va confuso con le apps che richiedono non una telefonata ma un accesso via Internet; si intuisce subito come l’interfaccia utente sia più agevole).
Può essere interessante richiamare alcune peculiarità di una buona applicazione di riconoscimento del parlato naturale indipendente dal parlatore:
• si definisce e si circoscrive l’ambito dell’applicazione
• l’applicazione si decompone in tanti passi
• in ogni task/step ci sono specifiche situazioni da superare per considerare superato il passo stesso:
– lo schema logico di una interfaccia per il linguaggio naturale prevede che nella espressione del chiamante ci possa essere tutto quanto serve per completare il task e raggiungere un punto fermo nel call flow
– nella realtà l’input del chiamante conterrà solo una parte dei dati richiesti e sono necessarie più interazioni con l’applicazione per arrivare al traguardo.
I tipi di output provenienti dal sistema sono categorizzati in genere in: prompt, feedback, istruzioni, aiuto, dati propri dell’applicazione.
Come si intuisce, sviluppare un’applicazione di successo non è affatto facile e vanno anche previste due attività costose, quali la prevenzione e il recovery dagli errori fin dalla fase di design e i test di usabilità. La prevenzione e il recovery dell’errore si traducono in altro sw sviluppato nell’applicazione per gestire situazioni particolari e possibili.
I test di usabilità sono fatti in laboratorio secondo tecniche dell’interaction design, ma devono essere specifici per i sistemi vocali.

Qualche raccomandazione
Visto questo scenario piuttosto complesso la raccomandazione da dare a un’azienda desiderosa di muovere dal DTMF all’uso del parlato è di coinvolgere il fornitore nel successo del progetto:
1. chiedere un proof of concept sulla transazione cliente-operatore del call center bersaglio di automazione attraverso il riconoscimento del parlato
2. vedere il risultato
3. se soddisfacente, registrare centinaia di chiamate della transazione da automatizzare (un campione molto rappresentativo del comportamento del chiamante), darle allo sviluppatore per sviluppare un’applicazione robusta
4. acquisire solo un insieme veramente limitato di licenze del sistema
5. vedere i risultati sul campo e apportare migliorie, se richieste
6. espandere il sistema, se si conferma il ROI
7. Successivamente al lancio dell’applicazione va previsto un sistema di monitoraggio e tuning dell’applicazione stessa

COMMENTI

WORDPRESS: 1
  • commento Avatar

    […] Continua a leggere l’articolo di Sergio Caserta […]