Defining and using SLA policies

Return to top
Have more questions? Submit a request

197 Comments

  • Susan Maher

    Anais,

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

    0
  • Anaïs

    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

    Thank you Susan !

    0
  • Anaïs

    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

    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
  • Moe Priester

    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

Please sign in to leave a comment.

Powered by Zendesk