REQUEST A DEMO

SLA Monitoring

One of the common tasks for a support/call center manager is making sure the team is living up to its service level agreements (SLAs). Pretty much every customer I’ve ever dealt with has different SLAs. As you can imagine, there’s a zillion ways for companies to setup and track their SLAs.

 

Example SLAs:

 

    • All cases must be responded to within 2 business hours
    • All Urgent priority cases must be responded to within 1 hour regardless of business hours
    • All cases must be responded to within the phone response time as stated on the contract
    • All cases must be closed within 5 days.
    • All subcases of type “Hardware Upgrade” must have a technician onsite within 36 hours.
    • All new cases for a Gold level customer must get a call back from a senior tech within 1 hour.
    • An initial response must occur within 8 business hours
    • etc.

 

A common use of RuleManager is to notify folks when a case is nearing or has passed its SLA. These notifications happen on an individual case basis. While this all works well, the influx of notifications can sometimes be overwhelming. In addition, there’s no overarching view of how the call center is doing.

 

The need

 

More and more, call center managers want to a dashboard view of what’s going on, which includes a real-time overview of how the call center is meeting their SLAs.

 

As I started thinking about how to accomplish this, a report seemed like the natural answer. For example:

 

    • Tell me how many open cases we currently have
    • How many of those are nearing their SLA threshold
    • How many of these have surpasses their SLA

 

Simple queries? Reports?

 

Overall, these are pretty simple queries to put together when your business model is simple.

 

For example, let’s say that the SLA we’re worried about is: All cases must be responded to within 2 hours.

 

So if a new case comes in at 4:00 PM, we need to respond by 6:00 PM.

 

So, the queries would look at the case creation_date, as well as the time the Initial Response occurred (if there was one), calculate the difference, and compare that to our 2 hour SLA. No problems yet. A little complex, but nothing that scares me. Until we have to think about business calendars.

 

Business Calendars dramatically increase the complexity

 

Now consider the scenario: All cases must be responded to within 2 business hours.

 

So, if a new case comes in at 4:00 PM on a Tuesday, and our support center hours are Monday-Friday 9-5, then our SLA says we must respond by 10:00 AM on Wednesday.

 

if a new case comes in at 4:30 PM on a Friday, and our support center hours are Monday-Friday 9-5, then our SLA says we must respond by 10:30 AM on the following Monday.

 

Good luck handling that in your reporting tool.

 

Even worse, what if the SLA says we will respond within 2 of the customer’s business hours? So, the hours for each customer are different.

 

My head hurts thinking about trying to do that in a report, and still have that report have decent performance.

 

A better solution: Let RuleManager do all the hard work

 

Let RuleManager figure out when cases hit certain SLA levels. RuleManager already is aware of business calendars, and knows how to figure out these complex scheduling scenarios. The plan is to have RuleManager update the case when it hits certain SLA levels.

 

By default, all cases will have a NULL SLA level. Then, if they’re getting near the defined SLA, I’ll set the level to 1. Finally, if they exceed the SLA, we’ll set the level to 2.

 

Here’s my implementation approach:

 

    1. Create a new SLA level column on the case table
    2. Create Business Rules that define your SLAs.
    3. The Business Rule Action will update that new custom column
    4. Execute a very simple query/report to total up cases based on their SLA level

1. Create a new SLA level column on the case table.

 

I use the Dovetail SchemaEditor, so a simple SchemaScript does the trick:

 

<schemaScript xmlns=”http://www.dovetailsoftware.com/2006/10/SchemaScript.xsd”>
<addColumn name=”x_sla_level” dataType=”Integer” table=”case” />
</schemaScript>

 

2. Create Business Rules that define your SLAs.

 

Using DovetailAdmin, I can create my business rules. Here’s the one I used for my testing:

 

Rule Name: Set Case Sla Level
Description: All new cases must be responded to within 4 business hours of the support center. At 3 hours, consider this a warning.
Object Type: Case
Start Event: Create
Stop Event: Initial Response
Conditions: None

 

Action 1:
Action Name: Set Case Level to 1
Create Activity Log Entry: True
Start Action: 3 hours from event creation using Sppt Bus Hrs
Message Type: Command Line
Message:  C:\work\fcsdk\SetCaseSlaLevel.bat [Database ID] 1

 

Action 2:
Action Name: Set Case Level to 2
Create Activity Log Entry: True
Start Action: 4 hours from event creation using Sppt Bus Hrs
Message Type: Command Line
Message:  C:\work\fcsdk\SetCaseSlaLevel.bat [Database ID] 2

3. The Business Rule Action will update that new custom column

 

I have a bat file that calls a JavaScript script, which uses the fcSDK to update the column.

 

SetCaseSlaLevel.bat simply calls cscript.exe and my custom JavaScript:

 

cd C:\work\fcsdk
cscript.exe C:\work\fcsdk\SetCaseSlaLevel.js “%1” “%2”

 

 

SetCaseSlaLevel.js updates the case:

 

var FCApp = WScript.CreateObject(‘FCFLCompat.FCApplication’);

 

var caseObjid = WScript.Arguments(0);
var slaLevel = WScript.Arguments(1);

 

FCApp.Initialize();
var FCSession=FCApp.CreateSession();
FCSession.LoginFromFCApp();

 

var caseRecord = FCSession.CreateGeneric();
caseRecord.DBObjectName = ‘case’;
caseRecord.AddForUpdate(caseObjid);
caseRecord(‘x_sla_level’) = slaLevel;
caseRecord.Update();

 

 

So, in simple terms, what will this business rule and script actually do?

 

If the case is not responded to within 3 Support Business Hours, then the SLA level of the case will be set to 1.
If the case is not responded to within 4 Support Business Hours, then the SLA level of the case will be set to 2.

 

4. Execute very simple queries to find cases based on their SLA level

 

The SQL now becomes simple and efficient:

 

Find the total number of open cases:

select count(*) from table_case where case_wip2wipbin is not null and x_sla_level is null

 

Find the number of cases with an SLA of 1 (nearing SLA):

select count(*) from table_case where case_wip2wipbin is not null and x_sla_level = 1

 

Find the number of cases with an SLA of 2 (SLA exceeded):

select count(*) from table_case where case_wip2wipbin is not null and x_sla_level = 2

 

Find the number of cases within the SLA (this can be calculated):

numberOfLevel0Cases = numberOfOpenCases – numberOfLevel1Cases – numberOfLevel2Cases;

 

 

 

Queries are great. But we don’t want our call center managers running queries, now do we? We can do better.

 

Some flashy goodness

 

Let’s display this data in a nice fashion. In my scenario, I’m using fcClient, and XML/SWF components, which are pretty easy to use. I use fcSDK to query for the data, and then generate XML for the component, which renders the output in Flash.

 

I’ve mapped the initial (null) SLA level to Green, level 1 to Yellow, and level 2 to Red. Pretty straightforward.

 

Here’s what it looks like in fcClient:

 

sla2

 

We also get activity logs (at no additional charge)

 

As an additional nicety, we can review the activity log for the case, and view exactly when SLA levels were reached.

 

Here’s the activity log from one of my test cases. Notice that for this test I set level 1 after 1 minute and level 2 after 2 minutes. I like a quick response!

 

act_log

 

Extensible

 

What I like about this approach is that its extensible. For example:

 

    • Any number of SLA levels can be used. I just used 3 (null, 1, 2), but you could use as many levels as you want.
    • Business Rules are very robust, so its easy to create any number of business rules that define your specific SLA requirements, starting and stopping on any events, using business calendars, and whatever static or dynamic SLA levels you want.
    • The same technique can be applied to Subcases, Change Requests, Part Requests, etc.
    • If multiple SLAs are needed per case (for example, cases must be responded to within 4 hours, and closed within 72 hours), then you can use different custom fields, or even add a new table in the schema if you have a lot.

 

Additional benefit: Historical analysis

 

Not only can you get a real-time view of the status of your open cases, but you can also do reporting on closed cases. Because we save the SLA level of the case, this allows you to report on how well you’re doing on hitting your SLAs over the past month, year, etc.

Next step: Drill down into cases

 

It’s great that we can see how many cases have hit Red status, and how many have hit Yellow status, so the obvious next step is to have the ability to drill down and see those cases. That will be the next step I work on. Check back later.

Enjoy

 

Hopefully this gives you some idea of what you can do when you start with a base of RuleManager, then add in a dollop of SchemaScript, a dash of fcSDK code, and a sprinkle of flashy goodness. Shake vigorously. Pour. Enjoy your real-time SLA monitoring.