-
Suggestion
-
Resolution: Low Engagement
-
None
-
0
-
6
-
NOTE: This suggestion is for JIRA Service Desk Server. Using JIRA Service Desk Cloud? See the corresponding suggestion.
Summary
A ticket can go through multiple cycles of the same SLA. The SLA web panel will then show whether this ticket met or breaches the SLA for each individual cycle
However, there isn't any reporting capabilities for this information. The default SLA report will only show whether the latest is met or breached.
Suggestion
Create a report for this information where users can see exactly how many cycles of SLA are met or breached based on a JQL query
- relates to
-
- Gathering Interest
- mentioned in
-
Page Failed to load
[JSDSERVER-2518] Additional reporting for same ticket with multiple SLA cycles
To me, the behavior does not make much sense and is rather a Bug than a Suggestion. Why does the individual ticket count each "Breached" and "Met" respectively, while the Report does not? And if you breach an SLA five times in row, and then meet it one time only - why is the ticket count as "Met"?
My scenario is as follows:
• There is a Service Desk SLA “Time waiting for support”. It measures whether the Support Representative provides regular updates to a customer when action is required by support (status “In Progress”). Time starts counting when “Start Progress” is being set, and stops when status e. g. “Confirmation” has been set (these are my test cycles). For e. g. Priority “Critical”, you need to provide feedback to a customer within 10h (= by sending a reply and setting status to “Confirmation” or “Waiting for customer” afterwards. Measuring stops, then, and will start again when “Start Progress” is executed afterwards). So there can be several cycles during the lifetime of a ticket.
• In terms of Reports, I await that each successful cycle “Start Progress Confirmation” gets counted as well as each breached cycle (= ticket was overdue regarding “Time waiting for support”)
• In other words: when the mentioned SLA cycle gets breached 3 times and is met 2 times, I await that this is shown accordingly in the Report. It is shown this way in the individual ticket (the "x"- or "check"-boxes next to the clock)
• What happens in the Report instead is that apparently only the latest status in terms of Breached or Met gets recorded. So my Report states "1 Breached - 0 Successful"
If I create a successful (= SLA Met) circle afterwards and refresh the report, it switches to “0 Breached – 1 Successful”
• I await that the Report states “3 Breached – 2 Successful” instead.
So each time when a Support Rep breaches the SLA for a particular ticket, I risk an unsatisfied customer, because my team member have to provide the latest feedback time in advance ("I'll get back to you tomorrow evening the latest"). So if the Support Rep fails to provide feedback in time five times in a row and only meets the last time this SLA - what is "Met" about this as stated in the Report, then?
For my organization, this SLA is key to our business in order to provide transparency to our customers: work is with us - what am I going to do, and when will I get back to the customer? This is something that our customers demand from us, and currently, Service Desk fails to support us. After Service Desk not being able to support several projects within one Service Desk, this is the second key feature that is missing. I am sorry to say, but I am getting disappointed with the product.
Thomas Löwe
added a comment - - edited To me, the behavior does not make much sense and is rather a Bug than a Suggestion. Why does the individual ticket count each "Breached" and "Met" respectively, while the Report does not? And if you breach an SLA five times in row, and then meet it one time only - why is the ticket count as "Met"?
My scenario is as follows:
• There is a Service Desk SLA “Time waiting for support”. It measures whether the Support Representative provides regular updates to a customer when action is required by support (status “In Progress”). Time starts counting when “Start Progress” is being set, and stops when status e. g. “Confirmation” has been set (these are my test cycles). For e. g. Priority “Critical”, you need to provide feedback to a customer within 10h (= by sending a reply and setting status to “Confirmation” or “Waiting for customer” afterwards. Measuring stops, then, and will start again when “Start Progress” is executed afterwards). So there can be several cycles during the lifetime of a ticket.
• In terms of Reports, I await that each successful cycle “Start Progress Confirmation” gets counted as well as each breached cycle (= ticket was overdue regarding “Time waiting for support”)
• In other words: when the mentioned SLA cycle gets breached 3 times and is met 2 times, I await that this is shown accordingly in the Report. It is shown this way in the individual ticket (the "x"- or "check"-boxes next to the clock)
• What happens in the Report instead is that apparently only the latest status in terms of Breached or Met gets recorded. So my Report states "1 Breached - 0 Successful"
If I create a successful (= SLA Met) circle afterwards and refresh the report, it switches to “0 Breached – 1 Successful”
• I await that the Report states “3 Breached – 2 Successful” instead.
So each time when a Support Rep breaches the SLA for a particular ticket, I risk an unsatisfied customer, because my team member have to provide the latest feedback time in advance ("I'll get back to you tomorrow evening the latest"). So if the Support Rep fails to provide feedback in time five times in a row and only meets the last time this SLA - what is "Met" about this as stated in the Report, then?
For my organization, this SLA is key to our business in order to provide transparency to our customers: work is with us - what am I going to do, and when will I get back to the customer? This is something that our customers demand from us, and currently, Service Desk fails to support us. After Service Desk not being able to support several projects within one Service Desk, this is the second key feature that is missing. I am sorry to say, but I am getting disappointed with the product.
Hi,
Thank you for raising and watching this suggestion. We regret to inform you that due to limited demand, we have no plans to implement it in the foreseeable future. In order to set expectations, we're closing this request.
This is an automated update triggered by low engagement with this suggestion (number of votes, number of watchers).
We hope you will appreciate our candid communication and our attempts to become more transparent about our priorities. You can read more about our approach to highly voted suggestions here, and how we prioritise what to implement here.
To learn more about our recent investments in Jira Service Management and Data Center, please check our public roadmap and our two dashboards containing recently resolved issues, and current work and future plans.
Regards,
Jira Service Management, Server & Data Center