Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Generating SLA reports when SLA goals are met butSeverity of he original submitted ticket is changed

Arshpinder Sidhu
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
April 22, 2024

Hello,
I am looking out to generate SLA reports on issues with different severity level for "Time to response" and "Time to resolution".

Questions:

Question 1 - As JSM allows to set-up goals based on priorities , what could be the best way to set SLA goals on severities (different from priorities). In our env., there can be 2 Sev 2 with high or medium priorities as an example.
Workaround that I have adopted - Set up an automation rule to match JSM inbuilt priorities with Custom Severity.
Highest = Sev 1
High = Sev 2
Medium = Sev 3
Low = Sev 4

Is there any other better way to set-up SLA goals?

Question 2 - If severity of a submitted ticket changes, how will the reported be affected?
Example 1: A customer submitted Severity 1 ticket which is responded and resolved with a workaround but stays open for RCA. In this case we downgrade the severity to 3 or 4, but we still want to generate reports on the initial Sev 1 submission and the downgraded Sev 3/4 on the same ticket. Is there a way we can have the SLA goal not to be rest on the original ticket submitted?
Expectation is not to have a duplicate/new ticket for affected severity.

Example 2: A ticket submitted with severity level 2 met the "Time to response" threshold but client decide to raise the severity of the issue due to urgency. How will the SLA reporting be impacted? Will the "time to respond" also reset?

1 answer

0 votes
Walter Buggenhout
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 22, 2024

Hi @Arshpinder Sidhu and welcome to the Community!

Maybe counter-intuitive, but I'd like to start with the second part of your question. An SLA has a timer that starts running or stops based on events. Once it reaches the condition to make the timer stop, it stops running. It can only be restarted if you add an event that triggers the timer to start running again. In the example you provided, that would not make any sense. If your time to resolution is either stopped or breached and your customer would (if he/she even has the possibility to do this) raise the severity of an issue, you would expect a shorter target for time to response. If it is already breached, that would only make things worse and not really contribute to a better service to your customer.

Secondly, I don't quite understand why you would translate severities into priorities when they are essentially the exact same thing. It is quite common to not let customers determine priorities of tickets and instead a much used practice is to offer them a more objective way to qualify the ticket they raise. A good example is a matrix consisting of impact x urgency, which you can translate into a priority. You can find a description of how you can implement this in this support article.

Finally, to wrap this up: if you use a more objective approach to qualify your tickets, the impact and urgency don't suddenly change (unless the person who reported the initial ticket made a wrong assessment of something). Rather than messing around with raising and lowering the urgency of these things, work with your service teams to use the SLA timers to properly respond to tickets on time. If a ticket gets missed occasionally, that may happen. But if missing tickets is more a rule than the exception, there is probably something deeper that's wrong.

Hope this helps! 

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events