Defining and using SLA policies

Return to top

57 Comments

  • Patrick A Windsor II

    Hello, 

    I happen to log into my helpdesk over the weekend and noticed that a SLA was about to hit its limit, I initially ignored it assuming the countdown was paused as it was a Saturday and my schedule has the support desk "closed" on Saturday and Sunday. About 2 hours later I noticed that same ticket had -26m under its SLA, so I am confused why it's doing that. I have the SLA set to "Business Hours" and my schedule is set from 8:00AM - 8:00PM Monday through Friday. I have the SLA for this particular customer at the top of the list of SLA's and it is set to apply only to tickets where "Brand is Acme", which would apply to this ticket.

    Am I not understanding how the SLA's timers work?

    0
  • Lolu

    When are we going to have the option to create a trigger based on SLAs? We want to tag tickets and notify teams immediately an SLA is breached. We don't want to wait till a full hour when our support team operates in seconds

    2
  • Graeme Carmichael
    Community Moderator

    Jesuloluwa

    I think it unlikely that we will get a trigger notification based on SLAs. Triggers are designed to fire when an agent or a user updates a ticket. As you noted, automations are based on time but only fire hourly.

    For live monitoring of SLAs, Views sound like they better suit your needs. Here is an article on adding the SLA breach countdown to a view.

     

    0
  • Lolu

    Hey Graeme,

    Views will not suit our needs. Once an SLA is breached, we want to notify external channels like Slack to notify certain people that will take immediate action. 

    I think it's a basic feature really as I know other CRMs that offer this.

    1
  • Scott Allison
    Zendesk Product Manager

    Lolu I'm the Product Manager here at Zendesk responsible for our SLA capabilities. We recently kicked off an ambitious project to enhance our feature set in this area and I'm pleased to say that we are planning to provide near real-time notifications for SLA breaches. Look out for more on this later this year, likely in Q3. Really appreciate your feedback. Thanks.

    1
  • Zbyněk Čepera

    Hello,

    I have a question. Does business hours mean that time will be paused for all SLAs?For example: I set the Pausable update to 24 hours. Will time be paused outside of business hours?

    Thank you,

    0
  • Scott Allison
    Zendesk Product Manager

    Zbyněk ČeperaYes, that's right. Calendar hours would continue to run the clock as normal, but if you select "Business Hours" then SLA measurement pauses. 

    0
  • Kristin Bouveng

    I can't find a metric in the SLA dataset for Next Reply Time. 
    How do I report on this? 

    0
  • Scott Allison
    Zendesk Product Manager

    Kristin Bouveng First select any of the SLA metrics, then you can apply a filter for next reply time. For example: 

    1
  • CJ Johnson

    What happens to historical reporting on an SLA if you delete a policy? 

    1
  • Justin H

    Hi CJ, 

    It looks like if you delete an SLA policy, the data for it in Explore will stay on all tickets the SLA policy was applied to. The only difference I am seeing after testing in my account is that you are unable to open the ticket links for tickets the SLA policy was applied to. 

    Hope this helps!

    1
  • Terry Knox

    Completely baffled by the behaviour of SLA policies when tickets reopen - see bold text below: 

    • Periodic Update: If a ticket is reopened with an end user comment, nothing will happen. If a ticket is reopened, with or without an agent comment, the relevant Update metrics activate new targets.
    • Pausable Update: If a ticket is reopened with an end user comment, nothing will happen. If a ticket is reopened with a public comment from an agent, the relevant Update metrics activate new targets.

    What's the thinking here? Surely if a ticket reopens, the update SLA targets should appear again? Some action is expected from the agent in almost all cases, right? Am I missing something? Is there a workaround? 

    0
  • Justin H

    Hey Terry Knox!

    The use case for these two SLA targets are for agent created tickets. If an agent makes a ticket proactively, then the first reply time and next reply time targets are not applied to the ticket, so these SLA targets hold the agent accountable for updates to your end users. In order to also include End User replies that reopen the ticket, you could add the Next Reply time target to your SLA policy so that a target is applied regardless of who reopens a ticket. 

    I hope this helps!

    0
  • Terry Knox

    Justin H - Presumably I can "layer" on Next Reply Time in addition to the other options, to catch cases like this? I'd still want Periodic/Pausable Update to be policies used in almost all other cases. 

    0
  • Justin H

    Terry Knox

    Yeah, that's right. The screenshot below is the test I did in my account, and after reopening the ticket with an end user comment, the NRT target was applied. When the agent replies, then the Periodic Update is applied. 

    0
  • Terry Knox

    Thanks! 

    0
  • Martin Cubitt

    Hi all,

    I wanted to set up SLA Alerting at 25, 50, 75 and 95% progress using Automation. As if the limit of hourly automation was not enough of a problem, I then find out that the Automation condition 'Hours until next SLA Breach' will not be met if the ticket is status Pending. So if the ticket is open for 55 minutes every hour but by some coincidence is pending for the other 10 and when Automation runs, the ticket will breach with no warning whatsoever.

    Does anyone have any suggestions or products to help manage SLA Alerting as clearly Zendesk is not up to the job.

    Thanks

     

     

    1
  • Brett Bowser
    Zendesk Community Manager
    Hey Martin,

    This is something our product managers are looking to improve so I'd recommend taking a look at the following announcement: An easier way to see upcoming SLA breaches
     
    You'll want to take a look at this comment in particular. 
     
    Not sure if anyone else has a workaround but I did want to make you aware that we are listening to your feedback :) 
    1
  • Scott Allison
    Zendesk Product Manager

    Martin Cubitt Just to add to Brett's reply above, until Zendesk supports real-time alerting natively I'd recommend you check out one of our partners to provide this functionality: https://sweethawk.com/

    0
  • Sacbe Alfonsina Ibarra E

    Hi! When are you planning for SLA policies to support chat or messaging tickets? Those are extremely important channels for us your Latam customers. It's more common for us to use chat/messaging than calls/email.  

    1
  • Scott Allison
    Zendesk Product Manager

    Sacbe Alfonsina Ibarra E Thanks for the question! We do have plans to fully support SLAs in our Messaging product late this year. There are no plans to support it in Chat. For more details or updates you may wish to follow this other thread.

    0
  • Mark Szymanski

    The article states "For SLA policies to work, tickets need to have a Priority value. If you do not set a Priority then none of your rules will be met."  This makes sense because in the SLA policies, the targets are specific to each of the 4 priorities.  However, when I view the event history of individual tickets without a priority, they've had SLA policies applied, at least some if not most or all of the time. 
    Is that statement incorrect or outdated?  Does the handling default to Normal even if the field holds no value?
    I intend to add a trigger (or modify existing ones) to cover this, but I'm really curious about what causes those w/o a priority to still have an SLA policy applied.

     

    0
  • Beto
    Zendesk Customer Care

    Hello Mark, thank you for your question!

    It is true that the Events will show that the SLA has been "applied" but in truth, it is not being applied correctly if the ticket has no priority. The events show that a specific SLA has been assigned to the ticket, because the ticket meets the SLA's conditions. But until a priority is set, no timer or SLA badge will appear, meaning that no SLA clock is actually being counted yet. 

    It is best to always apply the priority, either manually or via a business rule as you mention. The fact that an SLA is seen in the events does not mean that actually being measured currently on the ticket, only that the conditions for that SLA have been met. But without a Priority, it will not work correctly. 

    I hope this was helpful!

    0
  • Mobyfox Customer support

    Hello Customer care team!

    I am following the steps to set start setting up SLA's but I don't seem to have it? Maybe my level of access?

    Please see above where Business rules > Service level agreements. is missing, 
    Please inform me as to why? A little new to setting up here, 

    Many thanks!

    0
  • Scott Allison
    Zendesk Product Manager

    Mobyfox Customer support Thanks for the question! The first thing to check, is take a look at the top of this article which highlights which plan types includes SLAs. If you need more help feel free to reach out to our support which you can do by clicking on the chat icon bottom right on this page.  

    0
  • Ronald

    What happens with a breached SLA target when the submitter incorrectly labels a ticket which results it being routed to the wrong ticket group?

    Example - A ticket breaches the first reply SLA when assigned to ticket "Group A" and then gets reassigned to ticket "Group B". Does that First Reply SLA breach now count against Group B or does it stay with Group A? Both Group A and Group B have a First Reply target in their SLA policies.

    Or can the answer to this depend on how the specific SLA report is configured? I'm using the default Support- SLAs dataset and looking at the "SLAs" tab of the pre-built Explore dashboard. I'm not very familiar with the Support - SLAs dataset. 

    0
  • Dane
    Zendesk Engineering
    Hi Rich,
     
    Unlike updates history, SLA dataset will just record the met/breached target. The group or assignee associated with it will always be the one showing in the Assignee field and not the group/assignee that was associated with it when it was met/breached.
     
    For more information, please check SLA datasets.
    0

Please sign in to leave a comment.

Powered by Zendesk