solution:
playing music files in the queue will cause a person to skip a place in line if the file is playing while their turn comes.
periodic announce, etc
Same queue, no agents logged in, 3 people waiting.
3 minutes
5 minutes
7 minutes
An agent logs in and the caller to be helped is…
3 minutes
(according to queuemetrics)
So the 7 minute caller had to wait another 4 minutes before being answered…
Why didn’t the 7 minute caller be answered first,
How can this bug / inconsistency be fixed?
Are you playing any announcements ?
While an announcement is playing to a caller they are not available to be delivered to an agent.
taken from http://www.voip-info.org/wiki/view/Asterisk+config+queues.conf
[quote]Note that calls are not offered to queue members whilst the announcement is playing and it is possible for callers to slip ahead in the queue as a result. For example, call 1 arrives and is queued. Call 2 arrives ten seconds later and is queued. After twenty seconds, call 1 is played the periodic announce message. Exactly one second after call 1 starts hearing the message an agent becomes free. Since call 1 is tied up with announcements, call 2 is successfully offered to the agent. Call 1 remains on hold and yet a call which arrived later has been serviced.
[/quote]
4 months later.
Thank you very much for the good advice.
After more research, this appears to exist in versions 1.2-1.6
The reason it is not well documented,
This is a problem that wont be found really until a call center manager really scrutinizes the logs,
All messages have been turned off, but still the queue callers are getting answered out of order.
perhaps this is something…
[quote]AutoFill Behavior
; The old/current behavior of the queue has a serial type behavior in that the queue will make all waiting callers wait in the queue even if there is more than one available member ready to take calls until the head caller is connected with the member they were trying to get to.
; The next waiting caller in line then becomes the head caller, and they are then connected with the next available member and all available members and waiting callers waits while this happens.
; The new behavior, enabled by setting autofill=yes makes sure that when the waiting callers are connecting with available members in a parallel fashion until there are no more available members or no more waiting callers.
; This is probably more along the lines of how a queue should work and in most cases, you will want to enable this behavior.
; If you do not specify or comment out this option, it will default to no to keep backward compatibility with the old behavior.
;
autofill = yes
[/quote]
do you have this option on?
Trying it now, Thanks !
That was a good lead, and I was glad to learn about autofill, but the client still reports that the queue callers are being answered out of order.
Queue metrics shows 2 people in line, and agent logs in, the one waiting the shortest duration is answered first.
Any other suggestions ?
Could you post teh queues.conf section for this queue and also describe what messages etc are played. also output from the cli would be useful.
Its hard to say whats happening without seeing.
Ian
this happens with autofill turned on if the agent taking the first call fails to opickup…because autofill causes calls to be handled in parallel, while Agent 1 is no answering call #1, agent 2 does answer call #2 …and there you are out of order… it gets worse becasue it will keep happening until Agent 1 either picks up or logs off. Couple of things you can do: (1) look at autologoff options so if Agent 1 fails to pickup, they get logged off (2) Look at auto answer options so an agent does not get the choice about answering when a call come in (3) get a better agent.
I have seen this happen a lot and is quite common with combination of autofill + poorly behaved agents + any algorithm that sends calls in the same order each cycle. Good training, auto auto answer are best ways to stop this.
mudslide - are you saying that it is better to have autofill turned off? I set it to autofill=yes for the queues when it was previously not defined at the advise of mazzic. All messages are off as well.
The client reports that the issue occurs when no agents are logged on, and then one logs on. In that scenario, the caller who just arrived is answered by the just logged on csr, and the one waiting continues to remain in the queue.
Ok, they have a digium support contract, we will attempt to open a ticket.
Hi
You need to get verbose output of this happening, Digium and anyone else will need this, Just going on anecdotal reports wont cut it.
What is described will happen if the first caller is listening to a message. as I said earlier post the verbose output and the configs.
Ian
The client has sent several screen shots of queue metrics, clearing displaying one caller waiting 7 minutes, another less such as 3.
The next screenshot show a freshly logged in agent, talking to the caller who waited the least. When something is measurable, it is called “empirical”, not anecdotal.
What you are saying is that you dont have access to the server, no verbose output of a call and no config. Just a screen shot.
[quote]“empirical”, not anecdotal. [/quote] BUT we have been saying all along it depends on what’s happening, hence the need for output. also what is the strategy of the queue…
the autofill will create queue jumping. however, even with a single call and two agents, in least recent, if the call goes to the least recent agent agent and, for what ever reason, the agent does not pick up the call… the call gets marked RINGNOANSWER and that agent remains the least recent…so 15 seconds later or whatever, when the queue tries again, it is going to see the same least recent agent sitting there again… and will do that indefinitely unless that agent answers the phone or logs off the queue. that is both empirical and logical. i have hundreds of observations. autofill just adds a second dimension by showing the second call jump to the second agent while this is happening.
All queues are currently configured thus:
[queuename]
autofill = yes
ringinuse=no
musiconhold = default
strategy = random
timeout = 25
retry = 5
wrapuptime=15
;announce-frequency = 90
;announce-holdtime = no
;announce-round-seconds = 45
;queue-youarenext = queue-youarenext ; (“You are now first in line.”)
;queue-thereare = queue-thereare ; General hold announcement here
;queue-callswaiting = queue-callswaiting ; (“calls waiting.”)
;queue-holdtime = queue-holdtime ; (“The current est. holdtime is”)
;queue-minutes = queue-minutes ; (“minutes.”)
;queue-seconds = queue-seconds ; (“seconds.”)
;queue-thankyou = queue-thankyou ; (“Thank you for your patience.”)
;queue-lessthan = queue-less-than ; (“less than”)
monitor-format = wav
monitor-join = yes
joinempty = yes
leavewhenempty = no
timeoutrestart =
i know that feeling since i have had to explain this to clients.
fix options:
(1) auto logout of agents who get RINGNOANSWER — easy
(2) implement AUTO ANSWER calling [most typical option in large call centers especially using QM] – easy
(3) train agents to PAUSE themselves from queue if they get/make a call not from the queue’s ACD – harder
(4) use a strategy that is less optimal for load balancing agents but will not create blocking like this [RANDOM, ROUND ROBIN …basically any “dumb” strategy that does not compute agent position based on agent history]. This will definitely not happen with a RANDOM strategy.
(5) create a tool for supervisors to see who is blocking and enable the supervisor to both log the agent out and pass on some of those choice words to the agent.
Thanks very much, but I’m confused:
(4) use a strategy that is less optimal for load balancing agents but will not create blocking like this [RANDOM, ROUND ROBIN …basically any “dumb” strategy that does not compute agent position based on agent history]. This will definitely not happen with a RANDOM strategy.
Does this imply that it should or should not use random? It has been set to random for a while. I would think the definition of random is no prior knowledge of call flow, but you never know.
Anyhow, we are now in the process of having digium look at it to verify our setup to the bosses, then after that we are ok to suggest implementing the autologoff ( a very good theory, and mentioned by other researchers working on this topic ).
Thanks again all