- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-04-2019 08:01 AM
We're looking to create a trend report that shows the average time an incident is worked on. Currently, the business duration runs on our "8am-5pm weekdays excluding holidays" schedule. When an incident is resolved, a calculation is done to capture the total business duration the ticket was open. The issue we're finding is this does not take into account "Pause" conditions where the incident is in a state where they are awaiting a user, change, problem, etc.
The next thought was to look at the Task SLA table since the SLA's pause when the incident reaches these "Pause" states. The issue here is if the incident's priority is changed, a new SLA gets assigned resulting in multiple business durations. If we were to average the SLAs for the week, this would not first sum the SLAs for an incident then take the average resulting in inaccurate times. In the example below, the incident had it's priority changed from a P4 to a P3. The P4 SLA ran for 15 hours and 40 minutes while the P3 SLA ran for 3 minutes. These totals would not be summed in a trend report.
Does anyone have any ideas on how we can present the time a ticket is being worked on in the system?
Solved! Go to Solution.
- Labels:
-
Reporting

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-04-2019 09:00 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-04-2019 09:00 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-07-2019 07:58 AM
You could create a new SLA that starts at creation, and ends at resolution. Set no pause or restart conditions for the SLA's and you would have the metric you are looking for. If you are concerned with SLA breaches, then set the breach time to 999 days.
We do something similar for when an Incident is assigned to a queue, through resolution, and ignores pause states. We use this to measure how much total time that ticket spent in our queues.