Introduction

In order to measure workgroup call handling efficiency, it is important to define parameters for expected queue time limits. It is very common that what may be an acceptable wait time for one workgroup, may be completely different for another workgroup. Max Communications Server allows for per workgroup setting of a "Service Level Threshold," measured in seconds that can define as what the expected queue time should be less than.

A "Service Level" can than be calculated as a percentage of calls handled for each workgroup that can be used as both a workgroup performance metric, as well as a criteria for queue overflow options.

Service Level Threshold

Service level threshold should be thought of as "acceptable" allowed limits for queue time. While it is unrealistic to think that occasionally calls may exceed this time limit, by setting the threshold in this manner, it becomes much easier to use an application like AltiReport to get statistics on how frequently calls reach this state.

Using a service level threshold is a better metric to determine inbound caller wait time than simple average queue time, because it does not allow a small number of calls with a high wait time to skew the results. Consider a workgroup that may spend most of it's morning making appointments, and the afternoon providing longer more in depth information regarding their business. As a result queue times in the morning will likely be very low, as the calls are quick, while in the afternoon the queue times increase greatly. Perhaps a group like this, handling 100 calls a day has an average queue time of 3 min. The supervisor for this workgroup may have an expectation that calls are answered in less than 5 minutes (and so has the SLT set at 300 seconds) and think that they are doing an excellent job of meeting this statistic, however a measure of how many calls exceed the SLT could potentially show that 40 calls in the afternoon exceed 5 min. of queue time, but that the average is lowered because of the very short queue times in the morning.

Service Level

It is this concept of what percentage of calls exceeds the service level threshold that is used to calculate a service level. Strictly speaking AltiGen defines "Service Level" as, "a service quality index which calculates the percentage of calls serviced within a defined threshold for the defined period of time," and provides the caveat that, "the term 'serviced' may not necessarily mean answered."

In fact, MaxCS allows the system admin to define, per workgroup, what is used as the definition for "serviced". In order to understand the various manners in which service level can be calculated, it is important to note the three ways in which a call exiting queue can be logged:

1. Answered: The call is answered as a workgroup call by a member agent.
2. Abandoned: This includes all states where caller action caused themselves to exit the queue. This includes both hanging up, as well as selecting an option in the WG (such as pressing # to leave a voicemail). Additionally, if an RNA event (either Agent RNA or Group RNA) routes the caller to "Agent VM" or "Group VM," the call will be logged as abandoned to VM.
3. Overflowed/Redirected: All other exit states - this can include an workgroup supervisor redirecting the call or when queue overflow redirects the call. If a RNA event (either Agent RNA or Group RNA) routes the caller to anywhere other than "Agent VM" or "Group VM" it will count as "Overflowed/Redirected".

Real-Time Service Level

The additional purpose for defining a Service Level Threshold is to provide guidelines for when calls should overflow a workgroup queue. In this case, defined service level for the day would be an inappropriate metric- an extremely busy morning should NOT have any bearing on how calls will route in the afternoon. Rather than using the same Service Level calculations that are used for overall workgroup performance level evaluation, a Real-Time Service Level (RTSP) is calculated by comparing the number of calls in the workgroup queue which have exceeded the SLT to the total number of calls in the workgroup queue. While it is possible to set overflow rules based on the length of time in queue, or the number of calls in queue, using an overflow rule based on the Real-Time Service Level provides an overflow rule with an inherent fault tolerance. Instead of immediately overflowing calls that exceed a defined time, a certain number of calls exceeding that time need to be in queue before the overflow rule will take effect.