Defining and using SLA policies (Professional and Enterprise)

Have more questions? Submit a request

138 Comments

  • 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?

    1
  • 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?

    0
  • Nicolas Bergeron
    Comment actions Permalink

    Hi, 

    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.

    NB

    0
  • 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!

    0
  • 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.

    0
  • 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!

    Martha

     

    0
  • 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.

    1
  • Jon Rosenberg
    Comment actions Permalink

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

    0
  • 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.

    Cheers!

    0
  • Gina Martinez
    Comment actions Permalink

    Hi,

    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?

    0
  • 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.

    0
  • 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!

    1
  • 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!

    0
  • Kevin
    Comment actions Permalink

    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?

    0
  • Kevin
    Comment actions Permalink

    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."

    0
  • Brett - Community Manager
    Comment actions Permalink

    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.

    Thanks!

    0
  • Matt McLean
    Comment actions Permalink

    Brett,

    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.

    0
  • Christopher Rehn
    Comment actions Permalink

    Hi!

    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.

    0

Please sign in to leave a comment.

Powered by Zendesk