Calls in ACD not always being delivered to correct agent

[theblarney1]

Hi,

I am having a strange issue where calls into a call centre is not always being delivered to the longest idle agent, sometimes it is skipping this agent and going one that has been idle for less time.

I can view the idle times in the 6110.

I have checked that realtime is enabled on the Path and Queue, I originally checked that skills wasnt enabled but as a test enabled skills and gave all agents in the skillset group the same level (1) which hasnr made a difference.

Just curious to see if anyone else has the same issue.

The 3300 is running MCD 4.0SP3 (not PR1) and the 6110 is running 5.7SP1.

Thanks

 

[LoopyLou]

Your 6110 database up to date/correct?

The single biggest problem with communications is the illusion that it has taken place.

 

[theblarney1]

Yep all present and correct.

 

[sarond]

I am yet to go to a site to confirm/test with a client but I think I may have a similar issue.

It seems an agent is receiving calls even when the work timer is active. The calls just keep coming through to the agent almost immediately even the work timer is set for 2 mins. The only thing I can think of at this stage is that the agent ID is the lowest directory number of them all, this should have no impact but I have nothing else to go by as all agents are programmed exactly the same.

Please post if you find a solution.
I'm running MCD 4.1 SP2 / CIS 5.7 SP1

 

[LoopyLou]

First of all, not aware of any issues.

Do you have multiple paths with the same agents and agent groups?

The single biggest problem with communications is the illusion that it has taken place.

 

[kwbMitel]

I believe you will find that the calls that are out of sequence are not coming thru the queue but instead are direct calls or transfers.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[theblarney1]

Hi kwbMitel,

I can confirm that these are definitely not direct calls or transfers.

 

[surferx0]

I had this reported as well, but what I found is that the idle time reported by the 6110 is not the same as the ACD idle time.

I'm going to guess your site has ACD agents also taking non-ACD calls? The 6110 will reset the idle timer and place an agent back down to the bottom of the list when coming off a non-ACD call, but the ACD timer does not reset from non-ACD activity. Work timer also has no effect on non-ACD calls.

So an agent who just came off a non-ACD call can immediately receive an ACD call even though it appeared on the 6110 that they were on the bottom of the list. This can give agents and managers the impression that both work timer isn't functioning and that ACD calls aren't being distributed fairly.

The only time the longest idle agent displayed on the 6110 will get the next ACD call is in a pure ACD environment. Ultimately, in a mixed environment your agents are still getting distributed the ACD calls in a fair manner, you can look at your ACD records for ACD answer events to confirm that, but looking at the 6110 in real-time they'll have no idea who is actually "next in line".

 

[boycey9]

Seen this several times, the first step you need to do is find out if the call actually exists or not. What I mean by this is are the users who are reporting this watching the CCM or can they see it on the phones themselves.
For example, I had a call come in that got answered by an agent but it was never displayed as answered, and on the CCM realtime it still showed as ringing, therefore according to the CCM that agent was the next to get a call but as he had already taken a call the CCM view was incorrect.
The above will establish if the issue you are seeing lies with the 3300 or the CCM
It usually has somthing to do with queue refreshes, how many queues do you have on your systems.

 

[theblarney1]

Hi Surferx0,

It seems that you were spot on, we found that if an agent was next in line to take a call, their idle timer in the contact centre client would reset back to 00:00 if they received an internal or DDI call but the 3300 would still pass them the call (basically still honouring the previos idle time).

There is a registry edit that can be made to rectify this which we are testing at the moment.

More details here:

http://www.prairiefyre.com/kb/KnowledgebaseArticle50021.aspx?Keywords=idle+state