Number of queues an agent can service, UCCX vs. UCCE

[Michael Marvin]

Hello,

I understand that in UCCX, an agent can be skilled on a maximum of 25 contact service queues, which is a limitation that is beginning to cause problems for my company. I am trying to find out if the same type of limitation exists in UCCE. I understand the infrastructure of UCCE is completely different compared to UCCX, and that a migration would be a big project. But I need to know the answer nonetheless. Can anyone assist?

Thank you!

Mike

[Tanner Ezell]

If I may ask, what is the use case in which your agents require answering calls for more than 25 queues? It may be possible to refactor your code such that you retain reportin ability (a common reason numerous queues are utilized) while reducing the number of CSQs required.

Tanner Ezell
www.ctilogic.com

[oabulaban]

i agree with Tanner, 25 is a lot per agent..

as per my knowledge, UCCE does not have this limitation... don't think of PCCE as it has a limitation of 15


Sent from Cisco Technical Support Android App

[Anthony Holloway]

I also agree with Tanner.  If reporting is the main factor, then look at using the 10 custom reporting fields.  If it's a differentiation in service, then look at priorities.  25 seems like a bit much for a single Agent, let alone more.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

[Gergely Szabo]

Hi,

if you take a look at the UCCE SRND's (

http://www.cisco.com/en/US/products/sw/custcosw/ps1844/products_implementation_design_guides_list.html), for instance, for a recent ICM 9, the maximum number of Skill Groups or Precision Queues per agent that is mentioned there is 50.

However, the same SRND for ICM 9 states the recommended number of skill groups is 5.

In my understanding, there's no hard limit there, but with each skill group you add to an agent, you might need to lessen the number of queues or add some CPU power or RAM.

Remember, a lot of parallel processing (near real time routing, reporting etc) is happening there. It might be tempting to "decorate" agents with a number of skill groups, but you may run into performance problems sooner or later.

Actually, if you have specific requirements and this limitation is something you cannot work with, I might be able to help you. If you store sort of "skill group" information in an external database, this can be used to look up the agent(s) whose skills are the best suited for that particular task.

Can you please tell us why 25 is not enough?

Thanks.

G.

[Michael Marvin]

Hi guys, thanks for chiming in. The scenario is as follows:

• There are 30 teams working regular business hours in a non-ACD configuration.
• Each  of the 30 teams is to be assigned a unique after-hours emergency phone  number that will be provided to their clients to use in the event of a  night/weekend emergency.
• There is a 31st team, the "emergency"  team, who will be logged in after hours, and will service calls coming  into all 30 emergency phone numbers. This new team requires ACD logins,  queues, reporting, etc.
• In the event of a severe after-hours  emergency, the "emergency" team may be overwhelmed with calls coming in  through a specific team's emergency number. In that case, management  will ask members from the specific associated daytime team (the one  whose emergency number is being overloaded) to login and help service  the calls.
• If a daytime agent logs in, he should be presented  with calls from clients who called his specific team's emergency number  first, and any other emergency calls second.
• There may be  members of other daytime teams logged in also, to help with their own  emergency calls. In fact, we commonly have regional events, like a  snowstorm in the northeast, which could affect multiple teams in Boston.  New York, Philadelphia, and Washington DC simultaneously. In a case  like that, the order of preference for an emergency call would be to go  to 1) an "emergency" team member if available, 2) a team member from  that client's daytime team if available, and then 3) any available agent  from any daytime team.
• Another requirement is monitoring of  queue levels (hold times and/or calls in queue) for each particular  emergency number individually, and send an alert to a manager when a  particular team's emergency number is being overloaded with calls (based  on a pre-defined threshhold). The alert needs to be specific as to  which team's number is getting hammered, and needs to be sent to  different managers for different teams.

I'm  pretty sure that if I had less than 25 teams, I could accomplish all of  this with UCCX 9.0 Premium by assigning different skill levels to the  agents, and send SMTP alerts based on queue thresholds. But the number  of teams is 30, and will likely grow from there.

Maybe  I'm missing something? Is there a way to accomplish the above without  having individual queues for each emergency number? Thanks so much for  the assistance, I really appreciate it!

Mike

[Anthony Holloway]

This is a tough subject to tackle because it's not a technical one, but a soft skill of consulting the customer.

Customers are not aware of the impact of what they are asking for, and it's up to Cisco partners and consultatnts to advise them.

In my humble opinion this is not a supportable or scalable solution and I would advise the customer against it.  Having a prioritized list of requirements will help to see that the number 1 objective is to service the caller.  And to that end, a single CSQ for emergencies is sufficient.

I'm going to drop out of this converation at this time, but no disrepect, I just don't want to be involved in an argument over how to handle your customers.

Best of luck to you.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

[Michael Marvin]

Thank you Anthony for your advice. I am hoping to steer the business away from this solution, but I am looking for as much supporting information as I can. If it's not a supportable solution, they're going to be looking for a detailed explanation of why, as well as alternatives.

Does anyone else have any thoughts on this solution, whether supportable or not?

Thanks!

Mike

[Gergely Szabo]

Hi,

this is not bad at all. Please forgive me being a visual type, but I need to create a flowchart. Gimme give me a few minutes half an hour, I will fire up Gliffy and try to come up with a solution (using UCCE, of course).

G.

[Gergely Szabo]

Hi,

can you please take a look at the following:

http://www.gliffy.com/go/publish/5344875 (or as one image: http://www.gliffy.com/go/publish/image/5344875/L.png)

Call comes in at Pilot 1, 2, 3 .. N. (N is actually 30).

The number of calls per reporting interval (day, half hour, 15 minutes etc) is measured by the next element, the so-called ICM CallType. Including the number of calls waiting in the queue (if calls are queued).

First, decision: is there anybody available in the 31st skill group, the "Emergency SG"? If yes, call is routed to the longest available agent. If not, is there anybody available in the "Daytime" skill group for that particular pilot number? Again, if yes, call is transferred to that agent.

Then, is there anybody logged in in a different group (or multiple groups, as desired)? If yes, the call is sent to the appropriate agent.

Finally, the call is queued at all possible skill groups.

The good thing about ICM (= UCCE) is that you can have realtime information at both CallType and the Skill Group level. So in this case, regardless of the number of skill groups the call is queued at, you will see exactly one call for that particular pilot, waiting, of course, on the CallType level. But if you are interested in how many calls are waiting for treatment per skill group, you will check the report/database table for skill groups.

This can fit into one routing script.

Did I get this right?

G.

[Michael Marvin]

Gergely, that looks interesting. How about the monitoring/alerting requirements, how would UCCE handle those?

Also, he business already owns and is using UCCX, so obviously they would like to come up with a solution within that system. Anyone have any ideas on making this work in UCCX? Maybe even with some compromises to the requirements to make it fit?

Thanks!

[Gergely Szabo]

Hi,

monitoring various aspects, in other words, binding a reaction to a specific event while routing is easy.

If this is needed outside of a routing context, at a global level, it's not a problem either, I can help you with that.

I might be "spoiled" by UCCE, but at this point, I strongly believe UCCX might not have the necessary capabilities for this task.

G.

[Tanner Ezell]

Mike,

Can you please confirm my understanding of your scenario:

• During normal business hours calls go to day queue based on trigger number. i.e: trigger = 1000, csq = CSQ_DAY_01
• After normal business hours all calls go to a centeral queue, i.e: csq= CSQ_AFTER_HOURS
• In the event CSQ_AFTER_HOURS exceeds a given number of calls, an alert should be triggered and email a supervisor (or call) informing them after hours is being overwhelmed with $x calls in $x_csq, $y calls in $y_csq, and so on. 
  • Message might read: "After hours queues exceeded call threshold (100 calls). Breakdown of calls by queue: 19 for DAY_01, 4 for DAY_09, 21 for DAY_11, ..."
  • From a message such as this the supervisor could best determine which day queues needs assistance.
• During after hours operations if an agent or agents from CSQ_DAY_11 were to login and clear their queue of calls, agents should then begin receiving calls for CSQ_AFTER_HOURS (but not before).
• In a severe emergency event with day agents from multiple teams logged in, calls should go to the emergency team (CSQ_AFTER_HOURS), then
• the specific team for their call (CSQ_DAY_09), then any availabled daytime agent that is logged in.
  • To me it seems like this should be reversed a bit, I would think the caller should go to the most spcific agent first (CSQ_DAY_09) before an "emergency" agent (CSQ_AFTER_HOURS). Am I understanding the requirement correctly?

• In addition to the above, the supervisors should be able to peak into real-time information regarding callers in queues for specific numbers.

Does that sum it up correctly? If so I believe we can work up a solution that would not only meet your needs but scale to the platforms maximum capacity without issue (150 CSQs).

Tanner Ezell

www.ctilogic.com

[Michael Marvin]

Hi Tanner, thanks for the reply. I'm a little confused about some of the things you said, though.

In your 2nd bullet point, you said (correctly) that after normal business hours, calls would go to a central after hours queue.

You then talk about daytime agents logging on to clear their day queues, generating alerts for # of calls in the day queues, etc. I'm confused as to how the calls got into the day queues in this scenario, since we're specifically sending all calls for all triggers to the centralized after hours queue. Can you clarify that?

Thanks!

[Tanner Ezell]

Mike,

My goal was to clarify the requirements, in this case we are suggesting they are logically going for a day queue (while literally being in the after hours queue). I wanted to understand the requirements fully before suggesting a technical solution.

Tanner Ezell
www.ctilogic.com