Defining SLA policies

Return to top

104 Comments

  • Anaïs France

    Hi there !

    I read that the Next reply metric begins with the oldest unanswered customer's comment.

    Does the term "customer" mean any end user, not necessarily the requester ?

    That is, CCs added by the requester or by an agent, as well as other person sharing the ticket in case of shared organization ?

    0
  • Susan Maher

    Anais,

    I believe that the clearer answer is a public comment entered by an end user.  

    0
  • Anaïs France

    Ok, thanks Susan.

    When an end user enters a comment, does the ticket status automatically becomes open (from pending or on-hold) ?

    0
  • Susan Maher

    Anais,

    Yes, the ticket will go back to open.  Regards, Susan

    1
  • Anaïs France

    Thank you Susan !

    0
  • Anaïs France

    I am using the pausable update metric and I would like to have it paused while the dev team is working on the issue (for a bug fix or a new feature implementation), after having given the time estimate to the requester. I’m tempted to put the status to pending, but if the requester or CC goes to the portal, the ticket would look like we are awaiting the requester’s reply. What if I add a condition to my SLA policy like ”type is not task”, and set the type to task or add a tag, then reset things once the dev team has finished ? Would that pause the SLA clock ?

    What would be the best practice ?

    0
  • Susan Maher

    Anais,

    If you add a condition to your policy such as checking if Type is Task and then setting the ticket to Task, the Policy will then will apply only to tickets that are not Tasks.  This will stop the SLA all together until you change the ticket back to Problem or Question. 

    This will certainly accomplish what you need to do.  However, you need to consider the following:

    1. If the ticket takes a long time to resolve (I do not know the nature of your business so I apologize if my assumptions are wrong), it is possible the ticket will be forgotten and the customer will not get any updates for a long period of time

    2. If during the time the ticket is in development being fixed the customer writes back to request status, there is a chance the ticket could be missed at least for a while. 

    Having said that, if you already have processes in place to avoid these, the solution above is correct.  Good luck.  Susan

    0
  • Anaïs France

    Thanks for your reply Susan.

    I must confess that I don’t see any big risk in stopping the SLA while the issue is in development, and we consider not necessary to give periodic updates in this case (since there’s not much to communicate).

    1. I’ve made a view of all the task tickets, and I think we could avoid forgetting these tickets by sending an alert with automation using the “hours until due-date” condition, at least for the tickets for which we can set a due-date.
    2. If the requester or another end-user writes back during this period, I understand that metrics such as next reply wouldn’t apply, but otherwise, I don’t see why we would miss this ticket if the assignee doesn’t ignore the update notification.
      Besides, we could set a separate SLA for the update metric and add the condition only to this set of SLA so that other metrics wouldn’t stop. ?

    Am I missing something ?

    Anyway, I would love to learn how Zendesk and other companies deal with this.

    0
  • Susan Maher

    Anais,

    Sounds like you have it covered so it should work  Again, I do not know your processes.  I believe it should work.  it is a great solution.  I believe a cleaner solution than what I actually implemented. 

    0
  • jonathan.panka

    Would be nice if you can test a SLA Policie

    0
  • Susan Maher

    Jonathan,

    You have a couple of ways of testing SLA policies.  One way is to use a Sandbox System.  I set up all my work in the Sandbox first and test there before implementing in production. 

    However, that is a paid option.  So, if your organization doesn't have a Sandbox System then you can control the SLA policy via tags or a custom field that you can test for.  This way the SLA will only be in effect for those tickets that contain that tag or Custom field set. 

    Once you create your policy you can then create test tickets, notifications, etc based on that criteria and test that way. 

    I hope this helps.

    0
  • Oli

    Hey team,

    Wondering if there are any updates on previous feature requests for a first reply-time SLA that behaves like the first reply-time metric? We have a few use cases for tracking, via SLA, how long an agent has to make the first public comment on a ticket that only has one internal comment.

    I found links to some other community guide posts asking for the same thing, but got an access denied error on all 3 pages so I'm assuming they've been deleted by the original posters or moved somewhere else.

    Thanks!

    4
  • Jim Cobb

    How do you do a "Resolution time" SLA? Our SLA require that a ticket be resolved in X amount of business days depending on the importance of the ticket. Urgent must be resolved in 1 business day.

    0
  • Susan Maher

    Jim,

    You may want to consider using Agent Work Time. 

    Otherwise it will get complicated.

    0
  • Amanda Gunn

    What is considered part of calendar hours? Are weekends and holidays excluded or are those only excluded in business hours?

    We want to set our business hours to 8am - 5pm, Monday - Friday.

    Our first reply time metric is within 24hrs.  Tickets submitted on Friday should not breach SLA on Saturday, but on Monday if not responded within 24hrs from Friday time.

    I have the SLA set to 24 calendar hours for first reply time metric.

    0
  • Susan Maher

    Amanda, 

    SLA can be defined as Calendar hours or business hours.  Calendar hours means that SLA assumes that you are going to respond 24x7 and therefore SLA will breach on any day of the week whenever the SLA reaches the time you allotted for the response.  

    In order to use Business hours you need to set a schedule.  To set a schedule you need to go to Settings and click on Schedules..  You then can add your Schedule with the hours you indicate above (M-F 8-5) You also can add Holidays to the schedule.  

    Once you define the schedule, you may change your policies to calculate the SLAs in business hours rather than calendar hours.  SLAs then will breach on weekdays rather than outside your business hours.  I hope this helps.  

     

    0
  • Amanda Gunn

    Thanks Susan. Yes, I have that all set up. I was hoping that calendar hours didn't take in to account weekends and holidays.

    Changing it to business hours for the SLA would result in a much longer timeframe (24 business hours) that isn't exactly what we are held to.

    0
  • Susan Maher

    Amanda,

    While the system only give you those two choices, you can get creative.  You have the ability to define your schedule however you desire.  Therefore, if you would like to have SLAs breach anytime during the week but skip weekends, then define the schedule accordingly.  Additionally, you may have more than one schedule.  

    However, once you have more than one schedule, life gets more complicated because you will have to create triggers to set the schedule according to the correct criteria.  It will depend on your use case.  

    Unfortunately, the way SLA is set up "out of the box" is rather simplistic and doesn't allow for much creativity.

    We have a rather complicated scenario, but I had to do a lot of work.  

    Good luck! 

    0
  • Rylan R

    Hi,

    How do we track the next reply time if there is no metric on zendesk explore to track this?

    Regards,

    Rylan Roach.

    0
  • Gab Guinto
    Zendesk Customer Care

    Hi Rylan,

    If you're referring to the SLA dataset, then you should be able to report on the status of Next reply time SLA targets in Explore. But, if what you're looking for is to build a granular report to show the duration between each agent replies within a ticket, then I'm afraid that's not possible with the native metrics and attributes currently available in the SLA dataset, and any other datasets in Explore. Sorry about this limitation, Rylan.

    -1
  • Rylan R

    Hi Gab,

    Thanks for your reply but there isn't really a metric for the Next reply time on Explore. If there is please let me know which metric I need to use to create a report for this?

    0
  • Gab Guinto
    Zendesk Customer Care

    Hi Rylan,

    You can try using the metric SLA tickets (in the Support: SLAs dataset) and then filter or slice your report by the attribute SLA metric. You can set your report to display only the SLA tickets with the target Next reply time.

    From there, you can further slice your data by SLA metric status (Active or Inactive), SLA target status (Achieved or Breached), etc. You may refer to this article to see all the metric and attributes available for SLA data: SLAs dataset.

    0
  • Jorge Moreno

    Hi,

    Is there a way to track SLA's after a ticket is escalated (assigned to a particular group)? We escalate complaints after solving some incidents, and we want to be able to set SLAs (first reply and resolution time) for those tickets from the moment the escalation happens.

    Thanks!

    1
  • Rylan R

    Hi Gab,

    Thanks for sharing this. Is it possible to get the actual value for the Next Reply like how we have for the First Reply Time rather than just knowing where it was achieved or breached?

    0
  • Rafael

    Hi Jorge,

    You can track the SLA's ticket by using the SLA attribute Ticket group along with the SLA policy name. Regarding setting the SLA after the ticket is escalated is not possible as the SLA counts the interaction with the requester (most of the time customers). If you want to have a new first reply and resolution time metrics applied, a new ticket will need to be created for the new team.

    Hi Rylan,

    Since the Next reply time is the time between the oldest unanswered customer comment and the next public comment from an agent, displayed in minutes., you can use the attribute Requester wait time (min/hrs/days). That will measure the number of minutes a ticket spends in the New, Open, and On-hold statuses. This number is only measured after a ticket status is changed from New/Open/On-hold/Pending/Solved/Closed.

    Rafael

    0
  • Dominic

    Hi,

    Is it true that you cannot apply SLAs to tickets created via the API. Is there a workaround for this?

    Regards,

    0
  • ZZ Graeme Carmichael
    Community Moderator

    Dominic

    Tickets created via the API will have the SLA policies evaluated the same as any other ticket. So there should be no workaround needed.

    An SLA policy can have a 'channel' condition so that it only applies to tickets created via the API or never applies to tickets created via the API or relates to another channel. That may be causing the confusion.

     

    1
  • Scott Allison
    Zendesk Product Manager

    One thing to note about API created tickets, if the initial comment is a private note (which is fairly typical) then reply time metrics will not be evaluated.

    0
  • Patrick Rieger

    Hi, 

    is there any way we can avoid breaching requester wait time SLA in case a requester reopens a ticket by making another comment? For example, if a ticket has initially been created a few weeks ago and resolved. If the customer makes another comment, the ticket would breach the requester wait time metric instantly (as the ticket creation time is relevant for this metrics). Do you maybe have an idea? 

     

    Best, 

    Patrick

    0
  • Dominic

    Patrick Rieger, it might be that you're not setting your tickets to Closed, rather leaving them in Solved status? 

    If you do set the automation to close tickets after a certain period of time, even if customers reply to the same email, a new ticket would be created instead of re-opening the same one. This would solve your issue.

    Hope this helps.

    Kindly,

    Dominic

    -1

Please sign in to leave a comment.

Powered by Zendesk