Troubleshooting common issues with SLAs

Have more questions? Submit a request

23 Comments

  • Rene de Haas
    Comment actions Permalink

    "In this case, there is no First Reply Time metric applied, because the ticket was created by an agent"

    When we create a ticket on behalve of a customer, we need a SLA target. It should be replied in time. Any solutions?

    1
  • Megan Howell
    Comment actions Permalink

    Rene,

    In that situation, your best bet is to make an SLA using the reply time metric of "Periodic Update Time" which looks at the time between each public comment from agents, displayed in minutes. Unfortunately if an agent creates a ticket the First Reply Time metric is already out as an option, as it looks for the first public agent comment. You can see a bit more in this document.

    0
  • Brad Marshall
    Comment actions Permalink

    Is there any way to pause the "Next SLA breach" for "Periodic update" if it is in a status of Pending? Pending, to us, implies that we are waiting for a customer response and there is no dependency on the agent until the customer has fulfilled their responsibility. However, the timer keeps on going down and can mess up our workflows as you have to ignore some SLA's and pay attention to others.

    3
  • Matt Savage
    Comment actions Permalink

    I agree with Brad- more granular control over SLA events would be extremely helpful.  I understand the rationale for wanting to enforce the SLAs without an easy opt-out that could allow the metrics to be fudged.  However, there are many instances where an agent may review a ticket it but push it back to pending/hold status without comment:

    • inactionable responses (e.g. 'ok', 'thanks', etc.)
    • 'customer' responses come from automated systems (e.g. 'your ticket has been created') or similar sources that don't require actual response/confirmation at some points of a lifecycle

    There are workarounds, such as temporarily switching the ticket to a dummy SLA, then removing it when a new response arrives.  To combat abuse, you can also log any time this SLA is manually overridden in a custom field or tag so you can monitor that it's being used appropriately.  

    Obviously, this isn't ideal, but it is one solution that adds the basic functionality with some oversight.  You could combine this configuration with a trigger that gives you real-ish time notifications (email, Slack, PagerDuty, etc.) if you're concerned about monitoring it more proactively.  However, it'd be nice to have more control directly in the SLA policies rather than using complex workarounds.

    2
  • Mike
    Comment actions Permalink

    Can a ticket have SLA policies applied to it in succession?

    e.g. I've got a ticket that comes into our Tier 1 queue, to which a blanket 24 FRT SLA is applied. The agent replies back and achieves the SLA. But the ticket is not solved and needs to be escalated.

    The Tier 1 agent escalates that ticket to Tier 2.

    I have another SLA policy with 40 hour requester wait time, which should be applied to all tickets with a specific tag (applied via the escalation macro tier 1 agent used).

    That policy never gets applied. Does the ticket not get run through the SLA rules again after one SLA has been met?

     

    Thanks,

    Mike

    0
  • Peter Hochstrasser
    Comment actions Permalink

    We have the following metrics in our existing SLA:

    - 1 hour "acceptance time" for all priorities

      in this time span, we have to assign the ticket to a 2nd level agent

    - depending on priority, 1/2/4/8 hours "reaction time"

      after acceptance, we have to report an initial response by the 2nd level agent.

    - for blockers, there's a requirement for an update all 4 hours.

    There are no further requirements; there is no resolution time or some such.

    The first and last point are easy to implement, however, how do I handle and evaluate the second requirement? 

    The only idea i'd see is to "stop" the SLA after the "reaction time", i.e. first substantial response to the ticket by a 2nd level agent.

     

    Any pointers, ideas, tips?

     

    Thanks,

    Peter

    0
  • Rebecca
    Comment actions Permalink

    Hi Peter!

    Interesting question here! I see you opened a ticket with our Support team and appear to be in good hands. 

    0
  • Phil Holcombe
    Comment actions Permalink

    Zendesk support helped us understand another situation where SLAs are not behaving as expected. We use pausable update time to help ensure we keep customers informed of progress on issues that are taking a longer time ( for example because we've dependent on a supplier for an answer ). We noticed that some tickets are not showing any SLA target. The problem is caused when a public comment is added when the ticket is in pending status, or is set to pending status. In this situation, the SLA target is never set, so the ticket doesn't show any SLA breach time. It's not the most common workflow ( it's usually the customer that responds when the ticket is in pending status), but it's common enough to be confusing and annoying. The workaround is to only add public comments when the ticket is not in the pending status.

    Regrettably, it is considered 'as-design'

    If Zendesk believes this might impact others ( I had that impression ), I suggest this article is adjusted to reflect this scenario, and you can delete my comment.

    Phil

    Nexmo, the Vonage API Platform.

    1
  • Coilin Walsh
    Comment actions Permalink

    Hello - we have a "Next Reply Time" SLA set up, but it is not working on tickets when the end user sends an email (changes the Status from Pending to Open). The ticket is set with a priority, so I'm not sure what's going on.

    Additional info: we have nearly a clone of this SLA with "First Reply Time" and that one is working correctly. What do you think is going on here?

    0
  • Stephen Fusco
    Comment actions Permalink

    Hey Coilin, 

    Thanks for reaching out to us! The reason the SLA wouldn't be applied could be for any number of reasons depending on the setup of the SLA policy itself. To really troubleshoot we'd have to take a look at your account and the setup of the SLA itself. 

    I noticed that you're already working with one of our agents so i'll add the contents of your comment to that ticket so we can continue troubleshooting. 

    0
  • Lindsay Biernat
    Comment actions Permalink

    I'm creating a First Reply Time SLA and it appears to be firing on applicable tickets in the view, but I set the time to be 10mins, and it is showing on the view as 2 days from now. I'm new to this, can anybody give me some insight as to what's going wrong?? Thanks!

    0
  • Nicole - Community Manager
    Comment actions Permalink

    Hey Lindsay - 

    Most likely this means that the reply time would land outside of your business hours. The system defaults to two days to account for weekends. 

    0
  • Max McDaniel
    Comment actions Permalink

    Hi there, we have a report set to show "# SLAs Achieved" for a certain type of tickets, which should all fall into the same SLA policy. For several days, those tickets accidentally had a different SLA policy applied which they, by definition, couldn't achieve and therefore our report shows a column of "0" for the days where the wrong policy was applied. Is there any way to salvage the report for those days?

    I ran an automation which updated those tickets, causing the SLA policy to switch for them to the correct policy, however there still do not appear to be any recorded SLAs achieved in our report.

    Thanks!

    0
  • Guy Dee
    Comment actions Permalink

    Hi Max!

    Sadly there's no way to retroactively apply or analyze SLA data. Even if the correct policy has since been applied to the ticket, it will only assess its targets from that point forward; it can't go back and determine whether or not it would have been achieved if it had been applied earlier.

    Depending on the metrics your policy measures you may be able to retrieve some similar metrics for the affected tickets in a separate report, like first reply time and full resolution time, but the black-and-white Achieved vs Breached data can't be reconstructed.

    To avoid cluttering or confusing your current report, you might consider filtering out tickets from the affected date range.

    0
  • Heather Cook
    Comment actions Permalink

    Hi Team,

     

    Right at the end of the article there is this explanation:

    Explanation:

    The system can’t modify past ticket events history from the technical point of view, that's why when a new SLA application happens, SLA counter always looking forward from that point.

     

    This really doesn't make sense, please can you explain? Also could someone may update the English, as I don't believe it is correct.

    0
  • Jessie Schutz
    Comment actions Permalink

    Hi Heather!

    It's a little confusing and hard to explain, but I'll try to clear it up.

    It just means that the system can't retroactively apply a new or modified SLA to tickets that breach that SLA.

    So, let's say that you create a new SLA on Wednesday. There's a ticket in your Zendesk that, according to the conditions of that new SLA, would actually have breached the SLA on Monday had it been in place at that point.

    Zendesk will show that the ticket breached the SLA on Wednesday, the date the SLA was created, rather than Monday even though that's technically when the ticket met the SLA criteria.

    I hope that makes sense!

     

    0
  • Human-ISM Sysadmins
    Comment actions Permalink

    As others have stated, we really need a Next Reply Time metric that excludes tickets set to status Pending. The 'Pausable Update" Metric doesn't work for this, because it will count down for tickets that have already been replied to but were not marked pending.

    We also need a Next Reply Time metric that is satisfied by private comment updates.

    Currently there is simply no way track next reply time while taking into consideration excluding tickets marked as pending. This means you have to mark *every* ticket as pending whenever you reply, else you're going to fall flat on your face and break SLAs all over the place. We need to track our reply time, but we definitely don't want to set every ticket to pending to have to do so, because not every reply *should* have a ticket set to pending (E.G. a public reply from an agent of "we're working on this, it should be resolved within an hour" should count towards a *reply time metric*, but we should not have to make a public comment every time we set a ticket to pending telling the end user something they already know (E.G. "Thanks for telling us you're asking Joe about this, we're going to mark this as pending"). That's just harassing your end users with telling them something they already know because your ticketing system doesn't know how to handle pending statuses and reply-time SLAs together.

    Thus, Next Reply Time really needs a counterpart metric that pauses it when the ticket is set to Pending.

    At minimum, adding a Next Reply Time Excluding Pending metric would reduce the support burden of having to explain why the metrics don't work the way you expect them to, and having to train Agents to always make a public reply whenever they set a ticket to pending.

    Of course, this would also be fixed by making a Next Reply Time metric that was satisfied by private comments as well as public comments. Then agents could simply make an internal ticket update in cases where they mark a ticket as pending without a public reply. This is an internal metric that should be tracked to determine actual action time, as making a public reply for anytime a ticket is updated is also silly, and tnat's not currently possible in Zendesk.

    2
  • Nicole - Community Manager
    Comment actions Permalink

    Thanks for the feedback, Human-ISM Sysadmins

    I shared it with the product team that deals with SLAs, and they said that you raise some great points, however changing these things is much more complex than it looks on the surface, and no changes to SLAs are on the roadmap this year. However, we'll keep your comments on file for use the next time SLAs come due for improvements. 

    0
  • Ayal Kellman
    Comment actions Permalink

    Does anyone have any practical experience using Agent Work Time as their (only) SLA? I'd love to see a practical example how it can be implemented...

    Thanks!

    0
  • Devan - Community Manager
    Comment actions Permalink

    Hello Ayal,

    I've gone ahead and responded to your question on this topic in a previous post of yours linked below.a

    Response

    Best regards,

    Devan

    0
  • Fabio Strasser
    Comment actions Permalink

    Hi Nicole/Devan,

    +1 on the comment from Human-ISM Sysadmins.

    1st use-case: 
    A customer writes us, we call him back to answer him. After the call, we set the ticket to "pending" because there are still open topics for him to answer. We don't actually send a reply though, so the "next/first reply time" SLAs keep running.

    2nd use-case:
    We send the customer an email "sorry we're keeping you waiting, we're on it ....". He just replies "ok". Because of his answer, the "next reply time" SLA starts again.

    So we would need an option to pause those SLAs. Human-ISM Sysadmins' solution would be to write an internal comment. This is a possiblity for us as well, but a better solution would be a "pause" button in the ticket (maybe next to the SLA display at the top of the ticket).

    2
  • Ritz Kukreja
    Comment actions Permalink

    +1 on the inactionable responses from customers e.g. ok, thanks and SLA keeps running!! 

    what is the workaround for this issue

    0
  • Kevin
    Comment actions Permalink

    I'd also like to know if Zendesk has a recommended workaround? re: the issue raised by Ritz Kukreja, Fabio, Human-ISM Sysadmins, Matt Savage, and Brad Marshall  --  Next Reply when status is Pending should pause.

    0

Please sign in to leave a comment.

Powered by Zendesk