Ogni contact-center, o differente realtà che utilizzi massicciamente l'inbound telefonico, utilizza (o sarebbe opportuno utilizzasse una politica di distribuzione delle chiamate basata sull'uso di code, indipendentemente dal fatto che si utilizzino agenti oppure semplici membri (channels).

Anche in questo caso, però è opportuna l'impostazione di una strategia in grado di ottimizzare tale distribuzione.

Ci riferiremo a quanto mette a disposizione il sistema delle code offerto da Asterisk (queues,conf).

Strategie

Le chiamate vengono distribuite ai vari membri partecipanti ad una coda in base ad una strategia scelta fra alcune possibili, definite in queues.conf

• ringall: chiama tutti i channels disponibili fino a che uno risponde (default)
• roundrobin: a turna chiama ogni interfaccia disponibile
• leastrecent: chiama l'interfaccia meno recentemente chiamata (nell'ambito della coda)
• fewestcalls: chiama quella col minor numero di chiamate (nell'ambito della coda)
• random: chiama a caso una interfaccia
• rrmemory: round robin con memoria, ricorda l'ultimo membro chiamato con successo, escludendolo.

Penalties

I membri di una coda possono essere definiti in base ad una penalità (penalty) Ad esempio:

member => SIP/200,1
member => SIP/201,2
member => SIP/202,3
member => SIP/203,2

Alcune note su roundrobin ed rrmemory

roundrobin non deve venire confuso con "distribuzione circolare delle chiamate".

La strategia roundrobin ricorda l'ultimo membro dal quale era partito in precedenza, e parte col prossimo membro della lista. Nel caso in cui si abbiano 3 agenti (o membri), la prima chiamata ricade nell'ordine 1->2->3, la successiva nell'ordine 2->3->1, la prossima ancora nell'ordine 3->1->2, etc.

La strategia rrmemory l'ultimo membro chiamato, indipendentemente da quello di partenza, di modo che la prossima chiamata ricada sul membro successivo all'ultimo che abbia risposto. Sempre nel caso in cui si abbiano 3 membri e la prima chiamata ricade su 1, poi su 2 (e viene risposto), allora la prossima chiamata chiamerà 3, poi 1.
Nel caso in cui quest'ultimo risponda, allora la prossima chiamata chiamerà secondo l'ordine 2->3->1, etc. Nel caso della prima chiamata, se il membro 2 avesse risposto e la strategia fosse stata di tipo roundrobin, sarebbe rimasto il destinatario della successiva chiamata, mentre la strategia rrmemory lo escluderebbe.

E' possibile comunque ottenere una distribuzione circolare delle chiamate usando la strategia roundrobin e impostando una differente penalty per ogni agent (o membro), singolarmente o a sottogruppi, nell'ordine cioè in cui si desidera vengano chiamati.
App_queue tenterà sempre di chiamare tutti gli agents senza alcuna penalty, poi quelli con penalty 1, etc.

Wrauptime

Questo modo di impostare la distribuzione è l'ideale per attuare un servizio di contact-center cosidetto 'skill based', in cui si cerca di far ricadere la maggior parte delle chiamate dugli operatori più efficienti o preparati.
Anche qui il criterio di applicazione può essere reso meno rigido, al fine di evitare un sovraccarico di chiamate sempre agli stessi, impostando im maniera opportuna il parametro wrupuptime, relativo al tempo che deve trascorrere prima che un operatore che abbia appena terminato una chiamata sia consideraro ancora disponibile a riceverne una altra.

Cascading Queues (code a cascata)

Si può impostare una serie di code che ricadano l'una sull'altra.
E' possibile ottenere un effetto simile utilizzando penalties differenti per differenti sottogruppi di membri, ma questo sistema offre una alternativa che potrebbe essere più comoda od elastica (per via del timeout differenziabile) in talune situazioni.

E' fondamentale impostare un timeout per ciascuna coda. Ciò è ottenibile passando lo specifico parametro al comando Queue usato in extensions.conf.

Si può così impostare un certo numero di code che il dialplan consideri semplicemente in successione.

L'esempio seguente ipotizza una chiamata intenzionalmente indirizzata all'ufficio vendite: nel caso in cui, entro un timeout di 45 secondi, nessuno degli agenti di quella coda risponda, la chiamata ricade sulla coda gestita dagli agenti che si occupano di amministrazione, insistendo un po' di più, prima di passare la chiamata al personale tecnico:

exten => 1589,1,Answer
exten => 1589,2,Ringing
exten => 1589,3,Wait(2)
exten => 1589,4,Queue(sales_q|t|||45)
exten => 1589,5,Queue(admin_q|t|||60)
exten => 1589,6,Queue(support_q|t|||25)
exten => 1589,7,Hangup

Priority  invece opera nel modo seguente:

Essa fornisce la possibilità di superare l'abituale modalità FIFO di operare. vale a dire la possibilità non solo di accodare una chiamata in entrata, ma di posizionarla in qualsiasi punto della coda, in base al parametro in questione

In tal modo diventa possibile utilizzare una sola coda per accogliere tutte le chiamate in ingresso (le più importanti e quelle meno importanti) nell'ordine desiderato. La priority di una chiamata che entra in coda viene determinata da una speciale variabile channel, QUEUE_PRIO. Valori maggiori di tale variabile implicano una più alta priorità Non impostando tale variabile, tutte le chiamate posseggono la stessa priority, convenzionalmente 0, per default (semplice FIFO).

 ; clienti importanti 
 exten => _065437652/_065485471,1,Answer
 exten => _065437652/_065485471,2,Playback(welcome)
 exten => _065437652/_065485471,3,SetVar(QUEUE_PRIO=10)
 exten => _065437652/_065485471,4,Queue(support)

 ; clienti meno importanti
 exten => _065437652,1,Answer 
 exten => _065437652,2,Playback(welcome)
 exten => _065437652,3,SetVar(QUEUE_PRIO=5)
 exten => _065437652,4,Queue(support)

Weight

Si può anche impostare per le code una opzione weight, per fare in modo che, nel caso in cuii uno o più membri appartengano a code diverse, prendano prioritariamente le chiamate in attesa sulla coda avente maggiore 'peso'.

weight = <valore intero>

• Chi sono
• Prodotti software
• Tecnologie
• Articoli
• VoIP
• Linux
• Asterisk
• SER
• Case studies
• Links
• Fight the SCAM

Text zoom