Active working interval
300 minThe example spans five hours inside the configured support window.
Track first-response and resolution targets for internal support, including working hours, permitted waits, and tickets that need attention.
Explore with sample data. Adapt fields, views, and workflows for your team.
A worked example from the support app. These are sample calculation results, not a customer performance claim.
The example spans five hours inside the configured support window.
Two permitted waits of 30 and 15 minutes are excluded from resolution time.
The example policy does not pause for a vendor dependency.
300 − 45. This is not labor effort and is not the first-response time.
| Measure | Interval | Calculation rule |
|---|---|---|
| First response | Reported time → first recorded response | Working minutes; later progress notes do not reset the first response. |
| Resolution | Current active cycle plus prior active cycles | Subtract only the waiting reasons the captured policy permits. |
| Closed interval | Resolution → reopening | Do not add the closed gap to the new active cycle. |
| Support calendar | Monday–Friday, one daily window | Exclude configured closure dates and use the recorded UTC offset. |
Changing the second permitted wait from 15 to 5 minutes makes the same example total 265 minutes. The correction changes the linked ticket calculation instead of leaving a stale copied total.
A further 60 working minutes after reopening adds to the prior 265, producing 325 minutes. The closed overnight interval is not active resolution time.
A target state and linked escalation record identify which commitment needs manager attention. Record the owner’s action; a colored status alone is not a response.
Keep closure dates explicit and unique. The example supports a fixed UTC offset and one Monday–Friday working window, not rotating shifts or automatic daylight-saving transitions.
Active tickets are rechecked on a configurable schedule; the example uses 15-minute checks. This is not continuous monitoring. Scheduled checks and record-triggered updates consume automation runs, so size the interval and plan for the number of active tickets.
No. Age may include nights, weekends, closed intervals, and permitted waiting. The resolution clock follows the configured working calendar and pause rules. Actual technician effort is recorded separately in work logs.
The example records an explicit First response activity. Your service policy should define what counts as a meaningful response; it should not silently treat an automated receipt as a human answer.
Maintain closure dates in the service calendar. The working-time calculation excludes matching dates. Check the calendar and fixed UTC offset before using the app for contractual reporting.
No. It uses one Monday–Friday working window and a fixed UTC offset. Multiple daily shifts, rotating schedules, automatic daylight-saving changes, and complex contractual calendars require additional design or a specialist service tool.
Record changes trigger recalculation and active tickets also receive scheduled checks, set to 15 minutes in the example. Detection can lag until a check runs; do not treat it as real-time outage monitoring.
No. Automation runs and data usage have plan limits. Estimate active tickets multiplied by scheduled checks, then include activity-driven automation before selecting an interval and plan.
Inspect the calculation and waiting history, then adapt targets, working hours, and escalation ownership to a policy your team can support.