If you're experiencing service level agreement (SLA) issues, use this guide to find solutions to the most common behaviors.

This article contains the topics below:

  • The badge shows Now after the target is breached
  • Breached targets do not take business hours into consideration
  • The new policy does not display
  • 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

For general information about the functioning of SLA, see this article: Viewing and understanding SLA targets.

The badge shows Now after the target is breached

The badge will display Now when the target changes after a breach. These changes can include public comments, status changes, priority changes, or policy changes.

Breached targets do not take business hours into consideration

Even if the target was set up on business hours, the badge will always show the time in calendar hours. It does not matter if your target is in business or calendar hours.

The new policy does not display

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.

Explanation

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.

SLA not applied because SLA was updated after the ticket was created

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 after ticket update

SLA applied only to some tickets

An SLA isn't applied to tickets that meet all of the SLA policy conditions.

Explanation

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.

Depending on the ticket priority, SLA policies can have different target times and types of hours of operation:

SLA.png

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.

This can also happen if the ticket is created with a private comment or internal note, from a user who is not a light agent. For private tickets, first reply time SLA targets are deferred. The SLA target will activate when the first public end user comment is added, even if there have been public agent comments before that point.

In the example below, Zendesk didn't apply an SLA policy because the ticket was created without a priority.

Ticket without priority not triggering SLA policy

After the same ticket is updated to have a priority, Zendesk applies the SLA policy.

Policy applied after ticket update

First reply time metric not working

A newly created ticket doesn't show a timer for the first reply time metric even though all the criteria for the SLA policy are met.

Explanation

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 the first reply.

In the example below, there is no first reply time metric applied, because the ticket was created by an agent.

Ticket created on behalf of customer

You can create exceptions in your advanced settings.

SLA is not paused when the ticket status is pending

The SLA timer does not pause when the ticket status is changed to Pending.

Pending not pausing the timer

Explanation

This happens because the ticket is waiting for your agents to fulfill the first reply time or the next reply time metric. There are currently four SLA targets that do not pause in pending status: First Reply Time, Next Reply Time, Periodic Update Time, and Total Resolution Time. Reply metrics don't change based on ticket status. Reply metrics are fulfilled if an agent replies with a public comment 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.

Agent work time target with calendar hours

Explanation

SLA badges are always displayed in calendar hours. Real time remaining appears, so agents can prioritize their work. 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.

Different SLAs

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 the new policy is only a modified version of an existing policy, the system records another breach event at the time of the update.

Explanation

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

Explanation

When you edit a schedule, including adding or removing holidays, SLA targets do not automatically update. However, if a ticket receives an SLA update, targets will reassess. If there's a public comment, status change, priority change, or policy change, the ticket will recalculate its SLA badge according to the new schedule. Minimize schedule changes, since frequently changing your schedule cause confusion.

Note: SLAs don't apply to tickets that are solved upon creation. The solved status satisfies SLAs and prevents policies from activating, as long as the ticket remains solved. If tickets are reopened, SLAs can start activating and running normally.
Powered by Zendesk