Defining and using SLA policies (Professional and Enterprise)

Have more questions? Submit a request

136 Comments

  • Brian Gibson
    Comment actions Permalink

    Craig - I've had conversations with Erin about this as well - ideally, we would be able to have a custom SLA that lets us determine which status's it runs in, but until then, something that doesn't run in pending or on-hold would solve most of our problems.

     

    thank you!

    0
  • Jeff Callahan
    Comment actions Permalink

    Craig - thanks!

    I implemented the following...

    1. Modified all SLA's to run when Tag does not contain "No_SLA"
    2. Trigger to add the tag "No_SLA" when the Ticket is changed to Hold or Pending Status.  
    3. Trigger to remove the tag "No_SLA" when I ticket is re-opened.

    This seems to be working fine

     

    0
  • Vinay Sharma
    Comment actions Permalink

    Hi Erin,

    Is the reporting dashboard available within the format/ screenshot you has illustrated within an earlier post? It looked slick as an 'at a glance' view and exactly what I am looking for.

    We have setup our ticket SLAs and breach alarms, however, are really struggling with setting up the associated Dashboard view to see how we are trending against our initial and follow-up response target times - as a number and percentage reflection. Is there an intuitive 'How To' document that guides clients upon the dashboard setup and views?

    Not sure if anyone else has had any similar challenges and successfully resolved them? 

     

     

    0
  • Jake Holman
    Comment actions Permalink

    @Vinay: Ah, that's an old mockup of what the Insights dashboard might have looked like. We have an article which explains how to get started on that, I hope it's helpful.

    0
  • Brian Gibson
    Comment actions Permalink

    Jeff - Tried your suggestion, but I have problems with it.  I use Next response, and First Response SLA's, and your method conflicts with it, instantly sending my slaps into failure.  This didn't happen in the past before the periodic sla change zendesk made.. Guess I'm back to waiting for a solution from zen!

    0
  • Jeff Callahan
    Comment actions Permalink

    Brian - hmmm I do not understand why there would be a conflict?

    We also use First, Next and Periodic SLA's.  

    When/If the ticket re-opens due to Requester response the SLA is reactivated via Trigger (tag removed) and the ticket is then subject to the Next response SLA.  

    When/If the ticket re-opens due to a trigger then the Periodic SLA is immediately expired.  However we have an Automation to close our non-Urgent Pending Tickets after 5-days of no response so most Auto Close.

     

    0
  • Jennifer Robichaux
    Comment actions Permalink

    Have there been recent changes to the SLA metrics?

    Our team has been using "Agent work time" to track how soon a ticket gets a call back after being moved into a "Open" status (with other relevant tags). It used to be that the time until next SLA breech would start at the moment that the ticket was put into Open. Now we're finding that the time is calculated from when the ticket was created (ie since it was New), but this is not how we set things up, and it's causing some reporting problems for us.

    Was the "Agent work time" metric changed? Is there any other metric we could use to accomplish our goal?

     

    0
  • Craig Little
    Comment actions Permalink

    Jennifer,

    There haven't been any recent changes to the Agent Work Time metric. Please submit a ticket with examples of the issue you're experiencing, and we'll investigate.

    0
  • Gadi Vered
    Comment actions Permalink

    Craig - what is the update on the new Metric you mentioned on October 03, 2016 15:55 for Periodic Update?

    0
  • Craig Little
    Comment actions Permalink

    Gadi,

    It's been built for a couple of months now, but unfortunately, it's been tied up by a third-party integration issue. We have people actively working to get that resolved, so it should hopefully be made available in the next couple weeks or so.

    1
  • Brian Sorensen
    Comment actions Permalink

    This is promising.. I'm having a hard time however, apparently nothing has breached my SLA.  I know I have tickets that are breached.

     

    Here is the rule I have set for testing this.

    All new tickets that come in go to our Unsolved Group and are automatically marked URGENT

    The SLA condition is

    Ticket Status is Unsolved

    Target

    FRT - Urgent - 3h, High -4h, Norm - 5h, Low -6h

    I have tickets in the system that have not been responded to in over this threshold, but the SLA is not breached?

     

    any insight?

    0
  • Andrew J
    Comment actions Permalink

    Hello Brian - just a possibility, but do you have any other SLAs set?  A ticket can only work on one SLA, so the first one in the list that it meets the conditions for is the one it will be measured by.  I got caught on that once.

    0
  • Zac
    Comment actions Permalink

    Having a bit of trouble with SLAs on certain edge tickets.

    There are cases where one of our frontline agents might send a public reply to a customer, thus meeting the SLA, but then they need to reassign the ticket to another internal team to carry out some action. When it hits that other team's view, it shows up without an SLA so it is moved toward the back of the list.

    Wondering if there is a way to optimize our workflow so as not to miss these tickets (right now, I know there's no way to get the SLA re-applied as there was no follow-up comment from the customer).

    0
  • Arturo
    Comment actions Permalink

    @Zac, take a look at the Periodic update or the new Pausable udpate SLA metrics.

    If an agent needs to assign a ticket to another team/agent after informing the ticket requester about that with a public reply, using any of those metrics the agent would only need to submit the ticket as Open, instead of Pending or Solved, when answering to the customer to keep the next goal SLA counter active and then assign to the proper team/agent without updating the ticket status.

    Hope this helps!

    0
  • Tim Cambra
    Comment actions Permalink

    Have a question. We are running into a issue where a couple of our SLA's are voiding each other out based on the order the SLA is set under the configuration and i dont know why. Basically i have 2 SLA's setup. 1 is our First Reply Time and the other is our Next Reply Time. Both have the same conditions but the Next Reply Time looks for existing tags. If i change the order of the SLA  "Next Reply Time" to the top of the list it works, but then the "First Reply Time" SLA wont. If i move the "First Reply Time" SLA down in the order it does not trigger. Does anyone know why this would be occurring? Have i done something wrong? Or can we only have 1 SLA for both First Reply Time and Next Reply Time?

    0
  • Craig Little
    Comment actions Permalink

    Tim,

    Only one SLA policy can be associated with a ticket at a time. If you want both First Reply Time and Next Reply Time to be tracked on the same ticket, those targets must be configured as part of the same policy.

    1
  • Tim Cambra
    Comment actions Permalink

    Thanks Craig for the explanation. Thats too bad it works like that.

    0
  • Mike
    Comment actions Permalink

    Is it possible to set an SLA timer based on the time since a specific event?

    I'm looking to set an SLA that tickets escalated between service tiers.

    I want to start a timer from the time the ticket is escalated by an L1 agent, that dictates how long the L2 agent has until they must reply.

    I can't seem to find anything that lets you start an SLA timer based on a specific event, such as a tag being added to a ticket.

    Any suggestions?

    1
  • James Sanford
    Comment actions Permalink

    Hey Mike!

    It is not possible to set an SLA timer based on a specific event.  However, as you've pointed out, if you want to you can use a ticket tag as a condition for your SLAs.  If that tag was not present prior to that update then you would essentially be causing the SLA be applied based on that event.  If this tag is being added when your agents escalate their ticket then this should meet the conditions you are looking for the SLA to be applied to.  

    I would caution however, that there are not any SLA Targets that would fulfill your criteria here in stating there is just an SLA for the next L2 agent reply.  The only option I can foresee being used for that is Periodic Update which would continue applying the SLA requirement for every update.  First reply time would not be applicable for a ticket of this nature.

    0
  • Daniel Halsall
    Comment actions Permalink

    Has "hours of operation" been removed from the Targets? I do not have this option when I make SLA's

    0
  • Leandro Vasconcelos Sava
    Comment actions Permalink

     

    Hi Daniel

    First you need to enable business hours in order to see it when setting up SLA's.

    Click the Admin icon on the side bar >> Settings >> Schedule >> Enable.

    You will then see the option when setting up SLA's as showing on the image below:

     

     

     

    0
  • James Green
    Comment actions Permalink

    Hi,

    Is it possible to set conditions based on the ticket's requester's custom user fields, instead of just ticket fields? For example, our Single Sign-On payload includes some fields like Billing Cycle and Account Type.

    I want different SLA policies for different account types, e.g. First-Reply Time should be X for Business users, Y for Pro users, and Z for Free users.

    As a workaround, I also pass Billing Cycle and Account Type as tags during SSO and keep them in sync using automations. I suppose I could ALSO have custom ticket fields and set up some triggers, but that seems a bit overkill.

    Side question: If user's tags change (whether manually by an agent or automatically from an automation or a new SSO payload), do the existing inherited ticket tags also change?

    Thanks,

    James

    0
  • James Sanford
    Comment actions Permalink

    Hey James!

    Yes, custom user fields can be found in the SLA conditions drop-downs when configuring your SLAs.  Configuration options in these drop-downs are grouped so you should find a Requester section after your Tickets section.

    User tags are only passed on ticket creation so an update after the creation event will not retroactively affect existing tickets.

    0
  • James Green
    Comment actions Permalink

    Thanks James,

    I see the Role field under Requester, but no other user fields - default nor custom.

    SLA screen:

    User screen:

    0
  • James Sanford
    Comment actions Permalink

    Hey James!

    My apologies, it does appear you're not seeing that option in your account.  I'll go ahead and bring you into a ticket at this point so we can further troubleshoot this.  Also, I'm not sure if your User UID is accessible or useable elsewhere but I would not generally recommend posting that publicly!  If you wanted to edit your comment I believe it would be best to remove that.

    Please keep an eye out for an email from me with the ticket I'm creating to work with you on this - thanks!

    0
  • James Green
    Comment actions Permalink

    Thanks! User UIDs are publicly accessible on our site and APIs, so no worries there.

    0
  • Dan Greaves
    Comment actions Permalink

    Hey. I have a very easy question for anyone on this thread. Is it possible to set SLA's even if we are not using the priority field on our ticket forms?

    0
  • Graeme Carmichael
    Comment actions Permalink

    Dan

    You must set a priority to use SLAs. If you are not using the priority field, you can use a trigger to set all tickets to a default value. 

    0
  • James Sanford
    Comment actions Permalink

    Hey Dan!

    In order for an SLA policy to be applied to a ticket it will require that the ticket's priority is set.

    Also, for anyone who had followed along with James' question about custom user and organization fields in SLA policies: Only custom org/user fields that have defined values such as drop-down, checkbox, and date fields can be utilized in SLA conditions. 

    0
  • Dan Greaves
    Comment actions Permalink

    Graeme/James. Thanks for the quick answers. It's much appreciated.

    0

Please sign in to leave a comment.

Powered by Zendesk