Service Level Agreement (SLA) policies are agreed-upon ticket response, update, and resolution times from your support team to your customers. SLAs make work easier by quickly identifying tickets that need more immediate attention, and setting a timer on them.
However, things can get confusing when creating an SLA policy if you're not seeing it work as expected.
This tip contains the following scenarios for the most common SLA issues:
- New policy not being displayed
- SLA applied only to some tickets
- First Reply Time metric not working
- SLA not paused when ticket status is Pending
- Target hours showing incorrectly
- Newly applied SLA executes additional breach event
New policy not being displayed
A newly created SLA policy is not applied to existing tickets, or an updated SLA policy is not applied to tickets already using that SLA.
SLAs are based on ticket events. This means that in order for tickets to be matched to an SLA policy, something needs to happen to the ticket, like a ticket creation or update event; otherwise, the ticket shows no SLA information or keeps showing the old SLA information.
In this example, an SLA policy was not applied because either there wasn't an existing policy to apply the last time the ticket was updated, or the ticket didn't meet the policy's conditions:
In this example, an SLA policy is applied after an update to the ticket, after either a policy was created, or the ticket was updated to meet an existing policy's conditions:
SLA applied only to some tickets
An SLA is not applied to tickets that meet all of the SLA policy conditions.
This happens when tickets do not have a set Ticket Priority . Tickets must have a priority in order for the SLA policy to apply.
SLA policies can have different due times depending on the ticket priority:
However, if the ticket doesn't have a priority to match the time set in the SLA policy, the policy is not applied, and no timer is displayed, until a priority is added.
In this example, no SLA policy is applied because the ticket was created without a priority:
After the same ticket is updated to have a priority, the SLA policy is applied:
First Reply Time metric not working
A newly created ticket doesn't show a timer for the First Reply Time metric even though it meets all the criteria for the SLA policy.
This happens when a ticket is created by an agent on behalf of an end-user. The First Reply metric does not apply on tickets created by agents because the description, being a public comment, is considered to be the first reply.
In this case, there is no First Reply Time metric applied, because the ticket was created by an agent:
Here, however, the First Reply Time metric is applied because the ticket was created by an end-user:
Other metrics, like Agent Work Time, Requester Wait Time, Next Reply Time, and Periodic Update Time, will still apply and display if the ticket meets the SLA Policy criteria.
SLA not paused when ticket status is Pending
The SLA timer does not pause when the ticket status is changed to Pending.
This happens because the ticket is waiting for the First Reply Time or Next Reply Time metric to be fulfilled. Reply metrics do not change based on the ticket status; they can only be fulfilled if there is a public reply made from an agent to the requester.
First Reply Time and Next Reply Time always use an end-user comment as starting point and a public agent response as an end point. The following graphic shows how the First and Next Reply Time metrics fit within the lifecycle of a ticket.
Target hours showing incorrectly
Tickets with SLAs that have a target in business hours show a higher number of hours than what the SLA metrics should have set.
SLA time targets are always displayed in one unit of measurement: calendar hours. Although you can choose to calculate the target time in business hours the timer will still display time in calendar hours and will not take in consideration non-working days or holidays set in your account.
A longer explanation for this case can be found in Understanding the differences in SLA target hours .
Newly applied SLA executes additional breach eventCase:
When a new policy is applied to a ticket, even if it’s only a modified version of an existing policy, and the SLA target was already breached it makes another breach event recorded at the time of the update. For example, let's say that the current policy is breached on a ticket and the new policy added to the ticket on 20th April at 11:06 should have been breached on 15th April at 12:00. In this case, the SLA target counter will display not the actual time when the SLA should have been breached but the time when the new SLA was posted on the ticket, which is 20th April 11:06.
The system can’t modify past ticket events history from the technical point of view, that's why when a new SLA application happens, SLA counter always looking forward from that point.
For additional information about how SLAs work, check out Defining and using SLA policies .