Defining and using SLA policies

Return to top
Have more questions? Submit a request


  • Heather Cook

    In the article you mention:


    How does it work for Agent Time? For example I have a ticket where the Agent Time SLA of 8 hours is breached by an hour, but the ticket get's reassigned and given a new SLA policy where the Agent Time is 24 hours. What does the SLA clock do?

    Or if the scenario is reversed and the ticket Agent Time SLA is 24 hours, and it is 9 hours left till breach. The the ticket gets reassigned and the SLA policy changed to 8 hours Agent Time. What happens?

  • Monica

    Request:  I would appreciate being able to use Requester's Language as a condition of SLAs without having additional tags on a ticket.  Or even being able to use schedule as a condition.

    Use Case:  Our teams are based on functions used for groups in Zendesk and then split by language in views so they share macros and make reporting cleaner as their tasks are the same.  Not being able to target SLAs based on language or schedule requires creating alternatives such as a ticket field for language or ticket tagging.  Which if a requester's language is updated without updating the ticket right away means that they will sit in the incorrect SLA for longer.

    Other ideas for targeting SLAs based on language?

  • Nicolas Bergeron


    i have maybe a stupid question but i am scratching my head on it.

    As per header when defining SLA policies, the sentence is the following from Zendesk:

    A service level agreement (SLA) is a contract between you and your customers that specifies performance measures for support by ticket priority. For example, we respond to urgent tickets in ten minutes and resolve them within two hours. Your SLA policies are applied to tickets in the order they appear on this page, so drag to reorder as needed


    Now, if my first resolution time is 10 business days for an incident .. which target to i use in my matrix for each priority ??

    FRT: not relevant

    Requester Wait time? but the "paused" time doesnt goes toward the time from new to solved..

    Thanks for your guidance.


  • Bryan - Community Manager
    Zendesk Developer Support

    Hi Nicolas. It sounds like you want full resolution time applied to an SLA policy. Am I reading that right?

    Full resolution time is indeed a metric, but not one that SLA policies use.The only resolution times that SLA policies consider are Requester Wait Time and Agent Work Time.

    As you noted, "pending" time isn't considered because that time is outside of the agent's control, so having an SLA around it wouldn't be typical.

    I found a number of references about using full resolution time that might help, however:

    A couple good community posts on the subject:

    Tracking time spent on tickets between re-open and solve

    Full Resolution Time

    And some reference documentation:

    Ticket metrics via REST API

    Insights reporting and object reference

    Hope this is on track with your question and helps!

  • One Acre Fund

    Hey Zendesk Team,

    Quick question we create our SLAs to match categories. However, you might find a ticket might go through several categories before finally being closed. In this case which sla will be applied on the ticket.

  • Martha Walden

    Hello all,

    Hoping someone can answer this question. In the documentation above it says:


    Is this a hard and fast rule that you can ONLY choose one OR the other, and not both? What happens if you choose BOTH?


    Thanks for your insight!



  • Human-ISM Sysadmins

    We really need two additional metrics, and these have been requested a couple of times already in this thread and the SLA FAQ thread:

    1) Next Reply Time Excluding Pending Tickets

    2) Next Reply Time Satisfied by Public Comment OR Internal Notes (Private Comments)


    1) The current "Pausable Update" metric doesn't work for this because it tracks time between Agent public comments, not reply time from the last end-user comment. This means any time an agent sets a ticket to pending, they have to make a public comment.

    2) This is required for internal response-time tracking, and should be monitored for all agents to ensure that tickets are being handled promptly, even if a public comment has not yet been made. In fact, this is a more important metric than Public Reply Time, because different issues can take different amounts of time to resolve and thus reply to the client, but what you really want to be tracking is how long it takes for an agent to start working on the ticket, and that includes internal notes. Some tickets really shouldn't receive a public reply until a task is completed (generally any task-oriented tickets that are not a system broken), and those should have private notes added, and the time between end-user comment and that private note should be tracked. Not having this means anytime an agent begins working on a ticket they have to make a public comment, even if that comment has *no* usable information or even any information the end user didn't already have.

  • Jon Rosenberg

    I'm curious, are SLA's visible to the end user?

  • Brett Bowser
    Zendesk Community Team

    Hi Jon,

    Natively SLA's are not visible to the end-user. If this is something you're looking to make available, you may be able to set this up using our API and some Javascript. Here's a link to our API documentation which I believe you'll find useful.


  • Gina Martinez


    Any solution for setting SLA's based on a future due date?

    I have 2 sets of 3 customers who submit tickets based on future work needed. Due Dates are set using the 'Task' due date. So if I set my SLA for 24hrs, for a ticket form not due for a month, the SLA is breached by they time we get to it. 

    Can anyone think of a work around for this?

  • Tero Pihlaja

    Hello Gina,

    We are using the on-hold status with a trigger that changes the ticket to open state on due-date for a similar case.

    Maybe this works for you too.

  • Jessie

    Do you happen to have any better screenshots of what this would look like in a view? The screenshots in this article are small and blurry :)

    Thank you!

  • Nicole Saunders
    Zendesk Community Team

    Thanks for the feedback, Jessie. I've passed it along to our publishing team and we'll see if we can get some clearer images for you!

  • Kevin

    I am trying to determine if I can use Next Reply metric in the same policy as either Periodic or Pausable Update. I believe my question is: When the Next Reply Metric is satisfied with an agent response, is the Periodic or Pausable Update activated with the very same agent response?

  • Kevin

    Another question I have is why conditions cannot be based off ticket status. I read the text quoted below, but I do not understand what "those pieces of information are already built into the SLA policy model" means. I am confused why a condition based on status would affect anything negatively


    "Conditions for SLA policies are similar to the conditions you use to set up triggers. Like conditions for triggers, they have both All and Any conditions, and the conditions can be based on ticket fields, user fields, or organization fields. However, there are fewer options than in triggers. For example, you can't create a condition based on the ticket’s status or priority, because those pieces of information are already built into the SLA policy model."

  • Brett Bowser
    Zendesk Community Team

    Hey Kevin,

    Periodic and Pausable update is indeed activated from the same public response by the agent. As for status condition, the reason this not an available condition is because the Status is already being looked at to determine if an SLA target has been met or is paused.

    For example, the pausable update target will pause when the ticket is in pending status. This rule is built into the SLA policy system.

    Let me know if you have additional questions for me.


  • Matt McLean


    Since you mention Pausable Updates, has there been any progress on changing the logic that means a ticket will never start the Pausable Update timer if an Agent switches a ticket to Pending at the same time that they make their first Public Reply? This leads to some tickets falling through the cracks, since they won't have a "countdown" in the SLA column, and any automations based on "hours until breach" will not run.

    I had a ticket about this issue and was told it would be flagged for feedback/voice of the customer.

    Here is how you have it documented:
    "The pausable update metric uses the agent's public comment on a new or existing ticket as a starting point, only if that ticket is not in the pending status. Once a comment is present, the metric pauses in the pending status and resumes in a non-pending status with either no comment or a private comment from an agent."

    The part I take issue with is that it says "only if that ticket is not in the pending status." When a ticket is in the "New" status, an Agent's first Public Reply should start the Pausable Update, and it does, as long as the Agent does not simultaneously change the status to Pending.

    I understand that the Pausable Update SLA currently works this way. However, I have not seen any argument for why it should work this way.

  • Christopher Rehn


    I use Zendesk Insights and am not currently able to make the switch to Explore.


    I would like to set up a daily report with the following information:

    * Tickets currently in New/Open state with the current SLA considered a breach.

    I am not interested in "#SLAs breached total" because that would return tickets whose most recent requester reply has not passed SLA yet even though earlier replies may have.


    I merely want to see tickets whose current SLA status ("Next SLA Breach" as shown in Views) is passed, and are currently new/open.

    I tried building a report that shows New/Open Tickets with SLA breaches, but that keeps returning historical breaches whereas in this instance I am more interested in the current breach only.

  • Brett Bowser
    Zendesk Community Team

    Hey Christopher,

    Are you trying to see SLA stats in real-time? If so, I'm afraid this isn't possible at this time.

    Let me know if I'm misunderstanding your question! If you have a report example that we can take a look at that may also be helpful.


  • Christopher Rehn

    Hi Brett!

    No worries, I believe I have sorted it out! :) It does not need to be in real-time as such, since our agents do not work in the night. I built a report showing Tickets where the current SLA is Breached and the Ticket Status is New or Open. 

    I based it on another Metric that was present in Insights, "# SLAs Breached (Total)" but adapted it to this:

    SELECT IFNULL((SELECT COUNT(Records of Ticket SLAs) WHERE SLA Metric Status in (Breached (Active)) and Ticket Status <> Deleted and SLA Policy <> (empty value)), 0)

    We send out a Daily Report every morning at 7am, so this will report a close enough estimate to show many currently open tickets have surpassed their SLA, even though a few of them (the ones expiring between the latest update to Insights and 7am) are missing.

  • Brett Bowser
    Zendesk Community Team

    That's awesome! Thanks for sharing Christopher :)

    I think it would be useful as an Explore Tip as I'm sure other users could benefit from reporting on this data.

    If you're interested, you can create an Explore Recipe tip in our Explore Best Practices, Workflows, and Tips topic which I've linked for you.

    Thanks again and glad you were able to get this solved.


  • Jason Brown

    I am trying to set up SLA's and I am running into an issue. A lot of my organization tickets are submitted by light agents. I found that SLA Policies are not being applied when a ticket is re-opened from solve with a private comment from a light agent. I found that it takes a public comment from an Agent to trigger a policy being added.

    Is there a way to ensure that an SLA policy is applied whenever a ticket is re-opened?

  • Brett Bowser
    Zendesk Community Team

    Hey Jason,

    What SLA target are you looking to pick back up once a light-agent replies and re-opens the ticket? I'm afraid there's no way to customize an SLA policy and allow internal notes to be factored in here.

    I'd be happy to pass this along as feedback to the appropriate product managers on your behalf.

  • Craig Willis

    We have a Next Reply Time SLA that requires that Urgent and High Priority Cases for our Premium customers are updated ever 2 and 4 hours respectively.

    However, what we often see happen is that the agent will inform the customer that they will have an update for them in 2 days, (for example) and the customer is fine with that.

    However, the case is still Open, or On-Hold and so the NRT SLA will still fail multiple times.  We can't set the ticket to pending as that wouldn't be correct.  

    My question is, can we pause the NRT SLA when we've informed our customers as to when they will get a response?



  • Pedro Rodrigues
    Community Moderator

    Hi Craig Willis, if I understand your problem correctly, a workaround is to provide a specific macro for your agents to use when that happens.

    The macro could leave a generic internal note, set the status to On Hold and, more importantly, a specific tag (e.g. long_onhold).

    • In the current SLA policy you'd set a condition to not include the long_onhold tag
    • You'd create a new SLA policy for tickets with the long_onhold tag, and with a total handle time of 48 hours, for example.

    From that moment on, all those tickets where agents apply the macro should be updated with the new SLA policy.

    Hope this helps!

  • Monica

    I'm having a similar issue as Jason.  The non-requester replies which re-opens the ticket with a private note.  An SLA does not apply.

    When someone solves their ticket via Answer Bot and then replies re-opening the ticket, the first reply SLA is not applied but instead the next reply/pausable reply SLA policies are applied.  It would more sense for the first reply SLA to apply since an agent has not replied yet. If a view is sorted by SLA, someone could move themselves up the queue by solving and then replying.


  • Brett Bowser
    Zendesk Community Team

    Hey Monica,

    The First Reply Time target will not start until the ticket gets a first public comment from an end-user. Additionally, the FRT target is considered fulfilled once the ticket has been Solved . More information in the following article: Understanding first reply time (Professional and Enterprise)

    There's no way to adjust how the FRT target functions and I do apologize for any confusion this may have caused.

    Let me know if you have any other questions!

  • Conza

    Hi team,

    Our online support assists customers (end users), and stores (light agents) who process the orders.

    We have a 5 hour store response SLA.

    The issue is... all the comments are internal/private notes, and as such the first reply is never actioned - although it has taken place.

    Is there a work around to this?  

  • Conza

    Anyone? *Coo-eee*

    Elaborating a bit - the agents engaging with the light agents are internal/private comments. There is sometimes a chance that then becomes a public comment to customer. 

    The red flags remain for SLA not being actioned in time, but the response has actually taken place. It's just not recognised unfortunately. 

    How to resolve this? 

  • Nicole Saunders
    Zendesk Community Team

    Hey Conza - 

    I spoke with the product manager about your issue, and she said that there's not an easy workaround for this. However, she'd be interested in connecting with you to get more details on your use case as she's looking into some features related to your needs for a little ways down the road. Would you be interested in speaking with her? 


Please sign in to leave a comment.

Powered by Zendesk