Introduction to service level management

SECURITY  If your company uses service level management, all resources who create, manage, or work on tickets will work with service level agreements and should review this topic.
Administrators who create and manage service level agreements should review this topic and Managing service level agreements.

A service level is a performance standard that defines the time frame in which an issue will be resolved based on its severity and impact.

A service level agreement (SLA) is a minimum set of service levels, that is, performance standards, that your company defines to meet the service needs of one or more customers. You can have one SLA that you apply to all customers, or multiple SLAs to meet different customer needs or different price points.

EXAMPLE  You are negotiating with a new customer, a law firm. This firm stores all their current and historic documents on one file server that all employees with the correct security permissions can access.
If employees cannot access this server, all business activity is suspended. When this happens, it is a business-critical issue for them, because they are often subject to legal deadlines.
With a service level agreement, you can assure them of your service level goals:
• For business-critical service, someone will begin to address the problem in 15 minutes; you will update them within three hours on how you will fix the problem; the issue will be resolved within 8 hours. This standard applies 24/7/365.
• For service needs that are critical but will not immobilize the organization Your Autotask instance may be configured to use one of the following terms instead: Account, Business Unit, Client Company, Customer, Site., someone will respond within 2 hours and the problem will be resolved within 16 extended business hours.
• For routine support and maintenance service that does not rise to this level of emergency (when a printer fails, for example) someone will respond and schedule the required service during regular business hours.

The different goals in this example can all be defined in a single SLA. This is done by creating multiple "objectives."

Autotask defines four key stages in the service process as SLA events: First Response, Resolution Plan, Waiting Customer, and Resolved. Before you begin using SLAs in Autotask, an administrator maps these events to one or more ticket statuses.

When you create a ticket associated with an SLA, an SLA stop watch starts to run. As work is done on the ticket, the ticket status changes. When it changes to a status that is mapped to an SLA event, Autotask records the time and event type so you can keep track of how long it takes to reach each SLA event.

NOTE   If the status is mapped to the Waiting Customer event, the stop watch pauses and resumes at the next status change.

Refer to Task & ticket statuses and Mapping ticket statuses to SLA events.

SLA events that can be mapped

SLA Event	Description	SLA Clock	Event Recorded
First Response	Measures time elapsed between the time ticket creation and first response (often an acknowledgment that the ticket has been received) to the customer.	Running	SLA First Response Date/Time
Resolution Plan	Measures time elapsed between ticket creation and a resolution plan.	Running	SLA Resolution Plan Date/Time
Waiting Customer	Pauses the clock while you are awaiting action or information from a customer.	Paused	Nothing is recorded
Resolved	Measures time elapsed between ticket creation and resolution.	Stopped	SLA Resolved Date/Time

Actions that record SLA events

Action	Description of SLA event time
Create/edit a ticket and change the status	The SLA event time will be the create/edit date/time of the ticket.
Enter a note on a ticket and change the status	The SLA event time will be the date/time of the status change.
Enter time on a ticket and change the status	The SLA event time will be the date/time of the time entry (this allows you to retroactively trigger an SLA event, for instance, if you forgot to update a ticket for work performed the previous day). For First Response events, the SLA event date/time will be the start date/time of the time entry. For Resolution Plan and Resolved SLA events, the SLA event date/time will be the end date/time of the time entry.
Forward/Modify a ticket and change the status	The SLA will be the date/time that the ticket is forwarded and the status changed.
A Workflow Rule changes the status	The SLA event will be the date/time when a workflow rule that updates the ticket status fires.

NOTE  If an SLA event is recorded and no prior events have been recorded, those events will automatically inherit the date/time of recorded event.
For example, if there is no Resolution Plan event for a ticket and you resolve the issue on 4/1 at 3:00 PM, the Resolution Plan event will also be set at 4/1 at 3:00 PM.

NOTE  When the first status change recorded on a ticket occurs and the new status is mapped to an SLA Event other than the First Response event (that is, Resolution Plan, Waiting for Customer, or Resolved), or, the ticket status is set to Complete before a First Response event is recorded, the First Response event is automatically recorded and it inherits the date/time of the first recorded event. The Resource associated with the recorded event is set as the First Response Initiating Resource.

One SLA can manage more than one goal. This is because it can contain several objectives that allow you to differentiate how different scenarios will be treated.

An SLA objective defines:

• The combination of conditions (Priority, Ticket Type, Ticket Category, Issue Type, Sub-Issue Type) it applies to
• The number of hours before each SLA event (First Response, Resolution Plan and Resolved) becomes due
• The timeframe (Business Hours, Extended Hours or All (24x7)) for when the SLA clock is running

NOTE  A specific combination of Priority, Ticket Type, Ticket Category, Issue Type, and Sub-issue Type can only be associated with one objective.

The objective must be a 100% match to the ticket. However, a ticket can be a match for more than one objective, as shown by the example below.

EXAMPLE  In this SLA example, a ticket with Critical priority, an issue type of IT:Hardware, and a sub-issue type of Server matches both Critical objectives, but it is a more specific match for the first objective.

When assigning the objective, tickets are evaluated against the condition fields in left to right order:

• First, Priority is evaluated. If multiple Priority matches are found, then the Ticket Type, Ticket Category, Issue Type and Sub-Issue Type are taken into account, in that order.
• Ticket Type and Ticket Category are set to [All], so the tie breaker becomes the Issue Type: it matches the first objective.
• The Sub-Issue Type is also a specific match, so the first objective is confirmed.

NOTE  When reporting the amount of time it takes to reach the objective, the start time of the initiating event is rounded to the end of the first recorded minute and the clock starts counting at the beginning of the next minute. For example, if a ticket is created at 9:59 AM and the first response occurs at 10:15 AM, the First Response time is counted from 10:00 AM to 10:15 AM and will be reported as .25 hours.

To learn more about how SLAs use timeframes, refer to Establishing business hours for service level agreements.

Your SLA goals are defined as the percentage of times your company expects to meet the SLA objective.

EXAMPLE  An objective states that you will respond to a specific type of ticket within 4 hours (i.e., meet the First Response SLA Event within 4 hours). You set the First Response goal to 90%, that is, you expect to respond to this type of ticket within 4 hours 90% of the time. You will meet this goal even if you miss the first response objective in one out of ten cases.

This information is reported in the SLA Performance by SLA report. Refer to Reports on ticket metrics and SLA performance.

To use SLAs to record the time required to meet service level objectives and to monitor your success in meeting service level goals, you must apply SLAs to tickets. There are a variety of ways to make sure that the right SLA is associated with each ticket; you can apply them to tickets manually when you create or edit the ticket, or automatically through default settings, contracts, and workflow rules. Refer to Applying service level agreements.

When working with a ticket associated with an SLA, there are a number of best practices to follow so you don't miss your SLA Objectives and Goals. Refer to Managing tickets under service level agreements.

We recommend that you use Workflow Rules to automatically notify resources of upcoming SLA events. Refer to Autotask workflow rules.

The Ticket History page is the best place to review SLA data for a specific ticket. Users with Administrator or Manager security level can retroactively edit SLA dates.

Refer to The Service Level Agreement tab.