Applying service level agreements

What should determine service levels on a ticket?

To settle on the best method for applying service level agreements to your tickets, your organization Your Autotask instance may be configured to use one of the following terms instead: Account, Business Unit, Client Company, Customer, Site. must first decide what will govern the service level on any given ticket. This decision will determine the best way to apply the right SLA to each ticket, and the automation options that are available to you.

With this approach, service levels are customer-specific or based on the organization classification. A workflow rule can apply the SLA to the ticket when it is saved, based on the ticket organization. Refer to Customer Classification.

EXAMPLE  The Standard SLA is assigned to most customers, the Premium SLA is assigned to Premium Customers.

With this approach, service levels are based on individual devices Your Autotask instance may be configured to use one of the following terms instead: Asset, Configuration Item, Installed Asset, Installed Product., the device type or the product category. A workflow rule can apply the SLA to the ticket when it is saved. Refer to Device Type / Product Category.

EXAMPLE  The Standard SLA is assigned to Workstations, the Premium SLA is assigned to Servers.

NOTE  This allows you to have one billing contract for a customer, but apply multiple SLAs to the devices under the contract in scenarios where the actual maintenance is carried out by the various vendors, all of whom offer different response times.

With this approach, service levels are tied to the ticket's issue and sub-issue types. A workflow rule can apply the SLA to the ticket when it is saved, based on Issue and Sub-Issue Type. Refer to Issue / Sub-Issue Type.

EXAMPLE  One SLA is configured with multiple objectives. Issue Type/Sub-issue Type: Hardware > Workstation has a slower response objective than Issue Type/Sub-issue Type: Hardware > Server.

How to...

Method Description
Manual Selection Directly select an SLA from the SLA field drop-down list on the ticket or recurring ticket template. The list will contain all active SLAs permitted by the ticket category.
Refer to Adding, copying, and editing tickets.
Form Template Select a ticket form template that defaults in an SLA. The list will contain all active form templates permitted by the ticket category. Applying a form template is the equivalent of a manual selection.
Refer to Adding and editing form templates.
Ticket Category Make one of your SLAs the default SLA for all tickets that use this category. Ticket categories also determine which active SLAs are available for tickets that use the category. Even manual selection only offers options from the list available through the ticket category.
Refer to The Details tab.
Contract After you populate the Organization field on the ticket, select a contract that defaults in an SLA.
Refer to Creating a contract.
Service/Bundle Optionally, you can select a specific service or service bundle on the ticket.
If the contract and the service or bundle are associated with different SLAs, the SLA on the service or bundle will override the one on the contract, since it is more granular. Refer to Setting up your services and Setting up service bundles.
Device You can associate an SLA with individual devices. This is the most granular method for applying an SLA, so the device's SLA will override any SLA defaulted in by the ticket category, or contract.
Refer to Adding and editing devices.
Workflow Rule Fires You can create ticket workflow rules to update the SLA field, based on a large number of events and conditions.
Refer to Adding, editing, and copying workflow rules.

It is possible that the ticket category, the form template, the contract, the service or service bundle, and the device all have different active SLAs.

IMPORTANT  The sequence of events is crucial! As you populate the fields that can default in an SLA, the content of the ticket Service Level Agreement field keeps changing to the last SLA defaulted in. It also matters if the SLA field is displayed or not.

NOTE  BEST PRACTICE: Your company should decide on one principal criterion for assigning an SLA to a ticket. This will avoid any conflicts or unexpected outcomes associated with an "All of the Above" approach. Refer to Configure Autotask to apply SLAs automatically.

Here are various scenarios that illustrate the SLA selection rules when tickets are created:

  1. If the selected ticket category has a default value for SLA, it will be applied.
  2. If the user then selects a form template that has a default value for SLA, it will override the ticket category SLA.
  3. If the user then selects a contract that has a default value for SLA, it will override the form template SLA.
  4. If the user then selects a service or service bundle that is associated with a different SLA, it will override the contract SLA.
  5. If the user then selects a device that has a default value for SLA, it will override the contract SLA.
  6. If the user changes the ticket category or the contract again, their default SLAs will not override the configuration SLA.
  7. Only if the user selects a form template that has a different default value for SLA, or manually selects a different ticket SLA will it override the device SLA.

In this scenario, there is no way to manually update the SLA field, and form templates do not populate hidden fields.

  1. If the ticket is associated with a device that has an active SLA, it will be applied.
  2. If there is no active device SLA, but the ticket contract is a recurring contract with a service/bundle that has an SLA, the service/bundle SLA is applied.
  3. If there is no active service/bundle SLA, but the ticket contract is associated with an SLA, the contract SLA is applied.
  4. If there is no active contract SLA, but the ticket category has a default SLA, it is applied.
  5. Otherwise, the ticket SLA field is left blank.

The following flowcharts show which SLA is applied when various fields are edited and the SLA field is hidden.

Legend:

  • CI - Device
  • DSDC - Default Service Desk Contract

Device is changed

Contract is changed

Contract service or bundle is changed

Organization is changed

If you use a form template that defaults in an SLA, but also defaults in a contract or a device that have a default SLA configured, the SLAs will be applied in the following order of precedence:

  1. The SLA on the form template
  2. The SLA on the device
  3. The SLA on the contract

When a ticket is created through the Client Portal, the Web Services API, Incoming Email Processing and ATES, Managed Services Extensions, Quick Calls, or the Won Opportunity Wizard, Autotask steps through a series of checks to determine which SLA to use.

  1. If the ticket references a device (Client Portal, Quick Call, Web Services API) and the device has an SLA applied, the ticket SLA defaults to the device SLA.
  2. If the ticket does not have a device assigned, Autotask checks to see if a contract is applied to the ticket. If the ticket has an assigned contract (Client Portal, Quick Call, Web Services API) and the contract has an SLA applied, the ticket SLA defaults to the contract SLA. If a service or service bundle is specified that has a different SLA from the contract, the service or bundle SLA will prevail.
  3. If the ticket does not have a contract assigned, Autotask checks to see if the company has a default Contract. If the organization has a default contract and the contract has an SLA applied, the ticket SLA defaults to the SLA for that contract.
  4. If the organization has no default contract, Autotask checks to see if the organization has a parent organization Your Autotask instance may be configured to use one of the following terms instead: Headquarters, Parent Account, Parent Client, Parent Company, Parent Customer. with a default contract. If it does, and that contract is associated with an SLA, the ticket SLA defaults to the parent organization's default contract SLA.
  5. If there is no contract SLA, but a ticket category is passed in that is associated with an SLA, that SLA is applied.
  6. If there is no contract SLA and no default SLA has been selected, no SLA is applied to the ticket.

IMPORTANT  When you save the ticket, it is evaluated by the workflow rule engine. Ticket workflow rules can ignore any ticket category settings and assign an SLA to the ticket that isn't an available option on the ticket itself.

The best way to apply SLAs is to automate SLA selection as much as possible. If you have a clear strategy for setting service levels on tickets (refer to What should determine service levels on a ticket?), you can configure Autotask to automate this process.

This table makes recommendations for configuration of all areas that can apply an SLA to a ticket.

If the SLA is determined by... CONFIGURATION OF DEFAULT SETTINGS FOR SLA
Ticket Category Form Template Contract Device Workflow Rule
Device Make all SLAs available on all ticket categories, and do not select a default SLA. No No Use Import / Update to assign SLAs to individual devices. No
Device Type / Product Category Setting a default SLA on the ticket category can be used for tickets without a device.
Make all SLAs available on all ticket categories.		 Create ticket form templates based on the Device Type. They will override the ticket category default. If service levels are not the same for all customers: Setting a default SLA on the contract can be used for tickets without a device. No

Recommended:
Set up either Product Categories or Device Types so they serve as criteria for applying SLAs. Then create a workflow rule similar to this one:

  • Event (trigger): Entity “Ticket” Created / Edited
  • Conditions: Device Type (or Product Category) equal to "Hardware:Server"
  • Updates: Set Service Level Agreement As "IT:Premium SLA".
Issue / Sub-Issue Type If service levels are the same for all customers:
Create an SLA with objectives based on Issue and Sub-Issue Types. Make this SLA the default on all ticket categories.		 No If service levels are not the same for all customers (Option 1):
Use organization default contracts to pick the SLA for the customer.		 No If service levels are not the same for all customers (Option 2): Create several SLAs and use workflow rules to assign them to tickets, based on customer names or organization classifications.
Customer-specific Make all SLAs available on all ticket categories, and do not select a default SLA. If form templates are designed to create tickets for specific customers, form templates can be used as an alternative to workflow rules. Default contract at the organization or parent organization level, or specific contracts associated with individual tickets or devices, or both. No

Recommended:

  • Event (trigger): Entity “Ticket” Created / Edited
  • Conditions: Organization Name is In list: Organization A, Organization B
  • Updates: Set Service Level Agreement As "IT:Premium SLA".
Customer Classification Make all SLAs available on all ticket categories, and do not select a default SLA. If form templates are designed to create tickets based on organization classifications, form templates can be used as an alternative to workflow rules. No No

Recommended:

  • Event (trigger): Entity “Ticket” Created / Edited
  • Conditions: Organization Classification equal to "Premium"
  • Updates: Set Service Level Agreement As "IT:Premium SLA".

Since service levels are a yardstick that you measure your team's actual performance against, one could argue that there is never a need to change the SLA on a ticket. This is especially true when you have completely automated SLA application.

If you would like to prevent all or some users from changing the SLA on the ticket, simply hide the SLA field on all ticket categories.