Managing Service Level Agreements (SLAs) in RT

What's an SLA?

The Service Level Agreement (SLA) is often a critical component of customer relationships -- and commonly very complex. For those who may not have worked with SLAs yet, they are an agreement between a service provider and their customer that specifies required aspects of the service. For example, an SLA may define the maximum time allotted for a service provider's resolution of customer issues. RT makes all this accounting automatic and easy.

Managing SLAs is a business-critical task, because they are typically tied directly to the business' income. A missed deadline can incur financial penalties, leaving no room for sloppy tracking.

Without good tools like RT, the task of managing SLAs falls on a person--or a team--to do by hand. It's a huge amount of work to track, and any manual process is prone to error. When SLAs hit the bottom line, you want accuracy and automation.

SLA Management in RT

RT offers SLA management as a core feature (since version 4.4 - and it's available as an extension for 4.0 and 4.2). Once you've configured the system to match your contract requirements, due dates on tickets are automatically handled for you according to the rules.

The due date, depending on your configuration, is more than simply set for you on the ticket. It becomes dynamic, and RT can change the due date automatically to follow the flow of conversation between you and your customers. Each interaction on the ticket can change the due date to fully manage expectations on both sides. For example, after a customer creates a ticket with a question, there is a time allowed for the initial response, and separately for the ultimate resolution. Writing back to the customer with a request for clarification might stop the clock until the customer replies. When their reply comes in, the clock starts again, and the due date is reset as configured. All of this happens while accounting for your business hours, holidays, and more.

The Value of Automated SLA

Having due dates managed by SLA automatically is great by itself, but RT's business value really shines when you use SLA management as a foundation for further customizations of RT. Once your dates are automated, and therefore reliable, you can create saved searches based on the due date. Use those to build custom dashboards, and set up your RT at a Glance page to keep the tightest deadlines at the top of your list. Script the system to send you alerts when time runs short. This way, RT helps you stick to your SLA commitments, letting nothing slip through the cracks. You can even use this as a foundation for reporting and compliance.

Example Configuration Walkthrough

Let's see a basic example. Our intrepid service provider, ACME Industries, has a service level agreement with their customer, BigCo Incorporated. For day-to-day requests, BigCo expects ACME to resolve issues within five business days, and during normal working hours. ACME will file these in a queue named "BigCo - Standard". But BigCo also has some important systems managed by ACME. If they go down, BigCo must have a response from ACME within 30 minutes, so they know that ACME is hard at work fixing the issue. They also need any emergency issues fully fixed within 2 hours - every day, no matter what time it is.

Now we'll build the RT configuration ACME needs for this. We'll start out by defining the two SLA levels we need, using the `%ServiceAgreements` config option. First, the emergency level:

Set( %ServiceAgreements,(
    Levels => {
        '24/7 Emergency' => {
            Response => { RealMinutes => 30 },
            Resolve => { RealMinutes => 60*2 },
        },
    },
));

We named the level "24/7 Emergency" -- you can name it whatever you like. The "Response" key defines the amount of time between a ticket being created by a customer request, and the initial reply to that request. "Resolve" sets the time allowed between the ticket's creation and the final resolution.

Now, let's add the other entry, for standard five-day support:

Set( %ServiceAgreements, (
    Levels => {
        '5 Business Days' => {
            Resolve => { BusinessMinutes => 60*8*5 },
            BusinessHours => 'ACME Hours',
        },
        '24/7 Emergency' => {
            Response => { RealMinutes => 30 },
            Resolve => { RealMinutes => 60*2 },
        },
    }
));

Notice that we specify the time in minutes, and using an expression: sixty minutes * eight hours * five days. This makes it easy to see what's going on, but the notation isn't required. In this case, each business day has ACME open for eight hours, and they work Monday through Friday. We also need to define the hours that the "BusinessHours" key specifies, called "ACME Hours". Let's define those hours in the "%ServiceBusinessHours" config option:

Set( %ServiceBusinessHours, (
    'ACME Hours' => {
        1 => { Name => 'Monday', Start => '09:00', End => '17:00' },
        2 => { Name => 'Tuesday', Start => '09:00', End => '17:00' },
        3 => { Name => 'Wednesday', Start => '09:00', End => '17:00' },
        4 => { Name => 'Thursday', Start => '09:00', End => '17:00' },
        5 => { Name => 'Friday', Start => '09:00', End => '17:00' },
    },
));

With that done, we need to apply our SLA rules to Queues in RT. This can be done through the web admin interface, and defaults can be set in the config. Here we set the defaults in the "%ServiceAgreements" option with the "QueueDefault" key:

Set( %ServiceAgreements, (
    Levels => {
        '5 Business Days' => {
            Resolve => { BusinessMinutes => 60*8*5 },
            BusinessHours => 'ACME Hours',
        },
        '24/7 Emergency' => {
            Response => { RealMinutes => 30 },
            Resolve => { RealMinutes => 60*2 },
        },
    },
    QueueDefault => {
        'BigCo - Standard' => '5 Business Days',
        'BigCo - Emergency' => '24/7 Emergency',
    },
));

This applies the correct SLA to each of our two queues, which we assume already exist in RT and are called "BigCo - Standard" and "BigCo - Emergency". This could just as easily be tiered support, like bronze, silver, and gold, or anything else that fits your business model.

Are There More Options?

Yes! RT is inherently configurable. Anyone who's worked with SLAs knows how complex they can become. Clock time is not the same as business hours and service desk hours. Response is different than resolution. Questions to the customer sometimes need to pause the count of time against SLA deadlines, until the answer arrives. Ongoing dialogs must be managed. Do holidays count? Which ones? All these things happen under contract, and can be completely unique across customers.

As an RT user, you're in luck! In the discussion above, we looked at a basic SLA setup just to illustrate how it works. But you can go very deep with all the features RT's SLA support has built-in. And if you need even more, we'll build on that foundation to custom-tailor a solution for you.

We're sure by now you agree that RT's SLA features can make managing your customer requests simple. Give them a try, and let us know how much it helps you out!