QueueMetrics > Running QueueMetrics

Agent's couldn't get calls

(1/2) > >>

Richarddb:
Hello,

Yesterday at 13.34 there was a problem with Queuemetrics. There were two agents busy with a call and one agent was on pause. The other 12 agents were available at that moment, but still there were some callers on a waittime. It seemed that either the agents were automically put on pause or were logged off. On the realtime screen they were available but they didn't get calls, even not the ones who were waiting.
After logging the agents in again, they could answer the calls. This never happened before...

How is this possible? And what can i do about this?

Thanks for the help

QueueMetrics:
Asterisk sometimes logs off agents automatically if they have failed answering for a while. In the queue_log, such lines are marked as "Autologoff".

Richarddb:
In the queue_log there are no lines as 'autologoff', so it means it has another cause.. is there anything else to solve this?

QueueMetrics:
When this happens, do you have an idea of what was the queue status a s seen by Asterisk? or did you maybe restart Asterisk?

mudslide567:
i have seen this many times.  it is not usually a QM problem. i have found a number of different reasons usually rooted in a combination of member behavior and queue configuration. 

For example:  ring strategy is "least recent"... but least recent member is not answering and queue not set up with auto logoff...so queue simply keeps trying to route call to the one member who does not answer while others sit there idly.  the corollary to this is that if a second call comes in and the queue is set to autofill, the second call will glide right by to an available agent [second lest recent] while the first call is still stuck on the first non answering agent.

another example: a least recent agent who has previously taken a call and performed an attended transfer, effectively locking up their extension so that it shows available to the queue (and QM).  However, the phone is actually tied up until the transferred call ends and so when the calls are routed there, they will show in the log as RINGNOANSWER [and have the same result as previous example].

Generally I can find logical explanations for apparent anomalies like that described by simply watching QM, figuring out where the next call should be routed to and then going to see what is going on at that endpoint. 

Navigation

[0] Message Index

[#] Next page