Defining and using SLA policies (Professional and Enterprise) Follow

Comments

99 comments

  • Avatar
    Ravi Kant Verma

    Can we create a report that shows us the %age of time we met the SLA. For example. I have a SLA which says all sev1 needs to be replied within 1 hr.
    To find how are we doing with our response time on sev1 tickets can we create a report that would show that we are meeting the SLA X% of the times ?

  • Avatar
    Ravi Kant Verma

    Erin sorry I did not see your response above about the SLA dashboard. Is it something I can see on my account ? The screenshot looks very promising. I would be interested to test it.

  • Avatar
    Erin Boyle

    Hi Ravi,

    It's not yet available as we're still working on it (that screenshot is just a mockup). That being said, you should hear from me in the new few weeks with an update. :)

    Best,
    Erin

  • Avatar
    Matt Peters

    I notice that the Schedules are not available for selection when creating an SLA. Is this planned for the future?

    We have different ticket "Business Hours" (hence Schedules) for different SLAs, and therefore need to tie the response times into the Schedules, rather than the standard Business Hours or Calendar Hours. Hence the requirement to use the Schedules in the SLA.

  • Avatar
    Erin Boyle

    Hi Matt,

    If your SLAs are set to use business hours, they will use the schedule that is set on the ticket. Make sure you have triggers in place to set schedules on tickets, and the SLAs will work from there.

    Best,
    Erin

  • Avatar
    Matt Peters

    Ahh, got it. Thanks. I'll give it a try.

  • Avatar
    Ola Timpson

    Finally started playing with this today, but struggling with the First Reply Time option. A large number of our tickets are logged on behalf of a customer (sometimes by agents located elsewhere), and we still need first reply to these within 2 hours. What I don't understand is why the SLA timers work differently to the First Reply Time metric (https://support.zendesk.com/hc/en-us/articles/205951808-Calculating-first-reply-time) - the metric works perfectly for us in treating the initial description as separate to a reply.

  • Avatar
    Sol Accinelli

    +1 for Ola's comment.

    We want to start sorting Open tickets based on the SLA policies, but we are afraid that the rule will leave out all the tickets where the agent has created it on behalf of the requester. Our policy is that all tickets must be replied in 24hs, and for all the other cases we are using the "Next reply time" metric.

    From what I understand, using the Resolution time metrics (either Requester wait time, nor Agent work time) won't be useful in the case of agent generated cases, as that metric is the sum of all the time a ticket sits in the Open and New state, and it would hurt all the other tickets, for example, where the "Next reply time" was just 1 hour short of being breached. In this example, the next time it opens again the agent would only have 1 hour to avoid missing the Resolution time metrics. How could we avoid this?

    As Ola is saying, the First Reply Time should be able to tell apart the cases where the description was submitted by the agent on behalf of the requester, and still count that SLA.

  • Avatar
    Erin Boyle

    Hi Ola & Sol,

    We made the conscious decision to have the first reply time metric not include a first comment/description as made by an agent. For the majority of our customers, this is actually the desired behavior. However, I do understand it's not desired in your particular use cases. Unfortunately I don't have a workaround for you at this time, but will keep this in mind going forward.

    Best,
    Erin

  • Avatar
    Sol Accinelli

    Hi Erin! Thank you for your reply!
    I thought of a workaround that (I hope!) will accomplish what we need. Could you please review it and let me know if it makes sense? The basic idea is that we need to create a rule that excludes the tickets where the requester created the ticket, so that the SLA policy for agent-generated-tickets doesn't affect their metrics.

    Whenever a ticket is created by an agent in the Open state, a tag will be applied by a trigger, something like "agent_counter". We will then set up an SLA policy stating that all tickets created not by email and that have that "agent_counter" tag will have an SLA of 24hs for Agent work time. We will then set up another trigger so that if the ticket changes its status to Pending, it will delete the tag "agent_counter". This way, if the requester replies and opens the ticket again, the global SLA policy will be applied (24hs until next reply).

    Right? What do you think? I believe this could be a solution.
    Thanks in advance,
    Sol

  • Avatar
    Ola Timpson (Edited )

    Thanks, Sol. Your idea has helped me think about it. In our case the trigger would have to remove the tag on public comment, as sometimes the comment is escalating.

    Erin, I can see why the decision was made for the SLAs, but it does seem weird having it inconsistent with the metric definition (which never counts the initial description as a reply). I think maybe it's because our setup has agents in different teams, but one team always has to reply within 2 hours regardless of source.

  • Avatar
    Terry Knox

    Something I'd like to check - if a ticket is created by a Light Agent forwarding a customer email, will that affect the "first reply time" SLA? Ideally, stuff forwarded by Light Agents wouldn't count as having been responded to until a "real" agent replies.

  • Avatar
    Erin Boyle

    @Sol - if you're main goal is simply for agents to be able to view the clock, I think this will work. If you want to be able to report on these things once we introduce Insights for SLAs, this approach will not work, unfortunately.

    @Ola - we actually have plans to go back through all ticket metrics and update them. This will include changing the first reply time to be consistent with SLAs.

    @Terry - If the Light Agent forwards the customer email and agent forwarding is turned on, the first comment will actually come from the original customer who emailed the Light Agent. So you're right—the first reply time counter will start and wait for an agent reply.

  • Avatar
    Terry Knox

    Thanks Erin - we do indeed have agent forwarding on.

  • Avatar
    Ola Timpson

    Thanks Erin, if the metrics change to match then it gives me an excuse to update our processes to fit!

  • Avatar
    Mike Burns (Edited )

    Hi I have a question of ow I can set up my SLAs.

    I have reply to customer in 2 hrs and fix in 4 so how would i set this up with the new SLA's as in which fields would you enter this data

    Thanks

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

  • Avatar
    Terry Knox

    Really disappointed to see I can't define SLA policies based on an "empty value" for Organization - especially given you can do so for Triggers, Automations, Views and Insights metrics. :(

    Does this affect anyone else? I've made a feature request to reflect this: https://support.zendesk.com/hc/en-us/community/posts/205240698

  • Avatar
    Brian Gibson

    I would like to create an sla for time between updates in the open status, is that possible? ie: I want my agents to update tickets every 6 hours if they are in open status, not dependent on who the last comment came from.

    So, we might respond to the customer and leave the ticket open stating " we are working on this issue and will update you shortly", and leave the status as open, resetting the timer to 6 hours. in 4 hours we provide an update of "we are almost done here and will update you once your problems is solved. The sla would again, reset to 6 hours.

    Is this possible?

  • Avatar
    Erin Boyle

    Hi Brian,

    This isn't possible... yet. That being said, we're actually finishing up a brand new metric right now that we'll call "Periodic Update," and it will do exactly what you're looking for. I'll be sure to update you all once it's finished, tested, and rolled out!

    Best,
    Erin

  • Avatar
    Brian Gibson

    Amazing. Do you have a rough eta you can give?

  • Avatar
    Erin Boyle

    Not just yet, unfortunately. We still have a few last pieces to build out, so probably on the order of months. I'd love to get this out before the end of the year, and I think it's reasonable, but that is very much subject to change.

  • Avatar
    Baber

    Hi Erin,

    I would like to send agents periodic SMS notifications if a ticket is within 3 hours of breaching SLA.

    Is it possible to use the REST API to retrieve information on Next SLA breach for a ticket? I understand this information is not available at the ticket level, but it is available in the view - is it exposed via the API?

    Failing that, is it possible to manually calculate 'Next SLA breach'?

    Thanks,

    Baber

  • Avatar
    Corrin Duque

    Similar to Gary, we also want to be able to use triggers/automations to notify agents that we are nearing a breach of SLA respond within 1 hour on Urgent. We would at a minimum want to have agents notified at the 30 min mark. Without this we have no proactive action that helps us meet our SLA of responding in less than 1 hour. Is there a work around for this?

  • Avatar
    Erin Boyle

    Hi all,

    No, there is no current workaround for this built into the product. We are, however, exploring options for more timely SLA notifications in the future. To Baber's point, though, there are a few API options you may want to know about.

    We have an incremental endpoint for SLA breach and fulfill events: https://developer.zendesk.com/rest_api/docs/core/ticket_metric_events

    We also have 2 different ticket side-loads available: https://developer.zendesk.com/rest_api/docs/core/side_loading#supported-endpoints

    • The slas sideload displays the next SLA breach for that ticket, along with what metric it corresponds to
    • The metric_events sideload is the same information available in the incremental endpoint, but for that single ticket

    Hope this helps!

    Best,
    Erin

  • Avatar
    Yoav Brog

    Hi,

    Can I get SLA data at a ticket level through the API?
    Such as: time to next breach (inc. which policy), breaches that already occured, etc.

    Thanks,
    Yoav

  • Avatar
    Erin Boyle

    Hi Yoav,

    The incremental endpoint and the sideloads I mentioned in my last comment are your best bet to get that information. The slas sideload gives you the time to next breach for all metrics on that ticket, and the metric_events sideload will show you the history of ALL metrics on that ticket, including breaches.

    Best,
    Erin

  • Avatar
    Yoav Brog

    Thanks Erin!

    I'd require both upcoming breaches and historical so the metric_events sideload sounds like something that could work.
    What's the difference between the sideload and the regular ticket_metric_events?

    Best,
    Yoav

  • Avatar
    Erin Boyle

    @Yoav - the sideload will restrict the events to that specific ticket, whereas the regular ticket_metric_events is an incremental endpoint that shows all events across all tickets.

  • Avatar
    Erin Boyle

    Hi all,

    Just wanted to let you know we've just added a new metric called "Periodic Update." This allows you to set a time limit on how often you need to respond to a customer. For example, you may choose to update customers on high priority tickets every 4 hours, or even every 30 minutes. The metric begins after a first public reply, and the timer will reset itself after every public response to a ticket.

    Happy Thursday!
    Erin

Please sign in to leave a comment.

Powered by Zendesk