UCCX: Dynamic Call Routing with multiple CSQs

[Kessler82]

Hope everyone is well. Here is my current situation and would appreciate any guidance. Up until mid-year 2019, we had a resource who managed all of our UCCX administration,  that particular role has not been back-filled, as a result, I am taking it upon myself to learn this platform as there are changes that need to be made. I've got a good grasp on things, and have successfully implemented new scripts with relative ease. I'm at the point where I want to do a new IVR build because the one we have is outdated and is in need of a serious overhaul.

Here is where I need your assistance. 

We have two support numbers, one is a premium service, the other one, basic, with the key differentiation being contractual SLA's.

The way it's currently being managed:

6 unique CSQ's, 2 of those serving as a main CSQ with the remaining 4 serving as escalation routing paths to manage resource delivery. With the timing criteria in the scripting to determine when and how it passes from Level 1, 2, 3.

Premium Queue CSQs               Basic Queue CSQs

Premium_1                                Basic_1

Premium_2                                Basic_2

Premium_3                                Basic_3

Our analyst pool is skilled in three types of groups, Premium Primary,  Basic Primary and Premium backup and a group of normally off the phone resources, as a last resort  An example of these pools would like like this.

Premium Primary                   Basic w/ Primary                   Last Resort

Premium_1                            Basic_1                                 Premium_3

Premium_2                            Basic_2                                 Basic_3

Premium_3                            Basic_3 

                                             Premium_2

                                             Premium_3

While this works fine, the challenge is, it leaves a lot of capacity on the table during periods of high volume in one queue or the other, and it forces a customer to wait for a period of time before it de-queues as sends to a secondary or tertiary CSQ.

My preference would be to reduce the other number of CSQ's required, and dynamically route calls based on call type and availability. My current thought is to do the following:

Use "Most Skilled" as the selection criteria, and make the minimum competency of the CSQ to 1

Premium Primary Resource Pool                     Basic Primary Resource Pool

Premium_1 (10)                                              Basic_1 (10)

Basic_1    (5)                                                  Premium_2 (5)

Last_Resort_1  (1)                                          Last_Resort_1 (1)

The only risk I see impacting the premium CSQ would be if the basic CSQ is receiving higher than expected volume and the premium CSQ service level drops. 

The only other alternative way I can think of, is to dynamically route based on current agent availability through 'get reporting statistics' and just send to CSQ's based off that. 

Would appreciate any thoughts, or other ideas I haven't considered. 

[Anthony Holloway · Accepted solution]

You didn't mention it, so I'll assume that you don't know about call priorities. But it seems to me like you need to look into increasing the call priority of your Premium callers, so that they get preferred treatment over your basic callers.

I do think you're making a good decision to get rid of multiple queues, and let the system do the routing for you. If you just look at priorities, I think that will close the loop for you.

Keep in mind though, and I'm only saying this because you said you were learning, that the skill level of the Agent has nothing to do with the type of call they will receive next. E.g., If two types of calls are waiting: Premium and Basic, the Premium Agent could get the Basic call first, despite being skilled higher in Premium. This is because the Agent selection algorithm is controlled by skills and competency, but the "next caller" is determined only by time and priority (FIFO).

[Kessler82]

Thanks for the response, Anthony.

You are correct! I did fail to mention that, in the current state (future state too) the call priority is raised in the Premium Queues. 

"Keep in mind though, and I'm only saying this because you said you were learning, that the skill level of the Agent has nothing to do with the type of call they will receive next. E.g., If two types of calls are waiting: Premium and Basic, the Premium Agent could get the Basic call first, despite being skilled higher in Premium. This is because the Agent selection algorithm is controlled by skills and competency, but the "next caller" is determined only by time and priority (FIFO)."

This makes sense, sounds like I can ensure I solve for the highlighted by retaining the call priority in the Premium Queue?

I appreicate the feedback. The Premium Queue represents about 40% of the total volume, so i'm trying to make sure that I can provide some level of protection to answer that call in 30 seconds or less, without dedicating a sub-set of analysts to just be available to those Customers. Is there any value of using competency to protect that in this scenario?

[Anthony Holloway]

RE: Retaining Priority
Yes.

RE: Value in Competency
I don't understand your question here. However, I will say that the fact remains that once you introduce priorities in an environment where all Agents can answer all calls, the potential to starve the lower priority callers exists. It might not happen often, but like QoS on a network, you're going to want to protect against congestion. The automatic way of doing that, is to not skill 100% of the basic people in premium, leaving 1 or more resources available to handle basic calls. Because, all it takes is a steady trickle of premium calls, for no basic callers to be handled at all.

[Kessler82]

Perfect, Anthony. Most helpful. Thank you.

[James Hawkins]

One more idea would be to increase the priority of basic calls to match premium calls after they have queued for a defined period of time.

[Anthony Holloway]

I like this idea too. Good suggestion James.