nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to get "Time to first response" SLA working when approval needed?

Philip Colmer

We need to ensure that we are meeting our "time to first response" SLA *but* the clock doesn't start counting until the ticket is approved.

So, I've set up the SLA so that it starts counting when the ticket enters the status "Waiting for Support" and stops when the status changes to "Cancelled", "Closed", "In Progress", "Pending", "Resolved", "Waiting for Customer".

That works fine ... except for the fact that the SLA repeats every time the ticket moves back to "Waiting for Support".

I only want it to count the *first* response. What can I do to get this working?

Accepted answers

Philip Colmer

It turns out that there was another way to solve this ...

Screenshot 2020-12-09 154704.png Pause the SLA between the ticket being created and the ticket reaching one of the non-approval states. This has the advantage that it also works with the non-approval workflow which goes straight from creating the issue to "Waiting for Support" and thereby doesn't actually trigger the "enters state" rule.

All comments

Jack Brickey

Maybe replace enters “waiting for support” with issue created? I would need to see more details to recommend definitively. The key here is that you don’t want to start SLA if the issue “reenters” a status it seems.

Philip Colmer

Here is the workflow we're using. The drawback to replacing "Waiting for Support" with "Issue created" is that I don't want the clock to start until the issue has been approved (if the reporter requires approval). That is why I set the SLA to trigger on "Waiting for Support".

Maybe what I need to do is change the workflow so that when the customer replies, it transitions to "In progress" rather than "Waiting for Support" ...

Screenshot 2020-12-09 123525.png

David Friedrich

Hi Philip,

you could define a no-target-goal to your SLA excluding every ticket that already has been in status "Waiting for Support" once before. Or - if that doesn't work -, make the query about all the statuses, that would imply a first response to the customer. The JQL for those two options would be something like that:

1) status was "Waiting for Support"

2) status was in (Cancelled, Closed, "In Progress", Pending, Resolved, "Waiting for Customer")

2020-12-09 13_53_15-Window.png

A third option would be a no-target-goal for tickets that already have one public comment. If that is possible with JQL i leave for others to answer ;-).

Jack Brickey

so let's see if I can articulate the desired SLA behavior you want.

Start SLA when issue transitions from Needs Approval to Waiting for Support. You don't want to start on Waiting for Support if the issue doesn't go thru Needs Approval.

Is this correct? If so, given the limited conditions available to us for SLAs, I might consider creating a unique "waiting for support" status. For example maybe you have an Approved status that mirrors W4S. Just spit-balling here.

Philip Colmer

Unfortunately, that doesn't seem to work. I've decided to modify the workflow instead as explained in my answer below.

Philip Colmer

I've decided that, for my needs at least, the cleanest solution is to alter the transitions so that Waiting for Support can only transition to In Progress and then there are transitions between In Progress & Waiting for Customer.

This has a knock-on effect that the default "Transition on comment" automation needs tweaking.

Screenshot 2020-12-09 141834.png

Philip Colmer

It turns out that there was another way to solve this ...

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira-service-management

jira-service-management-server