Defining and using SLA policies (Professional and Enterprise)

Have more questions? Submit a request


  • Heather Cook
    Comment actions Permalink

    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
    Comment actions Permalink

    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
    Comment actions Permalink


    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 Flynn
    Comment actions Permalink

    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!

  • Linda Mise
    Comment actions Permalink

    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
    Comment actions Permalink

    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
    Comment actions Permalink

    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
    Comment actions Permalink

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

  • Brett - Community Manager
    Comment actions Permalink

    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
    Comment actions Permalink


    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
    Comment actions Permalink

    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
    Comment actions Permalink

    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 - Community Manager
    Comment actions Permalink

    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!


Please sign in to leave a comment.

Powered by Zendesk