Viewing and understanding SLA targets

Return to top
Have more questions? Submit a request

30 Comments

  • OT

    I love the look of the dashboard. We've just started using the SLA options and I like them so much that we're tweaking processes to make them fit.
    We're trying to decide whether to start using the Next Reply Time option. Is it possible to report out Next Reply Time at the moment? Would be great to see how long it's currently taking us to get an idea. Also, it was mentioned above the possibility of Next Reply Time SLA pausing on change to Pending, will this be happening?
    Related to this, is there currently a way to report out Agent Wait Time? This metric is perfect for our helpdesk to target, but I couldn't work out a way to combine metrics in Insights to get it.
    Thank you for the great feature.

    0
  • Erin Boyle

    Hi Ola,

    There's no specific Agent Work Time metric in Insights right now. However, you could create a custom metric using a combination of requester wait time and hold time. Basically you'd take Requester Wait Time and subtract Hold Time to get the equivalent of Agent Work Time. Hope this helps!

    We're still testing and fixing some bugs on the SLAs integration to Insights, but I'll let you all know as soon as it's available.

    Best,
    Erin

    0
  • Joel Hellman

    @Erin about the reports you guys are building for Insights...

    Unsure if this has already been explained somewhere, but, during a ticket's lifetime, there may be multiple SLA fulfillments and breaches. E.g. a ticket could have cleared the First Reply metric, then cleared the Next Reply metric 3 times out of 4 (so it breached at one time). Or the ticket may have breached the First Reply metric, and breached 4 of 4 for Next Reply time. Which would indicate a considerable worse customer experience!

    I'm wondering how/if we will be able to report on this? I.e, will we be able to measure SLA compliance as how it relates to the amount of times a ticket metric was applied, like a %compliance, or/and would a report metric be used that considers any SLA breach for a metric as if the entire ticket breached that SLA metric?

    Never breaching SLA for a metric like Next Reply time could pretty hard for longer/reopened tickets, and if we can only consider tickets which have never breached SLA in reporting, we wouldn't be able to separate pretty good SLA compliance (say 3 out of 4 Next Reply) from pretty bad (0 out of 0).

    0
  • Erin Boyle

    Hi Joel,

    Yep, this is one of the things we were very cognizant of when designing the new metrics. We'll count each instance of Next Reply separately, which means when you look at the % Achievement of the Next Reply metric for your account, it will essentially take the # times an instance of Next Reply achieved its target across all tickets and divide it by the # of instances we measured of Next Reply.

    Hope this helps!
    Erin

    0
  • Joel Hellman

    Just what I was hoping for. Nice :)

    0
  • Erin Boyle

    Hi all,

    We've started rolling out SLA metrics (and a dashboard) to Insights - you should be reporting by the end of today! See my announcement for more information: https://support.zendesk.com/hc/en-us/articles/207964937-SLA-reporting-available-on-Insights-rolling-release-

    Thanks for your patience on this one.

    Best,
    Erin

    0
  • Bonnie

    I am testing SLAs in our Sandbox, and I can see the policy applied in the ticket by clicking on the 'Show All Events'.  But I cannot see the green box in the top right of the ticket, nor can I see any values in the 'next SLA breach' column in my views. Can you give me any suggestions?

    Thanks,

    Bonnie

    0
  • Erin Boyle

    Hi Bonnie,

    1. Make sure you have a priority set on the ticket—that's probably the most common issue we see.
    2. If you've set up only first reply time and/or next reply time, you also need to make sure an end-user has made a comment on the ticket in order for those metrics to run. This is probably the second-most common issue we see.

    Hope this helps! If things are still looking off, we can create a ticket for you to look further.

    Best,
    Erin

    0
  • Bonnie

    Thanks Erin,

    It was Item 2. 

    Is there a way to have the metrics run without needing the customer to make a comment?  Would I need to setup the first reply time PLUS one of the resolution metrics?  I am looking specifically to see the 'next SLA breach' time - show how long before the first reply time metric is reached. 

    Thanks,

    Bonnie

    0
  • Erin Boyle

    Hi Bonnie,

    If you're just looking to have a metric appear, and don't really care what metric it is, then one of the resolution metrics would certainly do that for you. The reason the reply metrics don't show up is that if an agent creates a ticket on the customer's behalf, that is by definition already a first reply. When a ticket is created by an agent, the first reply metric is automatically fulfilled. Even if you set up a resolution metric, you still won't see a first reply timer unless an end-user created the ticket.

    I typically create a dummy end user with my personal email address and send in tickets that way to test. You can get the full experience that way.

    Best,
    Erin

    0
  • Ben Richards

    We also need a way of manually pausing the 'Next Reply' SLA metric as we get emails from a 3rd party with a local helpdesk reference number which doesn't need a reply, however it sets off the next reply metric again.

    A way to flip the status from Open to Pending and pause the SLA without needing to supply a public comment is needed..

    Is there a workaround ???

    0
  • Nicolas Feller

    Hi there,

     

    The following work around is a suggestion for communications with 3rd party collaborators to avoid setting of the SLA. The original request here is a way to manually pause the SLA which I am not aware if it possible at all.

     

    Follow these steps if you like some of the public comments not to set of the SLA.

     

    1. Create a trigger with the following conditions. Meets all of the following conditions > Ticket: Comment text > Contains the following string > (***string of comments agreed with 3rd party***). / Ticket is > Updated.

    Perform these actions: > Add tags > (tag that you would like for reference).

    *** For this work around to work it is necessary that you agree with the 3rd party collaborator a specific string of comments. Placing a under score instead of space would be optimal. I.e. "REFERENCE_ID:" ***

    2. Create a trigger with the following conditions. Meets all of the following conditions > Ticket: comment text > Does not contain the following string > (use the same string from the past trigger). / Ticket is > Updated

    Perform these actions: > Remove tags > (same tag from the last trigger).

    3. Create a trigger with the following conditions. Ticket is > Updated. / Ticket tags > Contains at least one of the following tags > (same tag used on numbers 1 and 2). 

    Perform these actions: > Ticket status > Pending

    4. Now we have to edit you current SLA which you don't want to set of every time the 3rd party collaborator responds to.

    Just add the following conditions to it. Apply this policy to tickets that meet ALL of these conditions > Tags > Contains none of the following > (tag used on triggers 1, 2 and 3).

     

    If all has been properly set every time your 3rd party collaborator responds to a ticket following the instructions (specific string of words) the trigger will fire and a tag that sets the ticket status to pending will be placed. Once the ticket is on pending status the SLA countdown will not start. Make sure to use a specific string of words that the customer would not use. 

     

    Hope this work around helps you to improve your work flow.

    1
  • Don Wood

    I just want to confirm how the pause works. For example, if I have an SLA to resolve a ticket in 5 days but on day 3 the client is testing for 3 days does the final resolution time end up at 5 days or 6 days?

    0
  • Leandro Vasconcelos Sava

    Hi Don,

    Basically there are two resolution time metrics: Requester wait time and Agent work time.

    Requester wait time pauses the SLA when the ticket is put on Pending and Agent work time pauses the SLA when the ticket is put on Pending or On-Hold.

    E.g: You have a ticket where you have an SLA to give a resolution in 3 days, but you need to receive a reply back from a customer or an external source to go ahead with the ticket.

    On the day 2 you put the ticket on Pending or On-Hold and depending on the metric you are using it will pause the SLA.

    After 10 days you get a reply back from the customer/external source, automatically the ticket will go to open status and the SLA will start to run again, meaning that you will have 2 days left to resolve the ticket if you don't put it on pending or On-Hold anymore.

    I hope that I haven't overcomplicated it!

     

     

     

     

     

    0
  • Lohith S

    Hi Team,

    The report metric % Achieved or % Breached doesn't come with the metric for which it is being calculated ?

    For instance, % Achieved for First Reply time

    % Achieved for Next Reply time 

    % Achieved for Resolution time(Don't see this in our Professional Plan) etc ?

    Same with Breached

    Thanks

    Lohith S

    -1
  • Nicole

    I am able to see the next SLA time  but was curious whether there would be a way to see which policy is causing the SLA next update time.

    Thanks

    0
  • Brett Bowser
    Zendesk Community Team

    Hey Nicole,

    To see which SLA policy has been applied to a ticket, you can take a look at the Ticket Events as mentioned in the article I linked :)

    Let me know if you have any other questions for me.

    Cheers!

    0
  • Michal Inbar

    Hi :)

    I am trying to understand if I have a way to set an SLA of agent work time but only since the ticket was open (not new), do you know a creative way to achieve that?

    Also, do you know if I can use the event time stamps in the explore section?

     

    Thanks,

    Michal

    0
  • Jason Fouchier

    Hi,

         I have the same question as Michal, is there a way to ignore tickets in the "New" status?

     

    Thanks,

         Jason

    0
  • Ben Van Iten
    Zendesk Community Team

    Greetings,

    In this case I would recommend creating a trigger on your account that every time the status of a ticket is "changed from" new status to anything else, a tag is added to the ticket. You could then have the SLA policy require that tag in order to run. This might mean having an entirely separate SLA policy for the target that you are trying to measure, depending on your workflow.

    Please let us know if you have any further questions!

    0
  • Michal Inbar

    Hi Ben,

     

    Thanks for replying.

    I tried to do what you suggested but the problem is that I would like to measure the "Agent work time" and subtract the time the ticket spent in status "NEW", basically i want to change a little bit the time that is measured. 

    Even if I have a trigger like you mention when the SLA starts counting it takes under consideration the time between "New" and "Open" which I would like to substructure. 

    Just to avoid misunderstanding....example below :) 

    New --> Open : 1 day

    Open --> Pending : 2 days

    Pending -->Open 3 days  

    Open --> Solved : 4 days.

    In the case above, I wish that the policy sum up the bold lines (2+4) and not the first row of New-->Open.

    Do you have ant idea how can I do that?

    Thanks,

     

    Michal.

     

    0
  • Ben Van Iten
    Zendesk Community Team

    Hi Michal,

    Thanks for the update. I see what you're saying and why my original solution is problematic. Unfortunately there isn't a way to do custom SLA targets and customize what you are trying to measure. I would recommend posting in our Product Feedback section with your use case and why you'd need to edit this target type: https://support.zendesk.com/hc/en-us/community/topics/200132066--Feedback-on-Support

    This allows other users to upvote the request and agree with you. I am also glad to flag our exchange as feedback, but the first method is a better way to get across that a lot of other users agree.

    Please let us know if we can assist further.

    0
  • Jason Fouchier

    Hi Ben Van Iten,

     

        Thanks for the tip. I have put your suggestion into play and I will see how it goes. My SLA's are all based around "Agent Work Time" and my agents don't work on new tickets, so when it tracks the time in the "New" status it causes more SLA breaches then we are actually having. Is there a better workflow for this that I haven't thought of?

    Thanks,

         Jason

    0
  • Michal Inbar

    Hi Ben Van Iten

    I  posted in the Product Feedback :)

    Until we will get answer form there, do you think I can build a metric in the Explore  in order to calculate this time?

    The Explore contains those time stamps?

    Maybe I can use the SLA policy and then subtract the time between "New" to "Open" in the Explore? 

     

    Thanks,

     

    Michal.

    0
  • Jason Fouchier

    Hi Ben Van Iten,

    I tried the trigger/tag solution you described but it seems that it is still tracking the tickets in the "New" status. The SLA is set to run if the "Ticket Complexity" is set and the tag "sla_ready" is there. In the history of the SLA, you can see that it is "Activated" and "Applied" at different times. This is causing issues with agents breaching the SLA's depending on when they where assigned the ticket.

     

    Thanks,

          Jason

    0
  • Brett Bowser
    Zendesk Community Team

    Hey Jason,

    I'm going to create a ticket for you so our Customer Care team can look at some ticket examples.

    Thanks for taking the time to share this with us!

    0
  • Harold

    Hi, I'm stuck with SLA metrics in Explore, trying to get an overall SLA % for all targets over all tickets in a certain time frame. 

    Researching this I ran upon this: period is oct-dec 2020 for one customer; There was 1 ticket still open on dec 31, all others were solved and closed. 
    However, the metric 'Tickets with an active SLA policy' indicates 4. Even when I look at all recent tickets, there are only 2 in jan (one open, one solved). How can there be 4 tickets with an active SLA policy?
    (cf this in the article: Note: When a ticket status is set to Solved, all SLA targets are considered met, and closed as a result.)

    0
  • Chandra Robrock
    Community Moderator

    Hi Harold! Would you mind elaborating a bit more on how you have this specific report setup?

    I'm afraid I wasn't able to locate a built-in metric called 'Tickets with an active SLA policy' on my end. Are you perhaps referring to the 'Active SLA Tickets' metric, 'Active SLA Targets' metric,  'Active SLA Policies' metric, or something else?

    0
  • Harold

    Hi, 

    I'm sorry I didn't respond any sooner, I hoped it was just incidental.

    But I just ran into this issue again. There's a ticket that has been closed in Nov 2020. According to Explore it still has one active SLA: Pausable Update Time. 
    I use a metric called D_COUNT(Active SLA tickets) and selected 'Status of SLA target' to be null (this is also how I found some tickets that an agent created on behalf of the customer which didn't get any SLA targets).

     

     

    0
  • Chandra Robrock
    Community Moderator

    Hi Harold! According to Zendesk's help documentation, it says "Tickets set to Solved immediately fulfill all active SLA targets" so I'm not sure why you'd see an SLA Metric that was in a Closed Status without being able to inspect the ticket myself.

    I'd recommend reaching out to Zendesk's Support team so that they can take a closer look at your Explore query and this particular Ticket ID for further assistance. 

    0

Please sign in to leave a comment.

Powered by Zendesk