Routing target question - UCCE

[Ryan Hilfers]

Wondering if anyone has any ideas on how to solve this.

Lets assume a scenario:

There are two call centers,  Seattle and Las Vegas.  There are sales and support agents in each location, routing between sales/service is handled by assigning two distinct skill groups,  support.sg and sales.sg    

Here is the customer's ask:  If the caller chooses support and they dialed from a certain TFN (DNIS), then only route to the support agents in Seattle..  BUT they still want to use the same support.sg skill group so that all other calls still route the same.

Obviously the best solution here is to make a new skill group and simply queue the calls with the special DNIS to both skill groups but i'm looking for another creative way.

Thank you,

Ryan

[geoff]

You have agent A in Seattle and agent B in Las Vegas. They are both members of the Support skill group. A call comes in for Support on a number of TNFs - say 800-555-1111, 800-555-2222, 800-555-3333 - and could be handled by agent A or  agent B, depending on availability and LAA.

Currently all three TFNs queue to the Support SG, but you want calls on 800-555-1111 to only go to agent A, and not agent B. And you don't want a new SG.

Sorry, but I can't see a way around the creation of the new SG. You could fiddle with queue to agent if you are just talking a couple of agents, but you would shortly be in a mess.

I would like to know why the customer does not want a new SG created. Please don't say "reporting". ;-)

Regards,

Geoff

[david.macias]

Reporting.

Create an enterprise SG and put two SGs in there.  The customer can then just look at reporting for the enteprise SG.

david

[Ryan Hilfers]

Hey Geoff, thanks for replying, you understood the question correctly. I also didn't think this was possible as skill group is really the lowest level of segmentation that ICM provides (besides agent) but as you said, if this were a one-off scenario handling this per agent would be feasible but its not.

There are good reasons for not making additional skill groups, mainly because of the routing strategy employed here would not allow them to segment out skill groups per location...  simply due to sizing limitations of UCCE, we would be over the 18k limit of system configured skill groups believe it or not.

This customer is more-so skilling the call than an agent pool, not the time to debate the stategy but of the 12k total skills we have configured now, segmenting by site would produce far too many skills.

Thanks for the help,

Ryan

[geoff]

Hi Ryan,

Thanks for responding so promptly. You are the first person to tell me about the 18,000 skill group limit - so thanks for that.

I see now - you just gave an example, but I sense that this is really the tip of the iceberg. The customer wants the site dimension added across the board?

You have 12k skills - how many sites?

It appears to me that skills have been created for reporting purposes - not for routing - and call types would have done that more appropriately. Do you think so?

Regards,

Geoff

[Ryan Hilfers]

Haha spot on, you've been doing this far too long! I would have to agree that most of what the customer has done in the past has been to accomplish reporting requirements      we have 12 sites and over 3 brands coming through our environment, the customer has chosen to include things like callerneed,product,transaction type,brand,language  all into the naming of the skill group, which creates a large number of combinations.

There is also a limitation of 3000 skills per Peripheral, both of which are undocumented but long story short we discovered the limitations via discussions with Cisco as we tried to obtain certification to assign >50 skills/agent.  All in all it really sounds like the right time to re-think the skilling strategy.