How can I troubleshoot common SLA issues?
This article covers:
- The new policy not being displayed
- SLA applied only to some tickets
- First reply time metric not working
- SLA is not paused when ticket status is pending
- Target hours showing incorrectly
- Newly applied SLA executes additional breach event
- Why don't I see an SLA badge when there's an SLA policy on the ticket?
- Updates to schedules don’t reflect in SLA Targets
New policy not being displayed
Zendesk isn't applying a newly created SLA policy to existing tickets, or Zendesk isn't applying an updated SLA policy to tickets already using that SLA.
SLAs are based on ticket events. For an SLA policy to match tickets, an event such as ticket creation or ticket update must happen on the ticket. Otherwise, the ticket shows no SLA information or keeps showing the old SLA information.
In the example below, an SLA policy wasn't 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 the example below, 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 isn't applied to tickets that meet all of the SLA policy conditions.
This happens when tickets don't have a set ticket priority. Tickets must have a priority for the SLA target to apply. The ticket priority must be the system default field. SLAs don't apply using custom ticket fields.
SLA policies can have different target times depending on the ticket priority:
If the ticket doesn't have a priority to match the target time set in the SLA policy, the target time isn't applied and no timer is displayed until a priority is added.
In the example below, Zendesk didn't apply an SLA policy because the ticket was created without a priority.
After the same ticket is updated to have a priority, Zendesk applies the SLA policy.
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 and the first comment is public. The first reply target is fulfilled at the ticket creation because the first public comment is submitted by the agent, which is considered to be the first reply.
In the example below, there is no first reply time metric applied, because the ticket was created by an agent.
SLA is not paused when the 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 your agents to fulfill the first reply time or the next reply time metric. Reply metrics don't change based on ticket status. They can only be fulfilled if there is a public reply made by an agent to the requester.
The first reply time and the next reply time always use an end-user comment as the starting point and a public agent response as an endpoint. For more information, see the article: Defining and using SLA policies.
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 won't take into consideration non-working days or holidays set in your account.
For a detailed explanation, see this article: Why do I see differences in SLA target hours?
Newly applied SLA executes additional breach event
When Zendesk applies a new policy to a ticket that already had the SLA breached, even if it’s only a modified version of an existing policy, the system records another breach event at the time of the update.
The example below has a ticket in which the current policy is breached. The new policy that was added to the ticket on 20th April at 11:06 should have breached on 15th April at 12:00. In this case, the SLA target counter displays not the actual time when the SLA should have 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 a technical point of view. When a new SLA application happens, the SLA counter always looks forward from that point.
Why don't I see an SLA badge when there's an SLA policy on the ticket?
There are several reasons why an SLA badge won't appear on a ticket with an SLA policy applied. For more information, see the article: Why aren't SLA badges appearing?
Updates to schedules don’t reflect in SLA Targets
Zendesk doesn’t reassess SLA targets if a schedule's hours or holidays change after this schedule is applied to a ticket. Even if the ticket and its other SLA targets are updated. Public comments won't make solve targets reassess, and status changes only make a solve target reassess if that target is paused or fulfilled.