- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-04-2026 01:13 PM
I've been digging online for a while but haven't made many inroads on something I'm curious about: We have a 'meter' that keeps tabs on our aging incidents. After seven days of an incident being open, it sends the incident to a service manager for additional review and feedback. I'm curious to know how we can integrate some sort of logic into this so that we're measuring only in "BUSINESS DAYS". Right now, Saturdays/Sundays & Holidays are counting against the seven day meter. So, if a ticket is open on a Wednesday, by next Tuesday it's already considered seven days old. Why should we be judged against a day/days when NO ONE in the company is even working? Any thoughts would be welcome, even if it's a 'no dice' to the logic being available at this time.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
a month ago
Hi,
If the sole purpose of this meter is to trigger this sub-process of a service manager reviewing the incident, I would use SLAs. SLAs are business-time aware, and conform to a schedule. SLAs also have a workflow/flow attached where you can specify actions that occur when % of elapsed time have passed.
OOTB most people keep the default flow which just triggers a notification. This is great, but doesn't track actionability.
Based on the above you could:
- Have an SLA that follows your business schedule, and has a duration of the equivalent of 7 days. This is important, you can't just set it to 7 days as it'll be 7 calendar days. You need to specify the hour-equivalent of 7 days for your schedule. E.g a 9-5 Mon-Fri schedule would be 56hrs.
- A flow that handles this "escalation process"
- In the flow, when it breaches trigger an incident task for the service manager to review.
You can then repeat this process, or "step up" the escalation if needed. Say it goes to 14 days? What happens then.
This is also then reportable as you'll have a running SLA tracking just how much time was used
You can use SLA breakdowns to track the assignment group(s) the incident touched, and for how long
An actionable task related to the incident where the service manager completed their analysis.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
a month ago
Hi,
If the sole purpose of this meter is to trigger this sub-process of a service manager reviewing the incident, I would use SLAs. SLAs are business-time aware, and conform to a schedule. SLAs also have a workflow/flow attached where you can specify actions that occur when % of elapsed time have passed.
OOTB most people keep the default flow which just triggers a notification. This is great, but doesn't track actionability.
Based on the above you could:
- Have an SLA that follows your business schedule, and has a duration of the equivalent of 7 days. This is important, you can't just set it to 7 days as it'll be 7 calendar days. You need to specify the hour-equivalent of 7 days for your schedule. E.g a 9-5 Mon-Fri schedule would be 56hrs.
- A flow that handles this "escalation process"
- In the flow, when it breaches trigger an incident task for the service manager to review.
You can then repeat this process, or "step up" the escalation if needed. Say it goes to 14 days? What happens then.
This is also then reportable as you'll have a running SLA tracking just how much time was used
You can use SLA breakdowns to track the assignment group(s) the incident touched, and for how long
An actionable task related to the incident where the service manager completed their analysis.
