02-10-2014 09:13 AM - edited 03-14-2019 01:04 PM
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
02-10-2014 09:18 AM
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
02-10-2014 09:39 AM
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
02-10-2014 09:46 AM
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.
02-10-2014 10:10 AM
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.
02-10-2014 10:23 AM
Hi guys, thanks for chiming in. The scenario is as follows:
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
02-10-2014 11:28 AM
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.
02-10-2014 01:33 PM
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
02-10-2014 01:41 PM
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.
02-10-2014 02:14 PM
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.
02-11-2014 06:57 AM
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!
02-11-2014 07:33 AM
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.
02-11-2014 08:15 AM
Mike,
Can you please confirm my understanding of your scenario:
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
02-12-2014 07:29 AM
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!
02-12-2014 07:34 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide