Business Hours Calendars

A business hours calendar defines when your organisation is open. It is what makes "four hours to respond" mean four working hours rather than four hours on the clock.

Not the same as Booking Calendars

• Booking Calendars — scheduling appointments against a resource: who is free, which slots can be booked.
• Business Hours Calendars — measuring working time, and calculating due dates that respect opening hours.

If you are booking somebody in, you want a Booking Calendar. If you are measuring how long something took, or when it is due, you want this.

What makes up a calendar

• The calendar itself — a name and a timezone.
• Its hours — the open periods for each day of the week.
• Its exceptions — individual dates that differ, such as public holidays.

How many do you need?

One per genuinely different pattern of opening — a standard business calendar, a 24×7 calendar for critical services, one per region if you operate in several. Resist creating one per team unless they really do work different hours: every extra calendar is another place holidays have to be kept up to date.

Worked Examples

• Support desk: a standard business calendar for normal cases and a 24×7 calendar for priority-one incidents.
• Multi-region: UK, Ireland and Germany calendars, each with their own public holidays.

A calendar is built in two steps: create the calendar itself, then add the open periods that make up its week.

1. Create the calendar

Give it a name and a timezone. Name it for what it represents — "UK Business Hours", "24x7 Critical" — rather than for the team currently using it.

2. Add its hours

Add an entry for each open period, giving the day of the week and the start and end times. A standard week is five entries — Monday to Thursday 09:00 to 17:30, Friday 09:00 to 17:00, for example.

Saturday and Sunday have no entries, so the calendar is closed then. A day with no entries is closed — there is nothing to switch off.

Split days

Add two entries for the same day to model a break — 09:00 to 13:00 and 14:00 to 17:30, for a calendar that genuinely closes at lunchtime.

A 24×7 calendar

Add an entry for each of the seven days running 00:00 to 23:59.

Timezone

Hours are read in the calendar's own timezone. An organisation spanning several regions should have a calendar per region rather than one calendar and a lot of mental arithmetic.

An exception overrides the weekly pattern for one specific date, in either direction.

A closure

Mark the date as non-working — public holidays, a shutdown period, an office move. The date then contributes no working time and calculations skip over it.

A special working day

Mark the date as working and give it its own hours — a Saturday opening, a shortened day before a holiday, cover during an unusual period.

Each exception can carry a note. Use it: "August bank holiday" is far more helpful to whoever maintains this next year than a bare date.

This is the part that gets forgotten

A calendar with last year's holidays quietly produces wrong due dates every time one of those dates comes round. Nobody notices until a customer points out that a target was missed over Christmas — by which time you have a month of incorrect measurements behind you.

• Load next year's public holidays as an annual task, with a reminder in somebody's calendar.
• Load them into every calendar, not just the main one.
• Remember that different countries have different holidays if you operate in more than one.
• Do it in advance. A holiday added after the event does not retrospectively correct due dates already calculated.

A calendar on its own does nothing. It becomes useful in two places.

Calculating due dates

The Workflow Builder's SLA node works out a due date and writes it to a field. Point it at a calendar and it counts in working hours.

Four working hours from 4:00pm on a Friday, against a Monday-to-Friday 9:00–17:30 calendar, is 11:30 on the Monday — one hour on the Friday and three more on Monday morning. Measured as plain elapsed time it would be 8:00pm on the Friday, when nobody is there to do anything about it.

Omit the calendar and you get the second answer, which is rarely what a customer commitment means.

Measuring how long something took

ActiveManage can calculate the working time between two moments, which is the honest way to report responsiveness. A case raised at 4:45pm on Friday and resolved at 9:15am on Monday took 64 hours on the clock and 45 minutes of working time. The first number tells you almost nothing; the second tells you exactly how the team performed.

Practical advice

• Store the due date on the record. Recalculating it later gives a different answer if the calendar has since changed.
• Measure against the calendar the commitment was made under. Reporting a 24×7 service against a business-hours calendar flatters the figures considerably, and somebody will eventually notice.
• Agree what starts the clock — when it was raised, or when it was assigned — and make sure everyone means the same thing. This causes more arguments than the calendar ever will.
• Recalculate deliberately. If a priority change should move the due date, make that an explicit step and record that it happened.