Defining and using SLA policies (Professional and Enterprise)

Have more questions? Submit a request

137 Comments

  • Kevin Mooney
    Comment actions Permalink

    Wow Erin, this is great.  Love the additional functionality.

    Kevin.

    0
  • Andrew J
    Comment actions Permalink

    Is there any reason why the new SLA system does not have full resolution time?  

    0
  • Erin Boyle
    Comment actions Permalink

    Hey Andrew,

    Yes! The vast majority of customers we've spoken with don't actually want to measure full resolution time, and that's the primary reason we haven't added it. Now that could change over time, and we will continue to evaluate which metrics are important to customers and add things as it becomes necessary. We don't, however, want to overly complicate what's already a fairly complicated feature by adding options that most customers don't find useful.

    All the best,
    Erin

    0
  • Andrew J
    Comment actions Permalink

    Thanks Erin,

    I think I can understand that.  Measuring resolution time only doesn't give a very good picture of what is happening.  I'll work with what we have for now :)

    0
  • Colin Piper
    Comment actions Permalink

    I am grateful for the new metric, for many customers I am sure this will be an essential missing feature now delivered. Where I am struggling is the auditing of all these metrics. Which has breached, 2 hours until which metric etc etc. Adding this one is just creating more blur in the SLA status. 

    I have created my own collection of triggers and automations to set and clear tags to try and create an history that I can then report on. But I cannot do this for all the metrics as often I cannot create unique conditions. 

    Hopefully it will not be too much longer before a solution to this really complex requirement is available. In the meantime though please keep feeding our insatiable appetites. Thanks

    0
  • Michael Warden
    Comment actions Permalink

    We have a situation I'm not sure is supported and I could use some help:  We only want to monitor Periodic Update Interval (PUI) when a ticket is in 'Open' or 'New' status - ie, some of our tickets are on hold until an event happens, which may be weeks out, and are set 'On Hold' and we don't want to apply the policy there.  Is there any plan to allow us to use 'ticket status' to apply to our SLA policies?  

    We were doing this successfully when we did Next Reply Time because the customer response always moves it back to Open from Pending and On Hold.  We were excited to see Periodic Update, but were bummed when we realized it wouldn't work for us.  

    So - we don't want to track SLA breaches for On Hold or Pending, only Open and New?  Additionally, we don't want the PUI clock running while in Pending or On Hold as we don't want it to immediately go into breach when we move it back to Open.  Any chance of that?  

    0
  • Erin Boyle
    Comment actions Permalink

    Hi Michael,

    Right now I believe Periodic Update will be automatically satisfied when the status is in Pending, but not in On Hold. We don't have any current plans to allow for more customized use of statuses in our SLA policies.

    Best,
    Erin

    1
  • Brian Gibson
    Comment actions Permalink

    This is a huge disappointment.  I dont need SLA's for on-hold tickets.  On hold means we know it is waiting on something outside of our control, yet if we want to use periodic response, we are tied to updating those tickets.  I feel like it is a serious design flaw of your periodic response SLA.

     

     

    4
  • Jamie Garbett
    Comment actions Permalink

    Hey Guys,

     

    My apologies if this has been covered but im having trouble with seeing the SLA timer. The SLA is configured, and i can see that it is indeed being applied via the audit trail of the ticket....

    Ive activated insights and there are no metrics at the minute displaying on the SLA tab.

    All help is - as always - very appreciated.

     

    thanks

     

    J

    0
  • Jessie Schutz
    Comment actions Permalink

    Hey Jamie!

    It can take some time for information to get synced into Insights, depending on your plan.  Are you still not seeing those stats, or have they since shown up on your dashboard?

    0
  • Olof Soldatic
    Comment actions Permalink

    I have to agree with Alex and Brian amongst others here.

    The On-hold status is a 3rd party status right?

    How are we supposed to be accounted for that time in a service level agreement environment? 

    1
  • Andrew J
    Comment actions Permalink

    @olaf - On-hold has had it's controversy since it's inception.  Personally I think it's important to remember the clients experience.  From their perspective - in our case - they are still expecting a response from us.  I would suggest that if you have regular processes that require waiting on a third party, you may want to exclude these from the SLA - maybe create a distinct SLA to cover these ones?

    0
  • Olof Soldatic
    Comment actions Permalink

    @AndrewJ - Well if On-hold was not meant for third party cases I would be more prone to agree. I can of course only speak for our company but we always communicate the reason for setting a ticket On-hold.

    If by "create a distinct SLA" you mean to alter our customer agreement, that's a no go. It's a non issue if a 3rd party has a scheduled disruption but what I am talking about are outages that are unintentional and unplanned. Therefore after we've assessed the issue and find out a 3rd party is causing the error - we report to both parties and set the issue On-hold. (Note that we are still reporting to our customers on an hourly basis even though the issue is On-hold)

    One way of making that more clear to our end-users would be to actually display the status for them - instead of what is shown today - "Open"

     

    0
  • Andrew J
    Comment actions Permalink

    OK, we are probably a little different - our 3rd parties tend to be contractors or services that we use, and though they are not our employees or agents on our helpdesk - we still consider that the client is awaiting something from us, therefore for the client the ticket is still 'open'.

    If the 3rd party you are dealing with is not responsible to you, would 'Pending' with an explanation to the client be more workable?  Who will the 3rd party advise when their issue is resolved?

    0
  • Olof Soldatic
    Comment actions Permalink

    No I'd say we treat 3rd parties in, roughly, the same manner - just that when the work is not on us to perform, the On-hold fits nicely, which I assume is the reason for its existence?

    The suggested workaround feels more like a step in the wrong direction. 

    If I'm out on my tricycle here I'm open for suggestions :) But if not 3rd party then what was On-hold intended for in the first place?

    0
  • Andrew J
    Comment actions Permalink

    Was created with 3rd party in mind.  However as you have noted - the ticket is still open as far as the client is concerned - on the premise that they are still awaiting a solution, whether it be from us or our contractor.  The discussion around how 'on hold' should show for the client was pretty robust and inclusive.  

    We take 100% responsibility for actions of our contractors, therefore if I have an agreement to follow up after a certain period... I will do that even if the delay is with a 3rd party.  

    We only ever put a request on hold for a specified period, and it reopens after that.

    Other than what we've already discussed - what might some possible solutions look like?  

     

    0
  • Olof Soldatic
    Comment actions Permalink

     

    I'll try another angle instead.

    According to the SLA targets, the "Agent work time" does take into account the On-hold status. What use could I have of that?

    0
  • Andrew J
    Comment actions Permalink

    That's a good way to put it :)

    I can understand it being shown in Customer wait time... but agent work time is a bit odd.  That said... Agent Work Time doesnt give any indication of ... agent work time!

    I can't see much difference in Customer Wait time and Agent work time. :shrugs:

    @Nora Mullen - can you clarify what the point is here?

    0
  • Erin Boyle
    Comment actions Permalink

    Agent work time pauses on both Pending and On-hold. If the ticket is in the on-hold status, we're assuming the agent isn't actively doing work because they're waiting on a third party.

    Requester wait time only pauses on Pending. In other words, it's a much more accurate picture of what the customer is experiencing, since most likely they don't care if the ticket is with you or a third party... they're simply waiting.

    0
  • Andrew J
    Comment actions Permalink

    Thanks Erin! Nice to see that - sounds as expected.

    0
  • Olof Soldatic
    Comment actions Permalink

    @Erin and Andrew,

    I can settle @ agree to disagree.

    We can't let 3rd party software or services count toward our SLA against our customers,
    continuously report yes but not full resolution time, which I am sure you've gathered by now :)

    I don't see us being unique in that matter either But, yes, we can work around it.

    Thank you for the input.

    0
  • Andrew J
    Comment actions Permalink

    @olaf - I'll just add one more comment - I do think the new SLA system is lacking in flexibility.  Sometimes you just want to measure a specific thing and the option isn't there.  Plus getting reports from these is laborious at best.

    0
  • Erin Boyle
    Comment actions Permalink

    Hi all,

    Just wanted to let you know about a change that went out yesterday for the periodic update metric. We heard from a lot of you that essentially fulfilling this metric automatically during the pending status was highly undesirable, as you wanted to keep your customers updated periodically, regardless of whether you were waiting on additional information from the customer.

    Now, the periodic update metric will not fulfill when the status is changed to pending.

    Recap on the newly expected behavior:  When an agent makes an initial public comment, an instance of periodic update will begin. When an agent makes a subsequent public comment, that instance will be fulfilled, and a new instance of periodic update will begin with a new clock. This will repeat, regardless of status, until the ticket is put into a Solved status.

    Let me know if you have any questions!

    Best,
    Erin

    -2
  • Brian Gibson
    Comment actions Permalink

    This is extremely unfortunate Erin, and yet again reduces how I can use Zendesk. In the past, Zendesk would recommend to use automations on pending tickets, instead of forcing agents to do manual up dates. This change has forced me to disable periodic slas for my agents and costumers. This is becoming a deal breaker for me, and I'd like to know if there are any options for my organization to revert to the old functionality. I noticed the change yesterday, when my slas began breaching, hurting my reporting numbers. Changing functionality without notice in the middle of the day is an extremely poor practice.

    Please let me know if I have any other options besides evaluating new providers

     

     

    Also - the new logic doesn't make sense by your own account here: 

    May 09, 2016 19:05

    Agent work time pauses on both Pending and On-hold. If the ticket is in the on-hold status, we're assuming the agent isn't actively doing work because they're waiting on a third party.

    1
  • Arturo
    Comment actions Permalink

    Erin, are there any chances of reconsidering the periodic update metric behavior update?

    As you may understand, changing this without any previous notice has broken consistent workflows for some of us.

    Please count us in if there's an option to go back to the previous metric behavior or to opt in for a replacement. 

    Also, we would appreciate if you, or anyone in the thread, could share a workaround to fulfill the SLA of a ticket when this is submitted as Pending but keeping it active when the ticket is submitted as Open.
    This can be applied, for example, when you want to start counting towards SLA only after a reply from the ticket requester and also when you want to keep the SLA active after escalating a ticket to another support tier after letting the requester know that using a public comment.

    Thanks in advance for your suggestions!  

    0
  • Gadi Vered
    Comment actions Permalink

    Erin, +1 on issues with the new functionality for periodic update.

    The SLA  for next response effectively disappears from the "open" tickets, if our agents made a public reply to say they are looking into something or working on an item.

    If we had the old functionality for periodic update or some kind of clever workaround with tags? 

    Any suggestion would do.

     

     

    1
  • Rafael Marquez Montes
    Comment actions Permalink

    Hi

    After having a long conversation with your Tier 2 Agent I realized that there are two behaviors related to business hours which make no sense to me.

     

    The first thing is that if somebody works on a ticket out of business hours, the counters keep working. I am not sure if this is actually happening, but shouldn't all the SLAs be stopped when it comes to "out of business hours"? That is the idea of an SLA, an agreement with the customer within your time frame, which is why we have calendar and business hours.

    This is specially wrong, in my opinion, in the case of the Periodic Update. The rule, as explained by your colleague, is that no matter the status of a ticket, no matter if it is set to business or calendar hours, this metric will always continue.

    This leads me to two questions:

    -What is the use of a metric in business hours if it continues beyond business hours when I have no service available. How can I update an user out of working time?
    - Why the metric keeps on running when the ticket is Pending? I have an agreement (SLA) with my customer about keeping him updated when the ticket is on my side. What sense does it make to update a ticket pending from the customer? If the issue is related to press or remind the customer to his part, this is not part of the agreement, and even less on my side. Why should I lose an SLA because a customer takes a long time to answer the issue that HE is having?.

    This is also applied to other metrics which continue running after business hours. You may refer to my ticket for further information. I could publish it here if you want since it does not contain internal information.

    Regards

    2
  • Gadi Vered
    Comment actions Permalink

    Erin and Zendesk team - our main problem is now once an agent has replied publicly but still needs time to work on a response. Since I had to disable periodic update (because it effectively cancels my ability to automatically follow up on a ticket) , there is now no way to track this ticket in terms of SLA and it is driven to the bottom of the view (which is set to look at next SLA breach).

    Any ideas how to get out of this situation?

    2
  • Jeff Callahan
    Comment actions Permalink

    Erin - is there a workaround to bypass the new logic for the Periodic Update Metric when tickets are Set to Pending?

    We use the Periodic Update metric to let Agents to prioritize tickets they are responsible for - Open Tickets

    However if a ticket is set to Pending the responsibility is on the Requester and should not be subject to the SLA.

    Could we use a Trigger to move Pending tickets into a different SLA Policy which does not use a Periodic update (maybe adding a trigger when set to Pending)?

    Then another Trigger to move the Ticket back into the Original SLA?

    1
  • Craig Little
    Comment actions Permalink

    Jeff and others,

    Thank you for letting us know about your use cases around the Periodic Update metric.

    I have some good news.

    We're in the process of adding a new SLA metric that will not run when the ticket is in the Pending state.

    We'll be sure to let you know once it's available for use. Stay tuned!

    1

Please sign in to leave a comment.

Powered by Zendesk