Business Hours Calendars

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.

Setting Up Hours

Hours are defined per weekday as a start and an end time.

Where to find it

Architect Panel → Data:

• Business Hours Calendars — working hours and exceptions

The structure

One row per working period per weekday. A standard week is five rows; a week with a lunch break excluded is ten, because each day has a morning and an afternoon period.

Days with no rows are non-working days. That is how weekends are expressed — by absence rather than by a zero.

Split days are two rows

If your service genuinely stops for lunch and that should not count toward a response target, define two periods for that day. If it does not stop, do not — the extra precision is only worth it if it is true.

Shifts and long hours

A day can hold whatever periods you need. A support desk running seven in the morning to eight at night is one long period; one running two shifts with a gap is two.

Round-the-clock is midnight to midnight on every day, which is worth setting up properly rather than approximating.

Match the time zone to the team

Not to the server, not to head office. The calendar describes when a particular team is working, and that team is somewhere.

Name it for what it is

"UK Support 08:00-18:00" rather than "Calendar 2". Somebody attaching a service level to a calendar six months from now needs to pick the right one from a list, and the name is all they have.

Check the arithmetic

Add up the hours per week and see whether the number is what you expect. A transposed time or a missing day is invisible in a list of rows and obvious in a weekly total.

Test with a real calculation

Take something raised at five on a Friday with a four-hour target and confirm the due time lands on Monday morning rather than Friday night. That single check catches most configuration errors.

Then load the exceptions

Hours define the pattern; exceptions handle the days that differ. Neither is complete without the other, and a calendar with perfect hours and no holidays will be wrong roughly ten times a year.

Worked example

A support calendar defines Monday to Friday, eight to six, in the team’s own time zone, named for its hours. The weekly total was checked at fifty hours, and a test calculation from a Friday afternoon confirmed the due time fell on Monday morning.

Recommendations

• Weekends by absence, not by zero-length rows.
• Split days only where it is true.
• Name calendars for their hours.
• Check the weekly total and one real calculation.

Holidays and Exceptions

Exceptions handle the days that do not follow the weekly pattern.

Where to find it

Architect Panel → Data:

• Business Hours Calendars — working hours and exceptions

An exception can go either way

Each names a date and says whether it is a working day. So the same list handles a closure — a public holiday, a shutdown, a training day — and extra opening, such as a Saturday you are unusually working.

A working exception can carry its own times, so a half day before a holiday is a working exception ending at one o’clock rather than a closure.

Write a note on each

Six months later, an unexplained closure on a Tuesday in March is a mystery somebody has to resolve. The note takes five seconds and answers it.

Load a year at a time

The single most useful habit here. Public holidays for the coming year, the Christmas period, any planned shutdown — entered in one sitting each January.

The failure mode is never a wrong exception; it is a missing one. And a missing holiday means every target that crosses it is measured wrongly, silently.

Remember the regional differences

Holidays differ between countries and often within them — Scotland and England do not share every bank holiday, and many countries have regional ones. A calendar for a team is a calendar for where that team is.

They apply to their own calendar

Exceptions belong to one calendar, so a public holiday affecting three teams needs entering three times. That is tedious and it is correct — a 24-hour service does not stop for a bank holiday, and its calendar should not say it does.

Half days are the ones people forget

Christmas Eve, the day before a shutdown, an afternoon closed for a company meeting. These are working exceptions with shorter hours, and they are the ones that get missed because they are not obviously holidays.

Check next month

A quick look at the coming month’s exceptions, once a month, catches what was missed when the year was loaded. It takes a minute.

Emergency closures need entering too

A day lost to weather, a system failure or a building problem should be recorded, or the day’s service levels are measured as though you were open.

Worked example

An organisation loads each calendar’s exceptions every January, with notes, including half days on Christmas Eve and before its summer shutdown. Its Scottish team’s calendar carries different holidays from its English one. Exceptions for the coming month are checked at each month end.

Recommendations

• Load a year ahead in one sitting.
• Note the reason on every exception.
• Half days are working exceptions with shorter hours.
• Enter emergency closures as they happen.

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.