What is an SLA?

An insurance company just received tentative approval from another large company to provide long-term disability insurance. Now lawyers from both sides get together to duke out the details. One detail specifies the level of service required by the insurance company. A definable metric might include how quickly the call handlers will answer the phone and how quickly they will resolve the request. These metrics and others are known as the Service Level Agreement (SLA).

You can use action logic to program SLAs, but it is not easy and becomes overwhelming if SLAs count only work hours or there are multiple SLAs in the same model. Fortunately, a new capability makes calculating and reporting SLAs simple.

How to set up an SLA

Well, we said it was easy, so we’d better be able to prove it. So this is how the SLA feature works.

Case 1 – SLA for Different Priorities using 24-hour per day, 7-day week clock

A customer negotiated for different SLA response times for three priority types:

Define Attributes and Variables

Create attributes and variables to collect information. First, create “attributes” that delineate the entities. In this case, we use a_Priority to define the different categories of problems. Then create a variable used to record the value of the attribute for each Entity exiting the model. The variable records the attribute’s value for each Entity leaving the model. In this case, the variable v_Priority records the attribute values of a_Priority. Next, use a variable to record the desired time value at each entity exit. In this case, we use v_Response_Time to record each Entity’s total time in the model.

Attribute:            a_ Priority                          Type: Integer

Variables:            v_Priority                           Type: Integer

v_Response_Time           Type: Real

Set the Priority Value for Every Entity

In this example, we set the Entity’s priority, but in other systems, the delineators might be the type of customer, acuity, or many different elements. Set the “priority” for every Entity. If importing the entities, then set the value before import. If the model sets the priority value according to probability, then ensure the setting of the Priority attribute before the Entity reaches the data collection.

Collect Data — Enter Action Logic on Each Exit

On every Exit route, write the following action logic:

The example logic above uses names for attributes and variables defined by our model. Use attribute and variable names that match your purpose.

Writing variables simultaneously lets the system know these variables are related to allow reporting of SLA stats. For example, complex groupings might require more than two variables to delineate subgroups. The principle is the same for complex systems – simultaneously write all the needed variables. For example, in a call center servicing several companies, you may want to add another delineator called v_Company (a numeric value for the customer name). This additional attribute allows separation by priority and Company.

How to Access the SLA Statistic

The following screenshots provide the procedure to show all service level agreement statistics in the Smart Stats output program.

Click on the New Report button, and a blank output sheet will appear.

Click on the Service Level Agreement button. Then, click on the layout where you want the upper-left corner of the statistic to appear.

First, select the SLA time statistic. Second, enter the SLA test value. For example, the expected response time is 15 minutes. Third, enter the percentage required to be lower than the expected response time.

Next, hover the mouse over the left side of the header and click on the filter icon.

Select “one” to show only priority one statistics.

The data above provides the basis for priority 1 SLA statistics. See the display results below:

Achieving the service level turns the cell green while failing the service level turns the cell red.

The new report displayed below shows the SLA for all three priorities:

Case 2 – SLA for Different Priorities using only work time  — 5 days a week, 8 hours per day

The main concepts remain constant, but you must use a clock that only advances when the required shift is active. In the previous example, when a call enters the system, the attribute CycleStart is set to the simulation clock. At the end of the simulation, the beginning time is subtracted from the current time to provide a response time.

In this example, a small Model Object provides the clock that stops moving when off-shift. The name of the model object is SLA Clock. Insert the model object and make the following changes to your model.

1. 1. Create a shift for the SLA Clock Activity. Create the shift to match your requirements. See the example shift below for five days a week, from eight AM to five PM.
      
   2. Browse to find the newly created shift.
      
   3. Adjust the SLA Clock’s resolution by opening the activity’s action logic.
      The resolution determines how often the logic cycles. For example, the resolution shown in the clock above means that the clock will cycle in 1-minute increments.
   4. When an entity enters the simulation, set the value of the attribute a_SLA_CycleStart to the SLA clock variable v_SLA_Clock_Time1.
      
   5. On every entity exit, modify the collection logic to use the SLA Clock variable and SLA cycle start attribute used at entity entrance into the model.

Display the SLA statistic for modified work weeks using the same techniques the previous SLA example used.

Benefits to You

With only a few variables and attributes, many separate SLAs become available. Therefore, there is no need to define independent variables for each group. In addition to requiring fewer variables, this method of setting up and modifying SLA information is faster and easier.