Defining and using SLA policies (Professional and Enterprise)

Have more questions? Submit a request

143 Comments

  • Kay
    Comment actions Permalink

    Hey James, How would you set-up an SLA on a voicemail message that came in via Zendesk Talk? It appears that it's not well possible since the metrics only measure against tickets that have a public comment, which in the case of private comment and voicemail is not possible.

    1
  • Nicole - Community Manager
    Comment actions Permalink

    Hey Kay - 

    I checked in with our SLA expert and he said that it's true that voicemails don't play well with SLAs. He suggested using a Requester Wait Time. Are you familiar with that? 

    0
  • George Kaloyanov
    Comment actions Permalink

    I have question about quote: "Currently, you can't create triggers based on SLA breach status."

    Are there any plans to make this available in triggers (e.g when SLA breach status changes to whatever value)?

    The automations seem pretty limited as far as SLA's are concerned with only number of hours and not being targets specific (e.g first reply breach vs next reply breach etc).

    0
  • Jessie Schutz
    Comment actions Permalink

    Hey George!

    We use automations with SLAs because they're time-based rather than update-based; Triggers only fire when a ticket has been submitted but automations run every hour or so. Would you be able to give more information about why you'd want to use Triggers with your SLAs? 

    0
  • George Kaloyanov
    Comment actions Permalink

    @Jessie:

    The automations in regards to SLAs are quite limited for the following reasons:

    *Run once per hour which is not good enough if our SLA targets are like 15 or 30 mins

    *Conditions are based on number of hours before or since SLA breach. But it is just about any breach, you can't specify specific targets in those conditions.

     

    In general we have certain SLA targets for first reply time that are in minutes not hours and also for our use case it would be nice to have Triggers to do something with the tickets (move them to different queue, email management list, etc) once a specific SLA target is breached (say first reply time for example).

    0
  • Jessie Schutz
    Comment actions Permalink

    Hi George! Sorry for the delayed response.

    I can definitely see where the current automation functionality isn't helpful for your situation. That said, I don't think that Triggers would be the solution in any case. Since they only fire when a ticket is updated, it wouldn't be an effective way to get timely reminders sent for an upcoming SLA breach.

    Now, since SLAs are based on ticket priority, you could conceivably set up triggers to send an email notification when a ticket is received or updated with a certain status, informing recipients that "An urgent ticket has be received and requires an update within 10 minutes" or something to that effect. It's not a perfect solution, but it might help.

    0
  • Jordan Phillips
    Comment actions Permalink

    I may be in a bit of a unique spot, but I really need an SLA in the Reply Time Metrics group which pauses on both Pending and On Hold statuses. We expect agents to update tickets periodically, but only if they are in New or Open statuses. 

    We're currently using the Pausable Update SLA with a trigger that adds a tag so the SLA doesn't apply when a ticket is On Hold. The problem is that this doesn't pause the SLA, so when the ticket opens up again, it may be breached or close to it, not giving the agent enough time to respond before a breach. 

    Is there a possibility of getting something like this?

    0
  • James Green
    Comment actions Permalink

    Jordan,

    Could you use Next Reply Time and ensure that agents always have the "last word" in the thread? The timer should then only keep running when the customer adds a comment (i.e. moves it from Pending OR On-hold into Open)

    0
  • Yoav Brog
    Comment actions Permalink

    @Jordan, I have the exact same requirement.

    What I'm going to do (after consulting with Zendesk's support people) is to apply a specific tag to on-hold tickets when they go into that state and remove it as they go out, so they are tagged as long as they're in that status.

    This would be done using a couple of triggers.

    Then modify the SLA policies to ignore tickets with that tag.

    I haven't had the chance to implement it yet but it should do the trick.

    Good luck!

    0
  • Jordan Phillips
    Comment actions Permalink

    @James,

    Thanks for the suggestion! This won't work for me because I need my agents to update our Open tickets every two days, regardless of if there is a customer update. 

     

    @Yoav,

    Thanks! The workflow you describe is exactly what I've set up and tested. This seemed like it would work, but the issue we've discovered is that when the SLA is reapplied to the ticket (after it's removed from hold and the tag is removed), the SLA timer is still running as though the ticket was never on hold.

    I suspect this is because the timer doesn't pause on hold status and is still based on the last agent update. In our case, a ticket might be on hold for a few days while a higher priority ticket is being completed, so if we require an agent update every two business days, it will automatically breach the SLA when removed from hold.

    Any other ideas out there?

    0
  • James Green
    Comment actions Permalink

    @Jordan

    Hmm maybe I'm not understanding correctly. My suggestion would ensure that a ticket is only Open (and therefore subject to your two day periodic update) if there is a customer update. Your agents would always set to Pending or On-Hold.

    Perhaps it's just me, but I never want a ticket to remain Open after I've made the last comment; it should always be Pending, On-Hold, or Solved if I've made the last comment.

    0
  • eko hardianto
    Comment actions Permalink

    Hi let me give the question that, if we reply email ZD submit as hold or pending, it will be increase the amount of SLA or not? anyone can answer my question will be pleased. thanks

    0
  • Yoav Brog
    Comment actions Permalink

    @Jordan - that's a bummer ;(

    Sounds like your explanation is correct, I'll give a test on my end as well and update if I manage to get it working though I'm not hopeful now ;(

    I don't have any other solution in mind, lets see if the Zendesk people have any other suggestion.

     

    @Eko - I'm not sure exactly what you, so it would help if you elaborated on your question.

    In general, if you reply via email to a ticket you can't control its status really. If the requester replies, it will Open the ticket, but if you reply via email, it won't go to Pending.

    0
  • Kristine Schindler
    Comment actions Permalink

    I am using the given SLA Reporting in Reporting Insights and in the SLA Reporting  header the SLA Policy List of Values does not match the list of SLA Policies I currently have in place.  How do I modify the list of values so it is accurate?

     

    Kristine

    0
  • Jessie Schutz
    Comment actions Permalink

    Hey Kristine!

    If there are SLA policies missing from your Insights report, the most likely scenario is that there haven't been any tickets using that policy so there's no data to send over to Insights. Once there's data available, it should get sent over.

    If this scenario doesn't seem to fit what your experiencing, let me know and we'll see what else we can figure out!

    0
  • Amy Waugh
    Comment actions Permalink

    Hi

     

    The SLA's function doesn't seem to work if the requester is an agent.

    Is there a way around this so that all tickets regardless of the role of the requester can use the SLA feature.

    0
  • Nicole - Community Manager
    Comment actions Permalink

    Hi Amy - 

    What SLA are you trying to apply? SLAs should work regardless of role, with the exception of First Reply Time. If you're not using FRT and you're having trouble getting it to apply, then we should do some troubleshooting. 

    0
  • Amy Waugh
    Comment actions Permalink

    Hi

    I was having a go at testing this in sandbox before implementing in live and it didn't seem to apply the SLA on tickets where agents are the requester, when it did on non-agent requested tickets.

    I was using, first reply time.

    Why is this the exception?

    0
  • Nicole - Community Manager
    Comment actions Permalink

    Hi Amy, 

    The First Reply metric does not apply on tickets created by agents because the description, being a public comment, is considered to be the first reply. 

    You can find more info on this in the article "Troubleshooting common issues with SLAs."

    0
  • Nate Legakis
    Comment actions Permalink

    We're on the Team plan and I'd like to simply create an automation to send out an email if none of our agents have replied to new tickets after 22 hours.  Is this possible?  If so, please let me know how.

    0
  • Graeme Carmichael
    Comment actions Permalink

    Nate

    Create an automation with conditions:

    ALL

    • Ticket Status is NEW
    • Ticket: Hours Since Created is greater than 21
    • Ticket Tags: Contains none of the following: email_22_hours

    Perform these actions:

    • Notifications: Email Group: Your Group
    • Ticket Add Tags:email_22_hours

    Because the ticket status is NEW, there is no agent assigned to the ticket. So you have to select a specific group of agents to notify or nominate a specific agent to notify.

    There are more details on automations here.

     

    0
  • Max McDaniel
    Comment actions Permalink

    Apologies if this is covered elsewhere, but I'm trying to find a way to report on the amount of time a ticket spends in New and Open status. The "Agent Work Time" SLA looks to be the correct measure, but this does not appear to be an option in GoodData. There is a metric for "Requester Wait Time" which indicates it measures the amount of time a ticket is New or Open status, but the report seems to be returning the total resolution time instead. Any thoughts?

     

    0
  • James Sanford
    Comment actions Permalink

    Hey Max!

    SLAs wouldn't be the best way to approach this measurement.  I would recommend building a report in GoodData based on our guide Insights recipe: Reporting on duration of a text field.  The Measuring Average Time in Solved section will be most applicable to what you're trying to review.

    0
  • Phamlephuongtrang
    Comment actions Permalink

    Hi Experienced,

    I'm new in SLAs metric, could you share about technical how to define the SLA for the service? 

    Thanks & Best Regards

    0
  • Gerald Crawford
    Comment actions Permalink

    So I read through this section and saw the following:

    "The first reply time metric is not applied to tickets created by agents, unless the ticket is created through a private comment"

    I was a little confused here. If the ticket is a private ticket, why would FRT be applied?

    0
  • Gerald Crawford
    Comment actions Permalink

    @James

    You said SLA's would not be a good place to approach the measurement of the amount of time a ticket is in the New and Open status. 
    If that is the case then why has Zendesk created the metric just for that? As Max pointed out the Agent Work Time seems to fit the bill exactly. As as this Zendesk article points out it is the "combined total of time spent in the New and Open status" for a ticket.

    Can you elaborate further why you do not think SLA's are a good place for this approach?

    Thank you

    Jerry

    0
  • James Sanford
    Comment actions Permalink

    Hey Jerry!

    "Can you elaborate further why you do not think SLA's are a good place for this approach?"

    Definitely!  An SLA will only show you whether the SLA was met or breached  While this can definitely be useful, there is more nuance to how an individual request is handled by an Agent.  If you are looking for actionable data points for your team to improve upon, I believe it is much more beneficial to have actual time values. 

    As an example, let's say your entire team has met all Agent Work Time SLAs.  That's definitely great as it shows that you are meeting the requirements laid out by the business for how much time they can spend on tickets if you wish to handle your volume or contractual obligations to customers.  If you were to look at the actual time spent on those tickets however, you may see that some of your Agents are spending more time on those customer tickets, possibly nearing the point of breaching the SLA, but as a result are providing customers with more in depth answers and solutions and with a higher rate of customer satisfaction than another Agent who is resolving their tickets in a much shorter timeframe but without the same level of quality as the rest of the team.

    My recommendation is to use SLAs as a means to ensure your teams are meeting the requirements set out by the business as a whole.  If you are looking at individual Agent performance however, there is far more that can be gleaned from actual time spent values, and this is especially true when including other metrics that gauge Agent performance within those same reports.  

    0
  • Gerald Crawford
    Comment actions Permalink

    Thank you for the quick response James.

    Let me follow up then. So what exactly is the Agent Work Time metric actually keeping track of? 

    Max said he wanted to see how long a ticket stayed in the New and Open status. Sounds like he is not looking at it from an agent level but from a ticket level.

    Is this metric not measured per ticket? Meaning can I not drill down to see what the AWT is for a specific ticket number? And is that value not given in a time measurement?

    I am asking because I am also evaluating currently some new features and capabilities we currently do not have, and this was of interest to me.

    0
  • James Sanford
    Comment actions Permalink

    Hey Jerry!

    The SLA Metrics will generally be keeping track of whether the SLA Target was met or breached rather than tracking a time value.  Service Level Agreement (SLA) metrics

    With that said, as outlined by some of the linked metrics including time durations, there may be cases where you could technically use these to show the time value you are looking for.  Due to the way that data connects and the complexities of reporting functions, my suggestions to use metrics, facts, or objects that are not part of the SLA metric set will generally ensure that you are only seeing the data that you're expecting.  Additionally, most of these non-SLA metrics will "play nicely" with similar ticket performance / agent performance metrics that you may not see the same results with if you build your report using the SLA metrics instead.

    To address the original question once more, with newly added perspective from discussing this with my peers; Yes, you could use the SLA Metric Value metric to report on some of these time durations.  As a general rule of thumb however, based on the types of reporting that we see customers looking for, we would recommend using the other methods of obtaining that data which I have tried to outline here.

    0
  • Gerald Crawford
    Comment actions Permalink

    James again thank you for your feedback.

    I would imagine that Zendesk put in a time tracking SLA because it is common to create internal SLA for ticket lifecycle. And it is a very useful SLA to measure and better understand the performance of your team. 

    Perhaps you have thoughts on my first question, the article from Zendesk stated the following.

    "The first reply time metric is not applied to tickets created by agents, unless the ticket is created through a private comment"

    I was a little confused here. If the ticket is a private ticket, why would FRT be applied?

    0

Please sign in to leave a comment.

Powered by Zendesk