ICM 6.0 Stuck Agent

[RattFang]

Hi!
We run ICM 6.0 in a mixed environment of Avaya G3r's and 8700's. We use mostly longest available agent type call routing. Approximately a year ago we noticed inequitable queuing between our sites. This is to say, one call center would be hammered with calls while call centers with same skilled agents would not receive calls. We found that we for reasons unknown to us that some agents would become "stuck" in available state in the ICM while showing a different state in the Avaya monitor BCMS.
We have since upgraded to the latest and greatest RTA from Avaya and had at least one engineering special provided by Cisco.
I can't think that we are the only ones who have seen this...
Helllllllp!

 

[sessiona]

I would run an rttest expr commands on the SkillGroup.LongestAvailable and see if the values are consistent. I have noticed the same problem in our environment, but we are thinking that it might be an issue with the way that the Avaya is distributing the calls. In other words the longest available agent may not be getting the call first which causes the LongestAvailable agent to appear falsly high at that site. We are switching our sites to use Avaya skill group type eas-mia(most idle agent) from eas-loa (longest occupied agent).

Hope that helps a bit.

 

[RattFang]

Thanks. We have run the session commands. It is obvious that the ICM is seeing the agents as "available" while the PBX can see them in pretty much any other state... including logged out. Of course, it is not a problem until the agent becomes the "longest available agent". We had built into our scripts to check for longest available agent combined with calls in the queue for the agent. If the condition exists, then no more calls to the site for that skill. I just thought maybe it would be better if we worked with the vendors to get ICM to perform its most basic function.

 

[sessiona]

I mis-read your first post, sorry. I have seen that happen as well and it ended up being a problem with the Avaya CMS realtime report, but we never found the root cause. You might also verify that you are running version 5.0.5 of the CMS realtime report.

As a work around you could switch to looking at MAX(Avail) instead of LongestAvailable for your Agent surplus conditions. That might lessen the impact until you can find the bug.

I am very curious what you find!

Just a thought!

 

[nigel5000]

hi
We are also encoutering this issue with a Definity set up.
Agents are often stuck in the available state but not building up any available time.
It would seem that the raw data on the PG and the CMS tie up, it is only when it is maniplulated within the ICM that the problems arise.

In our route select instructions we have changed the consider if to look for available agents and available time and that there are no calls already queuing.Complete overkill I know but this helps.
We have found that restarting the geotel reports will bring things back in line (sometimes only for a few mins) on most occasions but this is no fix.We have multiple sites but often seem to find this problem affects just one, seems to go away for a bit and then reappears.

Trust that there are no agent priority issues between skills in ICM and what is being used on the switch ?

Awaiting responses from Ciso at present.

 

[sessiona]

I am seeing the same issue in our environment now. Go figure. We have an Avaya/ICM 7.1.3 environment and we use Avaya AES for our ASAI and CMS 13 for our agent realtime data feed.

It seems like it is only happening on a single agent at a time, but I watch the LAA timer and it just continues to go up until it hits 4000 seconds and then it resets.

I know something is wrong because the Avaya CMS reports no agents available in that skills so there must be something wrong with either the Real Time report on the Avaya side or a bug with Cisco because I will show calls in Queue and agents available at the same time. Very strange!

I am submitting a ticket to Cisco and I will let you know what we find out.

 

[toddmmccall]

We have Nortel Symposium on ICM 4.6 and experience the same thing. We have dubbed the coniotion to be "Agent Synch Issues"
We primarily use Route Select nodes in our scripts, so our solution pertains to those nodes. We keep a value in every consider IF statement that looks for two or more agents available (if one is stuck as Available). Then, in the Select Max portion, someone came up with an ingenious method... we calculate the percentage of agent status as related to the number of agents staffed.
For agent surplus conditions its Avail/Ready and for call surplus, its CallsQueuedNow/Ready. But how do oyu know whuich condiion you are in, right? Well that's where the beauty comes in... what if a cals in queue condiion resulted in a NEGATIVe value, and an agent surplus condiiton resulted in a positive value?
So, here's the formula (Avail-CallsQNow)/Ready.

This formula rids us of the pesky stuck agents by merely taking one or two calls out of the queue value. But the benefits of having a Call Center Status value is... well its invaluable!
We even created variables to calculate this status every second in an admin script. Call balancing has never been easier or more predictable.

-Todd-