Using Hours for Targets
A business hours calendar is only useful once something references it.
Where to find it
Architect Panel → Data:
- Business Hours Calendars — working hours and exceptions
Architect Panel → Automation:
- Escalation Steps — timing that should respect working hours
Architect Panel → Data:
- Query Builder — reporting on elapsed time
What changes
Elapsed time stops being wall-clock time. A request raised at half past four on a Friday with a four-hour target is due at half past eleven on Monday, not at half past eight on Friday evening.
That is the whole point, and it is the difference between targets that describe your service and targets that describe the calendar.
Attach the right calendar
Different services have different hours. A target measured against the wrong calendar is wrong by exactly the difference between the two, consistently, in a way that looks like a performance problem.
Do not measure before configuring
History reported against a wrong or missing calendar stays wrong. If you are introducing service levels, set the calendars up first and start measuring from a known date.
Escalation should respect hours too
An escalation that fires at three in the morning wakes somebody for something that could have waited, or more often notifies a queue nobody is reading and achieves nothing.
Escalations that count working time escalate when there is somebody to escalate to.
Explain it to the people measured by it
Working-hours measurement is not obvious, and somebody who believes they missed a target they actually met will argue rather than improve. Explain how the clock works before publishing figures.
Say so in the customer-facing promise
"Four working hours" rather than "four hours", with the hours stated. A customer who expects a reply at eight in the evening because you said four hours is a customer with a legitimate complaint.
Watch what happens at the edges
Requests arriving just before closing, just before a holiday, or at the weekend are where working-hours calculation is most visible and most often questioned. Check a few of those specifically.
Review the calendar when performance shifts
A sudden change in service-level performance with no change in the work is usually a calendar — hours edited, an exception added, or a team moved to a different one. Check that before investigating the team.
Worked example
An organisation attaches its support calendar to response targets and escalation, having configured it before measurement began. When performance appeared to drop one month, the cause was an exception added to the wrong calendar — found in minutes because the calendar was checked first.
Recommendations
- Configure calendars before measuring.
- Make escalation respect working hours.
- Say "working hours" in customer-facing promises.
- Check the calendar first when performance shifts.