Descrizione Funzionalità

CT7 offre la possibilità di accodare i contatti inbound (sia voce che chat) ad un operatore preferenziale, allo scopo di fidelizzare un utente al suo operatore. La funzionalità permette di avere una gestione completa, potendo configurare anche il tempo massimo di attesa dell’operatore, quanti contatti al massimo accodare al superamento delle soglie preconfigurate, il trasferimento ad una coda presidiata da più operatori.

Funzionamento

Tramite IVR, impostando una variabile denominata _AgentID_ , è possibile indicare all’ACD qual è l’operatore preferenziale da utilizzare per il routing. Tale variabile deve contenere l’id dell’operatore comprensivo di dominio di appartenenza.

La presenza di questa variabile abilita la modalità “Accodamento ad operatore preferenziale”.

_AgentID_ non è propriamente una variabile di CallData, sebbene venga settata nello stesso modo di una variabile normale, ma una pseudo variabile, in quanto non viene riportata tra le variabili visibili all’operatore.

Quando viene effettuato il trasferimento a servizio di accodamento, che comprende tra gli altri parametri anche lo script di accodamento da utilizzare, il contatto verrà accodato su una coda “virtuale” personale.

Eventi

Utilizzando lo script di accodamento è possibile configurare il comportamento desiderato in base ai seguenti eventi:

Se l’operatore non è presente (o logged out), viene eseguito l’evento noagents
Se l'operatore loggato, la chiamata viene accodata internamente all’ACD nella coda dei job suspended presente nella risorsa stessa dell’operatore, quindi trattata e visibile a livello di segnalazione X2X in quanto tale. L’operatore quindi viene notificato quando è presente un contatto in attesa per lui.
Se l’operatore non è disponibile ma loggato, viene scatenato l’evento di queued.
L’evento di fullqueue viene scatenato in caso di raggiungimento della massima profondità di coda. Tale limite può essere impostato sulla risorsa operatore oppure genericamente sulla configurazione dell'ACD utilizzando il parametro generico “agentIDQueueLimit”. Non viene utilizzato il parametro specificato a livello di coda.
L’evento di timeout si scatena al raggiungimento del timeout massimo di attesa configurato sullo script (l’opzione “accoda come definito su coda” non viene valutata). Se il timeout di attesa in coda è abilitato, il corrispondente evento di timeout DEVE essere gestito
Se/quando l’operatore diventa disponibile, viene effettuata la divert della chiamata verso l’interno dell’operatore
Se l’operatore si slogga durante la fase di accodamento (NON se si è già durante la fase di divert), viene eseguito l’evento di noagents

L’evento di noagents deve essere gestito, non è implementata la possibilità di accodare se l’operatore non è loggato

Se la divert verso l’operatore fallisce, la chiamata viene rimessa sul route point. In questo caso, se l’eventuale timeout di massima attesa in coda è già scaduto, viene eseguito il corrispondente evento di timeout, altrimenti la chiamata viene gestita esattamente come nei punti sopra.

Configurazione

Esempio di configurazione su IVR tramite CTManager

IVR: Impostare su un servizio IVR la variabile _AgentID_ valorizzata con l’id dell’operatore, comprensivo di dominio, a cui si vuole fidelizzare il contatto (es: mrossi@acd.enghouse.com).
Script di accodamento: Effettare un trasferimento a servizio di accodamento indicando lo script di accodamento da utilizzare. Lo script gestisce l’accodamento e la distribuzione dei contatti, in quanto tale DEVE essere indicato un identificativo di coda perché altrimenti l’ACD non accetterebbe di utilizzare quello script, l’identificativo di coda serve unicamente a questo scopo.
Profondità di coda: questo è configurabile sull’operatore con fallback sull’ACD stesso, potendolo così configurare immediatamente per tutti gli operatori in maniera identica, mediante il parametro generico “agentIDQueueLimit”; normalmente è possibile farlo solo a a livello di coda quindi questo nuovo parametro è necessario in quanto la chiamata non è stata assegnata ad una coda. Viene generato l’evento di “fullqueue” quando è stato raggiunto tale parametro.
Timeout di attesa in coda: per l’eventuale timeout massimo di attesa, al termine del quale viene eseguito l’evento di timeout, vale la configurazione indicata dallo script eccetto “accoda come definito su coda” in quanto la chiamata non è stata assegnata ad una coda; NOTA: se il timeout di attesa in coda è abilitato, il corrispondente evento di timeout DEVE essere gestito

Esempi di utilizzo

Supponiamo di avere il gruppo di lavoro (coda) chiamato “HelpDesk”), con il suo normale script di accodamento per gestire gli eventi (messaggi di attesa, eventuali timeout / overflow etc.)

se la variabile call data “_AgentID_” nell’IVR NON è’ valorizzata, un contatto telefonico / chat che l’IVR trasferisce tramite il nodo di accodamento allo script associato alla coda “HelpDesk” viene accodato normalmente alla coda HelpDesk, con trasferimento al primo operatore libero
se la variabile call data “_AgentID_” nell’IVR è invece correttamente valorizzata con un iduser di un operatore del callcenter, l’IVR trasferisce la chiamata allo stesso servizio di accodamento di “HelpDesk”, ma l’ACD legge la variabile call data “_AgentID_” e quindi NON accoda sulla coda HelpDesk, bensì su una coda “virtuale” dell’operatore mrossi.
La coda “virtuale” permette di personalizzare tramite script la gestione del contatto in attesa. Facciamo un esempio: se in suddetto script l’evento di accodamento prevede la recitazione del messaggio “musicadiattesa.wav”, nel caso ovviamente questo di un contatto telefonico, il chiamante sentirà la musicadiattesa.wav, proprio come se fosse accodato sulla coda “reale” HelpDesk. Stessa cosa per la gestione di eventuali timeout etc. ovvero come avviene per i contatti accodati “normalmente”.