Using Enhanced SLAs

11 Comments

  • Jennifer Rowe
    Comment actions Permalink

    Mathew, this is a great tip! Very useful info for other users who want to set up SLAs. Thanks for sharing it!

    0
  • Francisco Yamauti
    Comment actions Permalink

    Hello Mat! Thanks for the insights!

    From your example I get the notion that you guys are operating across time zones as well, were you able to set up different business hours rules for it to work independently ? (so that no matter what country the service is being tackled on, it would make sense to the agent's schedules) 

     

    0
  • Mat Cropper
    Comment actions Permalink

    Hey Francisco!

    We operate on the basis that every shift should cater to every skill set. Our primary skill is language based, and so if I'm an agent who supports Chinese language tickets, for example, there's a peak in traffic overnight from mainland China, and then later in the day there's a steady stream of tickets from Chinese speaking players in the USA and Europe.

    That being the case, we plan to have every shift staffed with agents skilled in each of the 15 languages we support. Based on that, we decided not to have timezone-specific SLAs, but instead to structure our tickets based on channel and certain custom fields (player needs based, if you're interested!).

    We don't always get it right, of course. When we get failed SLAs, for example a bunch of breached SLAs for Chinese tickets, we take that as an indicator that our shift planning failed. Were there the right agents on the shift? Were there too few?

    Hopefully, that's helpful for you!

    0
  • Francisco Yamauti
    Comment actions Permalink

    That makes a lot of sense =) 

    We will run some tests here to tweak around biz hours, but I'm pretty positive it will work pretty similar to what you guys have over there. 

    Cheers =D

    0
  • Lisa Painter
    Comment actions Permalink

    Great post...thanks!   When I lead a support team many years ago, we had some strict SLAs and we printed them out on a pyramid (made out of paper) that sat on their desks.  We had response and resolution SLAs, so we used two sides of the pyramid for the details and used the 3rd side for our mission statement.  I guess today, there are more people working remotely sometimes, so having it centralized online some place is good too.  :)

    0
  • Amy Waugh
    Comment actions Permalink

    Can you get SLAs to work on reopened tickets that have been solved?

     

    As we have some customers who reply to a solved ticket about another query.

    0
  • Brett - Community Manager
    Comment actions Permalink

    Hey Amy,

    Can you clarify which SLA targets you're looking to use with re-opened tickets?

    Any additional information you can provide is greatly appreciated :) 

    0
  • Amy Waugh
    Comment actions Permalink

    We have first reply time, next reply time and pausable update on the same SLA.

     

    I would understand the first reply time not working for recently opened tickets from being solved but the other two.

    Would I have to add a criteria to the SLA for these to generate? 

    0
  • Brett - Community Manager
    Comment actions Permalink

    Hi Amy,

    As you mentioned, FRT would not be factored in assuming your agents already submitted their first public response on this re-opened ticket previously.

    However, if the ticket is re-opened then Next Reply Time and Pausable Update should automatically continue without you have to set up new criteria.

    Let me know if you experience anything different on your end.

    Thanks!

    0
  • Amy Waugh
    Comment actions Permalink

    Hi

     

    We have had a ticket responded to within the first reply time but the ticket got solved at the same time.

    The customer replied to the ticket, opening it back up but the SLA have not shown to resume the next SLA that it should encounter.

     

    The ruling of our SLA is 

    Channel - Email

    Tags contain none of u_no_notification, t_wpd_no_notify, t_solved_no_notification, t_deleted_ticket.

     

    FRT - 9 business hours

    NRT - 9 business hours

    PU - 27 business hours

     

    The relevant ticket has the following tags

    t_annual_leave, t_email_query, t_hrandpayroll_email, t_reopened

     

    I'm not sure why this is not continuing with the SLA

     

    0
  • Dan Cooper
    Comment actions Permalink

    Hi Amy,

    I would take a look into the events of your ticket to see if there is anything out of place.  Are some of your blocked tags on the ticket at any time?  Is the Priority field still populated?  Is there a schedule applied?

    Hopefully that gives you a few things to check into. It may be worth opening a ticket with that as an example for Zendesk to walk through it and see if they can identify where the SLA should have fired. 

    0

Please sign in to leave a comment.

Powered by Zendesk