Next reply time applied incorrectly (starts with zero) when ticket returns from On-hold state

Answered

5 Comments

  • Chandra Robrock
    Community Moderator

    Hi Drey! I'd be happy to help. I think I figured out what's happening here.

    Taking a look at your last screenshot, I see that this ticket Pausable Update Time target was triggered, in addition to your Next Reply Time target.

    The Pausable Update target will track the time between each public comment from agents when the tickets is in the New, Open, and On-hold statuses, pausing when the ticket is put into Pending.

    Based on your third screenshot, it looks like you have a trigger in place called the '[SLA] Stop if On-Hold' which causes this Pausable Update target to not be active when in the On-Hold status.

    When the customer wrote back in, a new trigger was run called the '[SLA] Set default to none' which then allows both the Pausable Update and Next Reply Time targets to become active again. Since it looks like it's been longer than 8 calendar hours since an agent last posted a public comment on the ticket, this is causing the SLA to essentially breach for that specific target upon reopening.

    However, you should still be okay from a Next Reply Time perspective. The Zendesk UI will display the time to Next SLA Breach, based on the target that is going to breach first. In this specific case, it was the Pausable Update target.

    Hope that helps! 

    0
  • Drey Tee

    Thanks Chandra, that could be the reason.

    But as far as I see we already use the Trigger "[SLA] Stop if On-Hold" which removes all SLA tags and Pausable update timer too.

    When ticket returns it gets default sla (sla-1day) and new Pausable update time target (8h).

    Did I miss something?

    0
  • Chandra Robrock
    Community Moderator

    Unfortunately, Zendesk doesn't support the ability to truly pause SLAs at this time, but it's definitely something that has been requested in the past. I'd recommend upvoting this community post to request this type of functionality: https://support.zendesk.com/hc/en-us/community/posts/115009712828-Functionality-to-pause-an-SLA. It's definitely a feature I'd love to see Zendesk build in the future.

    Without the ability to truly pause SLAs, the Pausable Update target is still going to look at the number of hours since the agent's last public comment, even if the trigger you implemented had temporarily "paused" the SLA when it was in the On-Hold status.

    To help get around this scenario, you could consider either not using the Pausable Update target or only make it applicable for specific to certain tickets/policies.

    For instance, we have an SLA Policy for our main Support group that uses the First & Next Response targets, and nothing else. However, for our Support Engineering policies, we've found the Pausable Update target is helpful for those tickets since they are typically communicating to our customers about long-standing bugs.

    We actually have a few automations to help ensure that these tickets "reopen" in our Support queue in X business days so that a Support Engineer can get a response out to the customer before the Pausable Update target is scheduled to breach.

    Would be more than happy to chat with you more about our reopen automations if it's something you'd be interested in exploring further. 

    0
  • Drey Tee

    I can't see how our workflow would look like without Pausable update time (we're rely on that heavily).

    Yes, please, could you share your automation details?

    0
  • Chandra Robrock
    Community Moderator

    Of course! So, at my company, we want to be able to bionically follow up with customers, without having to manually seek out these tickets in order to do so. 

    To help achieve this, we have a custom dropdown ticket field called Sleep, which has a few different time-based options (i.e. 1 hour, 1 day, 3 days, etc). If an agent moves a ticket into either a Pending or On-Hold status, we require this ticket field option to be selected. (Currently, we're using Zendesk's Conditional Fields to require this field, but I had another hacky automation we were using in the past when we didn't have access to this feature). 

    We then have a few different automations that look like the screenshot below to help tickets reopen in our queue, based on how long the ticket was "slept" for. That way, we know to either follow up with the customer or even check in with an internal team (i.e. engineering) so that we can communicate something back to the customer.

    This is really the main reason we don't use Pausable Updates for our Support policies, since this "sleep" automation is helping ensure that we're being responsive & timely with our customers. However, for our Support Engineers specifically, this helps them have the ticket reopen before the Pausable Update SLA would breach (since they do rely on this target for keeping customers updated on the status of bugs). 

    Would love to hear if you think that could be helpful for your specific use case.

    0

Please sign in to leave a comment.

Powered by Zendesk