Pros and Cons for SL routing and Skill routing

[CTIgem]

Anybody out there who had done service routing, I'd like your opinions about Pros and Cons regarding service level routing vs skill based routing.

Thanks in advance for your input.

[Kevin]

From page 224 of the URS Routing Reference for 7.1:

"At an interval of every 50 interactions or 30 seconds, URS calculates the
Service Factor for that interval, based on the interactions that passed through
the strategy."

Because of this, the calculated service level for the routing may not match your "to-the-minute" service level for the day.

If you need this value calculated outside of these values, look elsewhere. I had attempted to use it in the past, but the update frequency was not enough. It actually wound up being more of a problem than a benefit, because I always had to explain to the business why their daily service level was below objective, but the calls were not routing to available agents. 

In my experience, this tended to have a very negative impact on the daily service level, as opposed to helping it.  [Note: I was trying to use it for a small team - less than 20 agents - in a call center with a total environment of 250 agents. It may have a different impact in a larger call center]

[Kevin]

If you wanted to, you could probably create a formula (or a subroutine) that varied the escalation time, based on your "to the minute" service factor.

For example, if the service objective was 80%/30 seconds, and the routing targeted Low-skilled agents first, then Higher skilled agents, this could be done:

Escalation Time = the number of seconds the first group is targeted.

Simple Solution:
- Set the base escalation time (BET for brevity) to 30 seconds.
- If ServiceFactor >= Target (80%), then Escalation Time = BET
- If ServiceFactor < Target, then Escalation Time = BET/2

Slightly more complex solution
- Set the base escalation time (BET for brevity) to 30 seconds.
- Escalation time = Service Factor * BET
Using the second solution, your initial wait time will decrease (and hopefully, your speed of answer will increase) as the Service Factor drops.

You could also modify this solution to consider the Average Speed of Answer, or other pertinent statistic, as well.

[CTIgem]

Thanks for the info.
I was wondering about 50 interactions and 30seconds.
Since our center is small like yours, I'll run into the same problem.

[Genesys CTI Forum Administration Team]

Hi,

several months ago, our company has tested Service-Level versus Skill-Level and the results were very mixed.

Implementation:

Genesys' definition of Service Level is different from the one used by most of the call centers. I am sure that you were already aware of it. They call it Service Ratio or something similar to it and so right away, you end up defining two types of SLs: one for your call center and one for Genesys.

SL also requires you to identify targeting group's priority by High, Medium, Low which we found inadequate for multi-skill operator callcenter. It is also static, meaning that to change the targeting importance one needs to modify the strategy. Considering that many of the services have peaks at different times of day, this presents obvious problems to us, since we needed to have SL importance of a service to be either based on time table or overall load compared to the other incoming calls. To get it working with SL, we would need to create many IF-blocks per different scenario variations, cluttering both the strategy and our minds.

Advantage: Skill-Level Routing


Targeting:
SL simplifies routing by great deal, but unfortunately, we found that in a LDS-URS configuration, it fails to take into account the routing done by other URS and since all interaction-based calculations for SL are done on URS-level, the whole concept starts to make less sense in a multi-URS environment.

We also found the 15-second recalculating rule (I think it was 30) to be too short to see the overall flow and too long to adjust for sudden call inflows, resulting in scenarios where you would have 200 calls sitting in one queue, and calls from a queue with only 5 being distributed one after another.

To simplify things (and load), we are using VAGs as targets in our call center, where not only do we have VAGs for each service, but we also have VAGs for levels of that service as well. For example, we would have VAG_CS_High, VAG_CS_Medium and VAG_CS_Low. So, using SL across the whole call center is not possible with current implementation of SL, we could not figure out how to make one service have a priority over the other, while still ensuring that that operators with high level skill would be targeted over the operators with the same skill but lower level. It can be done, but we could not figure out how to do it without braking up the current VAG_[Skill]_[Level] structure.

At the end of a day, we found SL-based strategy's distribution rate to be 12% below that of skill-based one.

Advantage: Skill-Based Routing

Reporting:
It is simply not there. I mean, there is no simple way to get existing SL for each groups targetted by URS and we want to see what URS has caluclated, making us wonder what is going on.

Advantage: neither

My initial reaction to SL was : wow!!!! I want to use it!!! The more I tested it with others, the more I felt the potential for this object, while feeling the existing short-comings. I think that with time, SL would be the best way to route calls, but to achieve this, Genesys needs to address multi-URS support, multi-queue support, dynamic and time-table support for priorities for each group, and tighter integration with existing reporting services, not to mention DB.

I think that this would be great for a very large call center with a lot of services and not picky clients, who do not demand tweaking of routing parameters during call center operation and do not care about the intricacies of how the call is being routed. It is truly unfortunate that our tests have shown that SL-based callflows under-perform skill-based flows, but we suspect that in part this is due to dynamic nature of our call center, where different flows have peaks at different times. I also think that with further tweaking of BET and re-arranging VAGs, SL can match and perhaps even improve the overall performance. Unfortunately, Genesys does not really have any studies published for it and it is up to individual users to figure out what they want.

I foresee that in a near future, we would start migrating our callcenters toward SL, because of simplicity in design, but we have major concerns regarding BET (30 seconds is a long time when you just opened your lines, and have 3000 operators standing by), URS load and SL flexibility in terms of tweaking-on-the-fly.

Best regards,
Vic