Five working hours do not always mean 300 resolution minutes

A worked example from the support app. These are sample calculation results, not a customer performance claim.

Active working interval

300 min

The example spans five hours inside the configured support window.

Employee-information waits

−45 min

Two permitted waits of 30 and 15 minutes are excluded from resolution time.

Vendor wait

0 min deducted

The example policy does not pause for a vendor dependency.

Resolution working time

255 min

300 − 45. This is not labor effort and is not the first-response time.

Define the clock before judging its result

What the example service policy measures
MeasureIntervalCalculation rule
First responseReported time → first recorded responseWorking minutes; later progress notes do not reset the first response.
ResolutionCurrent active cycle plus prior active cyclesSubtract only the waiting reasons the captured policy permits.
Closed intervalResolution → reopeningDo not add the closed gap to the new active cycle.
Support calendarMonday–Friday, one daily windowExclude configured closure dates and use the recorded UTC offset.

Handle corrections, reopening, and missed commitments

Corrected waiting record

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.

Reopened ticket

A further 60 working minutes after reopening adds to the prior 265, producing 325 minutes. The closed overnight interval is not active resolution time.

Target missed

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.

Calendar exceptions

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.

Make service commitments understandable

Understanding service targets

Is ticket age the same as resolution time?

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.

Does an automatic acknowledgment count as a first response?

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.

How are holidays handled?

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.

Does the example support every shift or time zone?

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.

How often are breaches detected?

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.

Can a free plan handle unlimited service-clock checks?

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.

Make service commitments explainable

Inspect the calculation and waiting history, then adapt targets, working hours, and escalation ownership to a policy your team can support.

Explore service target tracking