Dealing with SLA blind spots

3 Comentarios

  • CJ Johnson

    Thank you for this! This may solve one of my SLA headaches that I've been trying to figure out how to handle better. 

    One thing to note about changing policies that caused a terrible mess this year with SLA for us: If the ticket changes policy, and a ticket had for the original policy, any policy metric breaches, the new policy uses the time the new policy was applied to begin the timers on those metrics. That means a ticket that was -10 days for FRT on OldPolicy, picks up NewPolicy with a 2 hour FRT target, well suddenly the ticket shows its 2 hours till breach, even though it came in over a week ago. This does NOT apply to the ticket's un-breached metrics, those track correctly post-policy switch, which I found very confusing. 

    0
  • Jacob the Moderator
    Community Moderator
    Zendesk Luminary

    Glad you liked it CJ Johnson!

    I saw your question a while back when I was trying to work this out for myself, and I decided to share my experience. Hope you and others join in with best practices and workarounds for these unusual flows.

    That is an odd consequence of switching policy on already breached tickets, do you know why this happens?

    1
  • Jacob the Moderator
    Community Moderator
    Zendesk Luminary

    Just wanted to drop a note to say that I updated my setup for activating Next-reply time targets using a trigger and webhook that would add a public comment authored by the requester on the ticket, and have a ZIS flow make this comment private so it would not show up in the thread for the requester to see.

    This is working well, but I'm still eagerly awaiting this upcoming release that should give admins more control in terms of what events activate and fulfill SLA targets.

    0

Iniciar sesión para dejar un comentario.

Tecnología de Zendesk