[asterisk-users] question about queue

David Cook dbc_asterisk at advan.ca
Tue Apr 15 10:46:21 CDT 2008


> Two use-cases where autofill=no is desirable:
>
> 1)  If it's important that you answer your callers in strict order (i.e. 
> in order to meet estimated wait time commitments etc).

Not always the case. Let's look at multiple queue assignment where agents
have skills (logged in) to multiple queues.

AGT1: Has SkillA, SkillB, SkillC
AGT2: Has SKillA
SLA: 24 seconds

Senario --------
Calls in Queues:
Call1: SkillA - 15 seconds
Call2: SkillB - 12 seconds

AGT1 will become available in now() +2 seconds
AGT2 will become available in now() +6 seconds
------------------------

CASE 1 (Calls in strict order):
TIME=now()+2:  AGT1 becomes available, CALL1 matched, time in Q now 17
seconds, assigned, SLA OK.
TIME=now()+6:  AGT2 becomes available, CALL2 NOT matched, not assigned, AGT2
idle, awaiting AGT1 to finish call, time in Q now 18 seconds.
TIME=now()+10: AGT2 idle, CALL2 sitting in queue, SLA failed.

CASE 2 (Calls not in order, system SMART enough to read into the queue and
predict availability based on historical data)
TIME=now()+2:  AGT1 becomes available, CALL1 matches, but system knows that
CALL2 is also a match and remaining agents are NOT a match. Predicted
availability says call 2 will fail SLA, system assigns CALL2 to AGT2, time
in Q now 14 seconds, SLA OK.
TIME=now()+6:  AGT2 becomes available, CALL1 matches and is assigned, time
in Q now 21 seconds, SLA OK.
TIME=now()+10: AGT1 on call 2, SLA OK. AGT2 on call 1, SLA OK.

Now this isn't strictly the problem originally described but I'm trying to
articulate where the use case as specified falls down in real-world
environments. This also shows and area that Asterisk (and _many_ other
switches) have not gone yet but we need to aspire to. This type of
functionality is why you currently shell out the bucks for Avaya. 

    
- dbc.





More information about the asterisk-users mailing list