Business Hours
A business hours calendar records when your organisation is working. It is a different thing from a booking calendar and is used for a different purpose.
Where to find it
Architect Panel → Data:
- Business Hours Calendars — working hours and exceptions
Architect Panel → Automation:
- Escalation Steps — which run in working hours
What it is
A named calendar with a time zone, holding working hours per weekday and a list of exceptions. That is all — deliberately, because it is a definition rather than a schedule.
What depends on it
- Service levels — a four-hour response means four working hours, not four hours including the night.
- Escalation — steps that fire after a period should count working time.
- Due dates — three days from Thursday is Tuesday, not Sunday.
- Reporting — time-to-resolve figures that mean something.
All of these are wrong in the same direction without it: everything looks slower than it is, and targets get missed on paper for work done promptly.
The time zone is on the calendar
Which matters as soon as you operate anywhere else. A calendar without the right time zone is a calendar that is wrong by hours, in a way nobody notices because the numbers look plausible.
Several calendars are normal
Different teams, regions and services keep different hours. A support desk running twelve hours, an office running seven and a half, an out-of-hours service running always — each needs its own.
They are cheap to create. Sharing one across teams whose hours differ is the mistake.
Get it right before measuring anything
Once service levels have been reported against a wrong calendar, the history is wrong too. Set the calendar up before you start measuring, not after somebody queries a figure.
It is a definition, not a wish
Record the hours you actually work. A calendar saying nine to five for a team that is present from eight makes every measurement slightly wrong, and a calendar saying nine to five for a team that leaves at four makes promises you break.
Review it annually
Hours change, teams change, holidays differ each year. An annual review alongside loading the next year’s exceptions keeps it honest.
Worked example
An organisation runs three calendars — a UK office calendar, a twelve-hour support calendar, and a 24-hour calendar for critical incidents — each with its own time zone. Service levels reference the right one, so a ticket raised at five on Friday is not reported as taking three days.
Recommendations
- Set the time zone explicitly on every calendar.
- One calendar per set of hours, not one shared.
- Configure before measuring anything.
- Record real hours, not aspirational ones.