Service-level agreement

A service-level agreement (SLA) is a contract between you and your customers that sets the expectations for your service level. SLAs help ensure that your customers receive timely responses and resolutions to inquiries.

Policy users can set SLA breach and warning targets for three metrics: first response, next response, and full resolution. Each metric has its own breach and warning target. You can specify whether the metrics are calculated using calendar hours or business hours while defining breach and warning targets.

Create an SLA

1. Go to Settings > SLA > + Create.

2. In the Create SLA window, provide a name and description of the SLA.

   After creating the SLA, assign policies to it.

Creating policies within SLA

Multiple policies can be created within an SLA. Each policy has a priority order, so if a ticket meets the conditions of two or more policies, the policy with the highest priority is applied.

To create a policy within an SLA, do the following:

1. Click + Policy.
2. Select either Ticket Policy or Conversation Policy.
3. In the New ticket policy pane, under Conditions, select the ticket attributes values of Tag, Part, and Severity.
4. Under Metrics, enable or disable First response, Next response, and Resolution time.
5. Click Publish.

SLA metrics are only applied to tickets or conversations that meet the policy's conditions.

Publishing an SLA

SLAs can be published once all policies are created. Published SLAs can't be edited. The user can't change the policies or priority order of a published SLA. The user can't change the policies or priority order of a published SLA.

Assigning customers

SLAs can only be assigned to customers once they're published. Once a service level agreement (SLA) is published, it can be assigned to customer accounts. If no customers are added, the SLA will not be applied to tickets or conversations.

Adding assignment rules

Users can't add or remove customers until the SLA is published. Each workspace has its own SLA, and a single customer can have multiple workspaces.

Adding assignment rules

Go to Assignment rules to add conditions for an account to be assigned a particular SLA.

1. Click + Create Rule.
2. In the New SLA assignment rule pane, select the account attributes and their values to check for.
3. Click Save and Apply.

Editing/Deleting an assignment rule

Once an assignment rule is created, you have the option to edit or delete it. Any changes made to assignment rules would only impact tickets where SLA is applied thereafter, there is no immediate impact on tickets where the SLA is currently running.

Adding exceptions to an SLA

1. Go to Exceptions to add customers who should always adhere to an SLA, regardless of the assignment rule.
2. Click + Customer.
3. Add all customer accounts/workspaces you want to assign the SLA.
4. Click Assign.

Setting an SLA as default will automatically assign it to all accounts without an existing SLA. This means that the assignment rules or exceptions for the default SLA are bypassed.

Dedicated assignment rules

This section within the SLA part lets you view the list of assignment rules created for all published SLAs. You can create/edit/delete assignment rules for any published SLA from this space and view the priority order for the application of assignment rules (to refer to when multiple SLAs are valid for the same account).

SLA metric calculation

SLA metrics are calculated based on the policy that's applied to the conversation or the ticket. There can be one or more SLA metrics active on a given conversation or a ticket, with each one being tracked separately.

SLA metric can be in one of the following stages:

• Active: The metric is currently being tracked on the conversation or ticket.
• Close to breach: The time spent by the SLA metric is greater than or equal to the close to breach target defined in the policy.
• Breached: The time spent by the SLA metric is greater than or equal to the breach target defined in the policy.
• Paused: The metric is currently paused based on some conditions. For example, when a ticket moves to awaiting customer response.
• Completed: The conversation or ticket has reached the completion condition.

Based on business hours defined for an organization, Active/Close to breach/Breached metrics can change schedules. Metrics move out of schedule when they remain at the same stage, but time spent out of schedule isn't included in the calculation.

If the customer account is updated after the ticket is created, all SLA metrics will be recalculated based on the updated customer account information. Any previous SLA breaches or achievements will be discarded, and new calculations will be applied according to the updated SLA.

The following table describes how each metric works for tickets and conversations:

Tickets

Conversations

Viewing SLAs

The SLA targets applied to a particular conversation can be viewed in the Inbox and the Conversation Detailed view. For a ticket in any of the ticket vistas.

When there are two active metrics, vista displays the one closest to the breach. In the case of a conversation where both the first response and full resolution metrics are active, and the first response is due in five minutes but the full resolution is due in one day, the vista displays five minutes. In the case where the first response isn't provided within five minutes, the timer displays negative values (such as -10m), which indicates that it's been 10 minutes since the first response was due. Conversations or tickets can also be grouped by SLA stages.

In the Detailed View, all metrics applied to the ticket or conversation can be viewed along with their current stage.

Filtering tickets by Next SLA Target

In order to filter tickets based on SLA, you can use the Next SLA Target filter. Here’s how the filter works:

• All: Filters all tickets that currently have an SLA applied to them. It will not filter tickets that had an SLA applied in the past and have been completed.

• Breached since:

  • Any: Filters all tickets that breached SLA, irrespective of when they were breached.
  • Over an hour: Filters all tickets that have been in breach for more than one hour.
  • Over a day: Filters all tickets that have been in breach for more than one day.
  • Custom: Filters all tickets that have been in breach from a given date.

• Will breach in:

  • Any: Filters all tickets that are currently not in breach.
  • Over an hour: Filters all tickets that have less than 1 hour left for breach.
  • Over a day: Filters all tickets that have less than 1 day left for breach.
  • Custom: Filters all tickets that will breach by the selected date.

Troubleshooting: No SLA running on the ticket

Issue

You have created and published an SLA, but no SLA is running on the ticket.

Solution

1. Check the SLA Name attribute:

   - Verify that the SLA Name attribute on the ticket is not empty.

   - If the SLA Name is empty, it means the customer account selected on the ticket is not assigned any SLA.

     - Action: Check your SLA assignment rules or add the customer as an exception to any of your SLAs.

The SLA Name is never empty if your organization has a default SLA.

2. Verify policy conditions:

   - If the SLA Name is populated but you still see no SLA metrics running on the ticket, the ticket does not satisfy the conditions of any policy within the SLA.

     - Action: Check the policies you have created for the SLA listed under SLA Name. For example, if you have created two policies, one with the condition Severity = Blocker and another with Severity = High, a ticket with medium severity will still have the SLA name but will not have any running metrics because it does not meet the severity conditions.

Next steps

If the issue persists, review your SLA assignment rules and policies or contact support for further assistance.

Expected result

The ticket should have an SLA running if the SLA Name is not empty and the ticket satisfies the conditions of any policy within the SLA.