Functionality to pause an SLA

34 Comments

  • Andrew
    Comment actions Permalink

    We have a similar issue when using "next reply", often customers will just say "Thanks!" which then commits us to reply.  Even when we set it to Pending, it still is waiting for our reply instead of "periodic update".

    7
  • Anthony Williamson
    Comment actions Permalink

    Simply adding "on-hold" to be included in the pausible updates would be a solution, or something more involved where there is an actual option in a ticket to deliberately pause an SLA.

    This is really key - Pending means it's in the consumers court but on-hold means it is with us. In our case if the product we are supporting is a hardware issue, we have to send information to our various distributors to issue the warranty. So even though it is in our organisations court, the support team shouldn't be 'penalised' for violating the SLA as they are simply waiting for paperwork from others outside the Zendesk eco system.

     

     

    0
  • Andrew Goetz
    Comment actions Permalink

    We actually use on-hold the most in the following instances:

    • Customer requests help with something in the future, so we put it on-hold until that date and time.
    • The customer has hit a bug which will be fixed in the next release of our product, so the ticket is on-hold until we release the new version (after which we inform them, ask them to upgrade, make sure it works as expected, then close the ticket)

    Our structure is:

    • Pending is ball in customer's court
    • Open is ball in our court
    • On-hold is timeout (or halftime/end of period/whatever sport analogy you prefer)

    This mean that on-hold is for tickets that are blocked, waiting third party input, or any situation where action is not required by neither the customer or us.

    When that is the case, it does not makes sense to have an SLA apply to a ticket in this state.

     

    6
  • Chandra
    Comment actions Permalink

    I agree with all of the above. We've had issues with both periodic update and pausable updates because of the inability to pause SLA's while in the on-hold status. We've had to come up with incredibly complicated workarounds that are still imperfect and unfairly breach tickets.

    We use On-hold primarily when our development team is researching an issue, not because the customer asks us to put the ticket on hold. This is contrary to the SLA and reporting metrics in Zendesk, which considers "on hold" to be time spent waiting for the customer. 

    1
  • SDS Product Team
    Comment actions Permalink

    I also agree with all of the above.  In fact I was told this is what happens as part of the on-boarding process, so my entire set-up was based on this fact.

    Open: For us to deal with

    Pending: awaiting user response

    On-Hold: awaiting a 3rd party

    Any chance anyone has a good solution?

     

     

    0
  • Nicole - Community Manager
    Comment actions Permalink

    Thanks for the detailed examples, everyone. Really helpful information. 

    There aren't any updates for SLAs planned in the immediate future, but sharing use cases like this is the kind of thing that helps prioritize things in the next round of planning. 

    0
  • Kalle Windefalk
    Comment actions Permalink

    I also agree with all of the above. Please prioritize this Zendesk.

    1
  • Peter Hur
    Comment actions Permalink

    Could Zendesk please create an option to Pause SLA when the ON-HOLD status is applied?

    • A nice way would be a switch, to turn on On-Hold pauses SLA just like Pending does.
    • A simple way would be to Pause SLA when a Specific Tag is added, and Unpause when that Tag is removed

    Anyway to do this currently?

    I thought of a potential semi work-around. When a specific Tag is added, it changes the ticket's current SLA to another SLA. However, I think this would create more issues because it isn't pausing SLAs, it is removing it from the SLA and applying another one. 

    0
  • Nicole - Community Manager
    Comment actions Permalink

    Thanks for the feedback, Peter. 

    Again, there aren't any immediate changes planned for SLAs, but we have flagged this thread as one for PM's to read through when they are pursuing improvements to that area of the product. 

    0
  • Matt Beecher
    Comment actions Permalink

    I also agree with all of the above. Please prioritize this feature. We use On-Hold when we are waiting for our development team to resolve a bug or enhancement and our SLAs usually end up breaching during this time since we do not need to update the customer. 

    0
  • Nicole - Community Manager
    Comment actions Permalink

    Thanks, Matt. I don't expect SLAs to be prioritized in the immediate future due to some other things that have to get completed first, but we have flagged this thread for the PM's. 

    0
  • Alex Tanayno
    Comment actions Permalink

    +1 for this feature. It would be really useful when putting the ticket to on-hold status. Nicole, is there any workaround available for now?

    1
  • Nicole - Community Manager
    Comment actions Permalink

    Hi Alex - 

    Not that I'm aware of, though if anyone else in the community has figured one out, please feel welcome to chime in!

     

    0
  • Ben Luo
    Comment actions Permalink

    I'm also in agreement with all of the above. Please prioritize this feature.

    2
  • Joel Koh
    Comment actions Permalink

    +1 to this. 

    1
  • Jake Martin
    Comment actions Permalink

    The issue we run into is similar to those stated above. Essentially, we provide the customer an update that the issue is with our development team, placing the ticket 'On-hold'. If the customer replies with a "thank you," this turns the SLA clock on again, even if you set the status from 'Open' back to 'On-hold'. The only way to prevent this is to reply again with "you're welcome," which can be gratuitous and time consuming with a heavy ticket load. 

    0
  • Jess Healy
    Comment actions Permalink

    +1 to this

    0
  • Kevin Ford
    Comment actions Permalink

    You can kind of implement this functionality on your own but it's not the most elegant. I added a checkbox ticket field called Pause. The tag for this is "paused." For us, this is paired with another ticket field that is a date field cause Pause Until.

    I put in an automation that will remove the pause when the date is reached (date is within previous x days).

    Modify your SLA to exclude tickets that have the paused tag. This will keep things from breaching. Unfortunately, the clock keeps ticking because the SLA policy looks as the last public reply that may be weeks or months ago. In other words, this delays the SLA breach until the automation removes the pause.

    To fix (hack) this, when the automation fires, the automation makes a public reply before removing the pause. This, too, is yet another hack as Zendesk does not allow you to make a comment on a ticket via automation. To do this, I use an HTTP target extension and have the automation notify the target.

    The unfortunate thing about this (besides how much of a hack this is) is this is making a public reply. Let me be very clear: DOING THIS WILL NOTIFY THE REQUESTER and they will see whatever text you put in the JSON body (shown below). You can suppress sending this to the requester by modifying the notify requester trigger but you cannot suppress sending to anyone on CC.

    The JSON body for the automation looks like this:

    {"ticket": {
      "comment": {
        "body": "WHATEVER TEXT YOU WANT THE PUBLIC COMMENT TO SAY",
        "public": true
        }
      }
    }

    The extension/target looks like this:

    URL: https://YOURSUBDOMAIN.zendesk.com/api/v2/tickets/{{ticket.id}}.json

    Method: PUT

    Content type: JSON

    Basic authentication: enabled and type in your username and password.

    2
  • Joel Koh
    Comment actions Permalink

    Notifying the requester is a dealbreaker for us, but I respect the hackiness of this workaround!

    1
  • Anthony Williamson
    Comment actions Permalink

    I'm with Joel regarding notifying the requester is a deal breaker...

    There are a number suggestions to not just this problem but others where the response is 'just hack the JSON' which I understand, but many organisations, such as myself, don't have a resource to do so. This is why we are asking Zendesk to provide the solution...

     

    0
  • Andrew Kaye
    Comment actions Permalink

    +1 I'm also in agreement with all of the above. Please prioritize this feature, Zendesk. 

    1
  • Jay Goodison
    Comment actions Permalink

    This is critical functionality... we're currently planning a move away from Zendesk as the lack of this feature is breaking our SLA reporting.

    0
  • Mateusz Toruński
    Comment actions Permalink

    I also agree with all of the above. As a support team for our own company product, we need to pause the SLA clock when awaiting software fix/feature release from our R'n'D.

    An option for customizable status fields for both "Support" (operator side) and "Help Centre" (end-user side), as well as relevant mapping, would be a perfect solution.

    @Nicole,

    "/.../we have flagged this thread for the PM's"

    Would you be able to share the timeline, when we could expect changes in the way that ticket status affects the SLA clock?

    1
  • Tim Schiller
    Comment actions Permalink

    We have managed to work around this fairly simply. We have an additional field called "On-hold reason". It has a number of typical reasons, "Waiting for development", "Waiting for scheduled meeting", etc...

    On our main SLAs we have this setup:

     

    We have 2 SLA policies, one for VIPs and one for everyone else. But the On-Hold condition is the same on both. 

    The other piece of this is a simple trigger. If any ticket goes from On-Hold, to any other status, simply clear the "On-Hold reason". Then the SLAs get picked up again. 

    1
  • Tobias Hermanns
    Comment actions Permalink

    Hi Tim,

     

    if you doing it like that, it will re-calculate SLA after back from On-Hold and not helpful.

     

    Simple example:

    SLA Set 1 = Next Reply Time

    SLA Set 2 = No Next Reply Time

    Based on your condition, you remove "Next Reply Time" for On-Hold Status, and SLA goal will gone from ticket (visibility) but for Reporting / Agent, after Ticket changed from On-Hold i.e. to Open and "Next Reply SLA" is back, the goal breach directly due to timing is re-calculating and also checking the other SLA Set On-Hold Time.

     

    So from my point of view or for my things not helpful.

    /Tobias

    0
  • Andrew Goetz
    Comment actions Permalink

    I like some of that Tim, and also tried something similar (having a tag disable the SLA), but consider the following scenario:

    1. You have an SLA policy with a 'Pausible Update' of every 24 hours (purpose is to ensure your team gives daily updates for important cases).
    2. A customer responds with 'Here are the files you requested', which restarts the 24hr update clock (ticket goes from pending to open).
    3. Your team then responds with 'Thank you, we will pass this to our developers and update you as soon as we can.', which also resets the 24hr clock (you will need to respond within 24 hours from this message to meet this SLA).
    4. You then put it into an On-hold state with your On-Hold Reason exception being 'waiting for developers' (which temporarily removes the SLA).
    5. It sits in the On-hold state over the weekend as the dev team reviews the case (48 hrs).
    6. On Monday morning, the customer replies with 'Any update to this investigation?' which sets it from On-Hold to Open, which reapplies the original SLA which was expecting an update that never happened over the week, and you instantly breach the original SLA policy.

    ---

    This is the case I am in, and simply having On-hold *actually* pause the SLA is the only method I can think of to ensure this 'instant breach' doesn't occur.

    0
  • Dion Van de Kamp
    Comment actions Permalink

    Is there a way to maybe exclude tickets with a certain tag or status (i.e. on-hold) in Explore when the SLA data is presented, as a workaround in the meantime?

     

    Or what about seleting this metric in SLA settings? It says that it doesn't count on-hold time? It counts the whole journey though...

     

    0
  • Jonna
    Comment actions Permalink

    Hi!
    +1 here struggling with the same challenge. We have a tickets "on-hold" sometimes very long time, because those are waiting for developers. We do not want these to be included in the "next reply time" SLA.

    We would need a way to report somehow if we meet our target to reply customers in X hours (periodic update). Has anyone been able to do this in insights by using this: https://support.zendesk.com/hc/en-us/articles/205367047-Insights-recipe-Duration-between-two-or-more-ticket-events-in-minutes ?

    If I understand correctly, I'd need to create 3 metrics:
    1) Showing timestamp when ticket status changes from "pending" to "open"
    2) Showing timestamp when ticket status is "open" and public comment made by admin or an agent
    3) Metric showing a difference between these 2 timestamps

    But how I could include also tickets that are "open" and remain "open" despite we send an update to the customer?

    0
  • Rick Kadlac
    Comment actions Permalink

    This is also an issue for us. We make use of on-hold for bugs that will be worked on soon and if the customer responds back with a comment like: "Thanks for letting me know" or "That's great" it will negatively affect their SLA metrics. 

    Giving the option to pause the SLA for the "on-hold" status in a way similar to the "pending" status seems like the lowest lift (from the ZD engineering standpoint) to be able to resolve this.

    SLA metrics are inaccurate until this is a feature.

     

    0
  • Kevin Ford
    Comment actions Permalink

    For those of you that are attempting to implement the "solution" I documented above using a target extension and updating the ticket with a public comment, it no longer works. Last night, the extension in our account was disabled due to too many failures.This is, I think, because the URL is now incorrect.

    Something changed in the behavior of the backend and when I open the target, the URL still shows as https://YOURSUBDOMAIN.zendesk.com/api/v2/tickets/{{ticket.id}}.json but after a few seconds changes to show https://YOURSUBDOMAIN.zendesk.com/api/v2/tickets.json so I think Zendesk is no longer allowing liquid markup in target URLs.

    It was OK while it lasted.

    0

Please sign in to leave a comment.

Powered by Zendesk