Troubleshooting common issues with SLAs Follow

Comments

8 comments

  • Avatar
    Rene de Haas

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

  • Avatar
    Megan Howell

    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.

  • Avatar
    Brad M.

    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.

  • Avatar
    Matt Savage

    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.

  • Avatar
    Mike

    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

  • Avatar
    Peter Hochstrasser

    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

  • Avatar
    Rebecca (Edited )

    Hi Peter!

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

  • Avatar
    Phil Holcombe

    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.

Please sign in to leave a comment.

Powered by Zendesk