UCCE Custom Routing Using Queue To Agent

[villarrealed]

I have a customer interested in performing their own agent selection using a database lookup rather than selecting agents based upon skill group assignment. The suggestion has been made to perform the database lookup and use the queue to agent node. This would be used in a mid-sized environment, several thousand agents, and the there could possibly be hundreds of agents listed in the queue to agent node for a particular call. Has anyone had any experience on using queue to agent in this manner? I'm curious if pushing the queue to agent functionality beyond it's intended purpose would cause issues.

[jimbrittcisco]

Can't help you too much other than to say if it were me I'd let them know that with that many agents, something like this could be very, very hard to manage.

Imagine everytime an agent is hired or leaves. Do you have touch these nodes and the DB? let alone the reporting, what happens with RONA, etc..

[geoff]

Queue to agent indirect with a DB lookup is workable - the result of the lookup must be their agent ID.

What would be the lookup criteria?

You need to establish an Enterprise Skill Group and an Enterprise Route using a skill group that will NEVER be removed from the agent (say by dynamic reskilling), so give it an artificial name like Q2Agent. Agents would also need to be in an overflow skill group.

You won't have to touch the script - there will be just one Queue to Agent node.

Don't queue if the agent is not logged in - overflow to a queue to skill group. Don't queue too long at the selected agent if they are logged in - again, oveflow to a queue to skill group.

You will have to manage the DB when an agent leaves, but it doesn't matter much because they won't be logged in. When a new agent arrives you will have to add an entry to the DB - but even if you don't it will be OK as the lookup willl fail and you will just queue to the overflow.

It's actually worth playing with.

Regards,

Geoff

[villarrealed]

Thanks for the feedback Jeff.

[villarrealed]

Jim,

Thanks for the feedback. I know it would be a nightmare to manage and there would be issues with reporting and WFM in particular. They have an agent database to manage agent relational data across multiple systems for reporting purposes and this would provide the lookup data for the routing. My big concern is with the ICM system itself and whether it would choke on the volume of DB dips and use of the queue to agent for every call.

[geoff]

No problem with ICM DB Lookup on every call - that's quite optimized. Queue to agent will not be an issue. You are just doing the work the Call Router has to do when you say Queue to Skill Group - in fact it should lighten the load in a tiny way.

The problems will not be in ICM - the problems will be in the data management.

Tell me again how the lookup works? What's the input data? You need to come back with one agent ID. How?

Regards,

Geoff

[villarrealed]

Geoff,

We are looking to use the GatewayODBC product offered by AS because of the complexity of the lookups.

This customer want's to use the queue to agent for multiple agents simultaneously. We would need to return multiple agents concatinated with a separator, probably a comma, and then use a formula to populate the queue to agent node with the multiple agents. In some scenerios the customer offered up, this list could contain several hundred agents that would need to be listed in a single queue to agent node.

The data input would be from the custom agent database that would take several factors and using an algorythm, provide a number for ranking purposes. The agent IDs would be stored in this agent database.

[jimbrittcisco]

Somewhere a TAC guy shudders at this thread..

I know that some ICM systems do get absolutely hammered with external and call by call lookups, and they run fine, or at least much of the time. What the exact threshold is, I don't know and it's probably very architecture specific. Good luck.

[geoff]

>In some scenerios the customer offered up, this list could contain several hundred agents that would need to be listed in a single queue to agent node

You've got to be joking. That's not going to work. Queue to agent is meant for specific agent routing - preferred agent, last agent spoken to etc. As a prequel to a Queue to Skill Group.

I don't know, of course, but I don't think it's designed for putting a bucket load of agents in there - I've never tried more than one row.

As far as the DB Lookup or Application Gateway goes, I don't see a problem. I know of one customer with 4000 agents and they were doing a DB Lookup on every call.

Regards,

Geoff

[villarrealed]

Geoff,

It scares me thinking about this. I've never had more than one agent in the queue to agent node either and I'm not sure what will happen with 2 let alone 200 agents listed in this node. This is an idea presented by the customer who has several employees who have ICM experience. It is a very interesting concept, but my fear is that ICM will choke on the volume of agents in the queue to agent node.

Thanks again for the feedback.

[geoff]

OK, well it's pretty interesting and you seem to have UCCE experience, so as long as a decent prototype is built and there is an understanding that the prototype must be proven before the idea is adopted, you should at least check it out. Could be something useful here.

Regards,

Geoff

[david.macias]

Just a note, when you way DB dip, you're talking about ICM DB lookup? If so, I don't recommend using this, your best best is some sort of app gateway or have a peripheral do it.

david

[geoff]

David, he wrote:

"We are looking to use the GatewayODBC product offered by AS because of the complexity of the lookups."

Regards,

Geoff

[david.macias]

Thanks, totally missed that part.

david

[castrillor]

Hi all,

I now this post is quite old but I have a question about "Queue to Agent" node and I would apperciatte if someone could help me.

We have a "dinamic" Queue to Agente node where the  preferred agentID is obtainted froma an external app using App Gateway. We are able to queue to the agent with no problem, have a treatment for the queue and sending the call to agent as soon as he becomes available.

The "only" issue we have is that, as far as I know, we need to have the whole "Route-Peripheral target - Label" configured for every agent. As we have 8000 agents in the system it is a huge config task and difficult to mantain. (Now we are using Agente Autoconfiguration)

Do you know if there is any possibility of no having to configure a route (PT and label)  for each agent and if it is possible to send the call using a dinamic label or something like that.

The system version is ICM 8.01 and it is integrated with AVAYA ACDs.

Thanks and regards