Solution definition

Durante questa fase sono stati raccolti in un apposito documento i requisiti funzionali di base che devono essere presenti sull’applicativo. Questa fase non solo recepisce le richieste derivanti dall’azienda Cliente, ma definisce anche una soluzione da mostrare come prototipo durante la visita presso il primo Call Center.

Inoltre per ciascuno di questi centri di gestione della chiamata sono stati individuati degli Use Case di riferimento in modo tale da ottenere la mappatura delle attività, e avere un confronto concreto tra la situazione as-is e quella to-be. Queste casistiche dovrebbero rappresentare situazioni reali che si trovano a gestire i Rep (Call Center Representative) durante il momento di interazione con Cliente.

La decisione su quali Use Case adoperare ha visto la scelta tra due diverse modalità di mappatura:

1) Utilizzare i Motivi di Chiamata: si tratta di insiemi, aggregati per tipologia, dei Motivi di Contatto, ovvero dei riferimenti attraverso cui tracciare la chiamata e l’attività dell’operatore. Al termine di ogni chiamata infatti l’end-user deve riportare le motivazioni della chiamata da parte del Cliente, andando a selezionare 3 diversi stati predefiniti, che identificano in maniera univoca il contatto avvenuto tra Cliente e Call Center. Ad oggi i Motivi di Chiamata sono 12 e clusterizzano al loro interno 96 diversi Motivi di Contatto

2) Utilizzare le procedure seguite dagli operatori, durante la gestione della chiamata: gli end-user infatti utilizzano un catalogo dell’azienda Cliente, sul quale sono presenti 146 procedure da seguire a seconda del problema della chiamata. Per ognuna di queste sono riportati diversi step, con domande specifiche a risposta chiusa, da sottoporre al Cliente. Tali procedure hanno una struttura ad albero, percorribile in una sola direzione, in cui ad ogni nodo corrisponde una domanda. Queste procedure servono per far sì che l’operatore segua un percorso ben preciso nella gestione della chiamata e non prenda liberamente decisioni su possibili soluzioni da proporre al Cliente.

81

Dopo un’attenta analisi dei due approcci la scelta è ricaduta sulla seconda modalità, poiché nonostante la possibilità di utilizzare tutti e 12 i Motivi di Chiamata questi non sarebbero stati facilmente confrontabili con le azioni svolte dagli operatori nello stato as-is dei sistemi.

Utilizzando il secondo caso si è riusciti a mappare con 97 procedure, ovvero il 70% del totale, tutte le azioni svolte sui sistemi odierni. Il 30% trascurato infatti è stato coperto ugualmente in termini di funzionalità utilizzate sui sistemi, non comportando quindi alcuna perdita informativa.

In conclusione quindi sono stati individuati 97 UC, ripartiti sui 4 diversi CC, come dettagliato in Tabella 4.3:

Call Center

N°

Use

Case

Esempio

Pisa 23 Non mi torna il credito

Bologna 19 Gestione contestazioni roaming

Catania 19 Problemi amministrativi

Ivrea 35 Fattura ADSL/Fibra

Tabella 4.3: Use Case individuati

Questi Use Case, divisi per CC, sono stati a loro volta clusterizzati per macro aree di appartenenza ed è stata individuata per ciascuno la frequenza di accadimento. Questa si distingue in alta, media o bassa in base al numero di chiamate ricevute per quella problematica.

Sulla base di queste casistiche, è stato predisposto un documento per raccogliere in una fase successiva le informazioni utili a mappare i sistemi presenti e capire in che

82

modo gli Operatori lavorano. Inoltre sono stati individuati i KPI da rilevare durante le visite on-site per confrontare la situazione as-is con quella to-be all’interno dei CC. L’obiettivo di questi KPI è quello di dimostrare l’efficienza della nuova soluzione rispetto alla precedente in termini di velocità di gestione della chiamata e di user experience dell’operatore.

In particolare per ciascun UC il documento deve riportare le seguenti informazioni:

 Customer need: si tratta del bisogno manifestato dal cliente, che lo spinge a

contattare il Contact Center

 Attività del Rep: sono le attività che l’operatore svolge sui sistemi as-is mentre è

in cuffia con il cliente

 Info/Dati necessari: informazioni indispensabili per svolgere ciascuna attività

individuata al punto precedente

 Sistemi sorgente dati: per ciascuna attività il Rep deve solitamente accedere ad

un sistema diverso. In questa sezione sono segnati i nomi degli applicativi utilizzati durante tutti gli step di gestione della chiamata

 KPI:

o Numero di click: click del mouse effettuati dall’operatore per svolgere un’attività di verifica informativa o di azione dispositiva all’interno di uno specifico Use Case. Nella situazione as-is avendo le informazioni sparse devono essere utilizzati più click, rispetto al to-be, dove le informazioni sono tutte concentrate su di un unico applicativo.

o Numero di schermate: finestre aperte sullo schermo del computer dell’operatore durante ciascuna attività. In questo caso dovrebbe essere mostrata la netta differenza tra la situazione as-is in cui si hanno più sistemi aperti, ognuno riportante le informazioni su più finestre, e la situazione to-be in cui si ha un’unica landing page, dove al massimo vengono massimizzati dei widget.

o AHT (Average Handling Time): tempo medio di gestione di una chiamata riferita ad uno specifico Use Case. Ovvero tempo che l’end

83

user adopera per effettuare tutte le attività in modo tale da fornire una soluzione al Cliente. Questo dovrebbe riportare un notevole miglioramento grazie alla minore dispersione delle informazioni e la facilità di ricerca da parte dell’end-user nella situazione to-be.

Questi KPI sono stati utilizzati in un momento successivo alla loro raccolta per confrontare la soluzione as-is con quella to-be. Grazie all’utilizzo del prototipo è stato possibile infatti fare un paragone tra i sistemi vecchi e quello nuovo, in modo da mostrare concretamente i vantaggi ottenibili nel secondo caso.

 Pain Points: maggiori svantaggi dovuti dallo svolgere l’attività nello stato as-is.

Si tratta delle problematiche e difficoltà riscontrate durante l’utilizzo dei sistemi presenti oggi

Questo documento di raccolta, così formato, è stato utilizzato come guida per rapportarsi con gli end-user. Questo ha permesso successivamente di focalizzarsi sulle azoni realmente svolte sui sistemi, senza rischiare di tralasciare aspetti fondamentali durante le visite ai CC. Se ne mostrano dei frammenti in Figura 4.5:

84

4.2.3 Struttura del processo di raccolta dei requisiti, design degli use-case e