Documentation forSolarWinds Service Desk

Service level management

On this page

Introduction

In SolarWinds Service Desk (SWSD) you define service targets using SWSD's Service Level Management feature. By establishing service level agreements (SLAs), you can monitor, alert, and report on missed SLA targets.

Navigation

ITSM customers ESM customers
Setup > Service Desk > Service Level Management

Service Provider > Service Desk > Service Level Management

Create a new SLA

SolarWinds recommends that before you begin creating a new SLA, make sure you understand how SWSD calculates SLAs. See How SLA hours are calculated for more information.
Enterprise Service Management (ESM) service providers can create their own service-provider specific SLAs.

  1. From the All SLAs index page, click Add in the upper right.

  2. In the Add New Rule dialog, define your new SLA rule by completing the fields as described in SLA rule fields below. Notice that when you being creating the new rule the toggle in the upper right is set to Active. You can change the toggle to Inactive and activate it later.

  3. After configuring all the SLA rule fields, click Create.

Activate or inactivate an SLA

You can toggle an SLA on or off.

  • When an SLA is toggled to off:
    • The SLA does not apply to new open incidents.
    • Active clocks set on an incident for the SLA are terminated.
    • You can still report on the SLA in Analytics.
    • The SLA rules are flagged as disabled in the filter in Analytics.
  • When an SLA is toggled on:
    • The SLA applies to all new incidents from that time forward.
    • The SLA does not go back retroactively to incidents that are already open or closed.

To activate / inactivate an SLA:

  1. Navigate to Setup > Service Desk > Service Level Management.

  2. Scroll to the right and in the Actions column, click the toggle button.

    When you inactivate an SLA, you are prompted with the following message to confirm you want to disable the rule: This action will disable the SLA, which will exclude it from new incidents and terminate active clocks.

Delete an SLA

SolarWinds recommends that you not delete any SLAs. Instead, toggle them on or off.

If you attempt to delete an SLA, SWSD will prompt you with the following:

This action will permanently delete the SLA which will exclude it from all reports and new incidents, and terminate active clocks.

Deleting SLAs results in the loss of historical data.

SLA rule fields

Name*

The name field is a label. Create a name that indicates the service level for internal service providers. To help with reporting, ensure the name is unique from other SLA names. You might want to create an SLA for the expectation that tickets are assigned to agents within a specified amount of time. So you could name the SLA to match the target.

Define Target

The target is the metric, action, or activity you are measuring against. Define the operation you expect your service agents to perform within an allotted period of time. In the image below the target is Not assigned, and you can set your own expected time, for example, within 30 minutes. In this instance, the breach would occur if the ticket were not assigned within 30 minutes of creation.

The targets include:

  • Not assigned
  • Not commented
  • Not resolved
  • No actions taken*
  • No state change 

* The following criteria is considered an action taken on an incident:

  • An update was made to any field on the ticket
  • Any task in any state exists on the ticket
  • An automation rule ran its actions on the incident

Use Business Hours

In addition to defining a target, you can set the SLA to follow your organization’s business hours, that is, the hours your organization provides support. For example, do you have a set of business hours that are used for the entire organization, or do you have different hours for each site? Are your business hours set to specific hours of the day or do they include the whole day? See Business hours for more information.

Suspend SLA time for all states to which SLA does not apply

You can also elect to suspend the SLA timer during certain states of inactivity. For example, if an incident is in the Awaiting Customer Input state, you may not want that incident to breach the SLA.

See Incident lifecycle from creation to resolution or close for a list of out-of-the-box states. See also Custom states.

Set Timer Indication Threshold

In an SLA, you can configure the Set Timer Indication Threshold settings to warn you before an upcoming breach. The Initial Pre-Breach Indication setting ensures you have sufficient time to address the incident prior to a breach. The Final Pre-Breach Indication setting reflects when the breach will occur (based on the site or account).

The final pre-breach indication cannot use a measure of time larger than the initial pre-breach indication. If that occurs, the data entry field changes to red.

For the example we used earlier on creating an SLA for Not assigned, you might set the initial pre-breach indicator for 15 minutes, and the final pre-breach indicator to 5 minutes. SWSD

When you set timer indication thresholds, you will see visual indicators in SWSD in the table view when you are looking at a list of tickets. You will also see an indicator when viewing the details of an incident or service request. For the Not assigned example above, 15 minutes before breach the color changes to yellow, and 5 minutes before breach it changes to red.

Consider the following before you configure

Certain factors can influence the outcomes of alerts and reports. For example, the time zone of the incident and the business/work hours.

Alerts may not work as you want them to if you apply business hours to a rule and then try to combine days and hours as your trigger thresholds.

For example:

  • If your organization set business hours to a 12-hr workday, and you configure an SLA rule to use business hours and set your timer indication threshold to trigger within 13 hours, the alert will not trigger until the next business day.

  • If your organization set business hours to a n 8-hr workday, and you want technicians to comment within 24 consecutive hours, consider that 24 hours = 3 business days, so don't use days as the unit of measure.

Configure

Configure both indicators to warn you based on the appropriate unit of measure prior to the breach. See Consider before you configure.

  1. Click the on/off toggle to On.

  2. For each type of indication your organization decides to use, decide whether to use business hours and/or suspend the SLA timer for all states to with the SLA does not apply.

    If you choose to use business hours, SWSD will look at the business hours for the site of the incident (or default business hours if there are no business hours for the site) and apply that to the SLA rule when generating alerts and reports.

    • If your organization's business hours are configured to use a whole day, use days as your unit of measure in SLA rules.

    • If your organization's business hours are configured to use hours, use hours as your unit of measure in SLA rules.

  3. Click the dropdown menus and select minutes, hours, or days.

  4. Enter the number of minutes, hours, or days.

Examples of factors that can influence report outcomes

Case 1: Sites with different business hours

Incident A within site 123 has an SLA with regular business hours set to Mon-Fri 8:00-17:00. Incident B within site 456 has an SLA with no defined business hours, or it has all-day marked for all days. If both breach at about one day, Incident A will show nine hours, and Incident B will show 24 hours.

A very small change in breach time can cause the sort to be 24h (for B) and 9h (for A).

The sort is still accurate, but it is important to take these details into account.

The sort is still accurate, but it is important to take these details into account.

Case 2: Incidents with different time zones

Incident A is within a site using a USA time zone. The breach will be reflected in the beginning of the next work day. Incident B has no selected site. It will use Jerusalem (the default account time zone) and breach in three hours.

If it is 9AM in Israel, the sort will be B, A because B will breach first. But the display will be out of order--for example, B (3h) and A (0m).

This sort is accurate. Take time to understand these cases to determine how to best proceed in resolving incidents and avoid SLA breaches.

Define Scope

Here you define whether the SLA applies to all, incidents only, or service requests only. You can also define the category and subcategory.

After you determine the target, configure your SLA rules by refining specific filters. This helps you provide varying service levels as they pertain to different internal service providers and priorities.

You can scope the filters to the following options:

  • Incident / Service Request
  • Category
  • Priority
  • Site
  • Department
  • Requester
Create an SLA rule once and define the category and subcategory by using a multi-picklist. This allows you to apply the same rule to multiple category/subcategory combinations.

Set Action

An action defines what you want to happen if the SLA breaches. It can define the priority and assignee, allowing you to send a notification to a specific user prior to an SLA breach. For example, you can click the dropdown menu and select the option to include a notification to the assignee's manager and the manager's manager.

Setting an action helps you define automatic actions to deploy if the target is breached.

You can define one or multiple actions, which include:

  • Change priority
    • +1 (bumps the priority up one level)
    • Low
    • High
    • Critical
  • Re-assign incident (often used to escalate a ticket or reassign to another team)
  • Send notification to (notify someone that the SLA has breached, for example, the assignee's manager, the manager's manager, or perhaps a group responsible for SLAs)
  • Add Tags (adding tags can help with reporting, especially regarding tickets that have breached under the current rule)

How SLA hours are calculated

The examples below can help you understand how SLA hours are calculated to meet your company goals.

  • The SLA timer starts at incident creation.

  • The SLA work day is measured by average business hours. Each organization sets their own business hours.

    • If you provide support three days a week at 8 hours/day and two days a week at 6 hours/day, an SLA measured by business hours equals 7.2 hours/day.

    • If your business hours are set to 7 am - 5 pm Sunday through Friday, the average business day is 10 hours and excludes weekends. If a ticket is created at 9:30 am on Friday, October 8, with an SLA of one business day, the ticket will not breach until 9:30 am on Monday, October 11. That's because October 9 and 10 fall on Saturday and Sunday, and they are not business days.

The time zone for SLA compliance is set by the incident site. If there is no site, SWSD looks at the organization's default time zone. See Organization & sites for more information.

Updated and/or newly created incidents do not automatically get updated with a newly defined SLA. That is, as you define new SLAs, they will only be relevant to incidents created after the SLA is defined.

All SLAs index page

After you create the SLAs for your organization, you can view them in the All SLAs Index page. You can also customize your view.

Default view options

Default view options include:

  • Edit
  • Rename
  • Share
  • Save Changes
  • Save as New
  • Set as Default
  • Delete View

Customize view

Views in SWSD are fully customizable. See List view for more information.

  1. Click Edit View under All SLAs in the upper left.

  2. In the Edit View pane on the left, select the edit type from the tabs.

    • Filter tab. You can select an attribute and provide a value to filter by. You can also add more attributes. Filtering options include:
      • All SLAs (Default)
      • No actions taken
      • Not assigned
      • Not Incident index
      • Not resolved
    • Columns tab. Select the columns to include in your view. Column options include:
      • Name
      • Target
      • Scope
      • Action
      • Pre-Breach Thresholds
    • Sorting tab. Select a field to sort by and the sorting direction for that field.

SLA breaches

Breaches display on the All Open Incidents index page.

The SLA Breaches and Next Breach columns show color-coded timers for each incident.

  • Green Timer. Reflects an incident that has not met the pre-breach criteria.

  • Orange Timer. Reflects an incident that is past the initial pre-breach indicator, but has not reached the final pre-breach indicator. 

  • Red Timer. Reflects an incident that risks breaching the pre-determined SLAs.

If you have set multiple breach times, the Next Breach timer reflects 1 upcoming breach. You can click it to see more details with up to 3 upcoming breaches.

By setting the thresholds as described above, the indicators keep your teams better informed prior to any breach of SLAs. They also provide ample time to perform the necessary actions to resolve any issues and prevent a breach. Using the Incident Index page, agents can sort their queues based on which tickets will breach next. This helps them prioritize the tickets and reduce breached incidents, ensuring that your VIP cases receive your services within the agreed-upon time frames.

Multiple thresholds

You can set different thresholds based on the importance of the specific SLA. For example, you might need two similar Not Resolved SLAs: One for VIP users, the other for the general public.

In both cases, the SLA will be breached after three days. For the VIP case, you have included an additional trigger to escalate to the IT manager. As a result, in the VIP SLA, you can set the initial threshold indicator to alert at two days prior to breach and the final threshold indicator to one day. For the general public SLA, you can set it with the initial indicator threshold at one day and the final indicator threshold at five hours prior to breach. 

Unexpected breach after recategorizing incident

Recategorizing an incident does not restart the timer, therefore, the breach date/time will not change. For example, an incident using the hardware category is saved during morning business hours on Monday. The breach is scheduled to occur three business days later on Thursday morning. During business hours on Tuesday the category is updated to software. After the update, the breach will still occur on Thursday morning because the timer starts when the incident is created and does not change when it is updated. This applies to any SLA where a change to the incident affects the SLA.

Send a pre-breach notification

The pre-breach indicator does not currently send a notification. As a workaround, consider creating an automation rule. See Automation rules for more information.

Be aware: Business hours do not apply to automation rules. A pre-breach notification configured with automation rules may not meet your organization's needs. SolarWinds recommends you test thoroughly.

SLA example

See SLA examples for some broad examples of SLA setups.

Related topics