Business hours and holiday schedules for SLAs

What it does

A customer service schedule defines the working week, daily hours, breaks and time zone that an SLA counts against, and it can observe a holiday schedule of dated closures. Point an SLA at one and its warning and failure times are calculated in working hours rather than wall-clock hours.

Key facts

Both are created in the Copilot Service admin center under Calendar: the customer service calendar for working hours, the holiday calendar for closures.
Work hours can be set as the same each day, varying by day, or 24x7. Breaks can be added within a day and are excluded from SLA time.
The schedule carries a time zone and applies daylight saving automatically. The SLA calculates in that time zone, not the agent's or the customer's.
Holidays are attached by setting Observe on the customer service schedule and picking a holiday schedule. Holiday records are dated with a start and end, so someone has to add next year's dates each year.
If an SLA has no business hours schedule, it is treated as 24 hours a day, every day. That is the default and it catches people out.
Changing a schedule does not recalculate SLA KPI instances that are already running. Recalculation only happens on pause and resume, when the SLA on the record changes, when the SLA item changes, or when an instance is reapplied after a terminal state.
Worked example from the docs: 09:00–17:00 hours, 12-hour failure duration, case created at 10:00, next day a holiday. Seven hours are consumed today, the holiday is skipped, and the remaining five hours land at 14:00 the day after.
Microsoft's recommended pattern for a schedule change is to leave the old calendar and SLA active, create a new SLA pointing at the new calendar, activate it and make it the default. Edit-in-place is only advised where you also intend to force recalculation.
If you do need in-flight instances updated and pause/resume is not in use, the documented approach is to edit the calendar and then drive each affected record through a pause and a resume, in bulk, out of hours.
Where pause and resume is already in use, Microsoft says updating in-flight instances after a calendar change may give mixed results, with elapsed time part-calculated on the old calendar. Treat that combination as not properly supported.
A calendar created or last saved in the legacy web client can stop SLAs applying. Reopening and saving it in Unified Interface fixes it.

When to use / skip

Attach a schedule whenever the client's commitment is expressed in business hours, which is almost always outside 24/7 contact centres. It is a two-minute configuration that removes an entire class of "the SLA failed overnight" complaints.

Leave it blank deliberately, not accidentally, for genuinely round-the-clock commitments. Say so in the design document, because a blank Business Hours field looks like an oversight to whoever picks the system up next.

Where a client operates across regions, resist the urge to build a single clever calendar. Separate schedules per region, each with its own holiday schedule, selected via separate SLAs, is easier to explain and far easier to change.

Configuration decisions

One schedule or several, and how an SLA is chosen per region or per contract.
The schedule's time zone, and whether the client understands that it is fixed to the support team rather than following the customer.
Whether lunch and other breaks are excluded from SLA time. Excluding them is honest; including them is simpler.
Which holiday schedule each calendar observes, and who owns adding next year's dates.
Your strategy for calendar changes: new SLA and new calendar side by side, or edit in place and force recalculation.
Whether resolution SLAs use the same calendar as response SLAs. Often they should not.

Gotchas

A blank Business Hours field means 24/7, silently. There is no warning and the failure times just look aggressive.
Editing a live calendar does nothing to running cases. The client will assume it does, and will not tell you when they edit it.
Holiday schedules do not repeat. Miss the annual refresh and every bank holiday counts as working time.
A holiday added after a case's failure time was calculated does not move that failure time.
Combining a calendar change with existing paused instances gives partly-old, partly-new elapsed time. There is no clean fix.
Legacy calendars from an older implementation can look fine and still prevent SLAs applying until re-saved in Unified Interface.

Consultant notes

Walk the client through one worked example on a whiteboard, holiday included. It converts an abstract argument into a number they can check.
Put "add next year's bank holidays" into the client's operational runbook with a named owner. It is the most commonly missed BAU task in this whole area.
Push back on per-customer calendars. The maintenance burden is real and the contractual gain is usually imaginary.
Before go-live, test a case that spans a weekend and a holiday, and check the failure time by hand. Do it in the target environment — time zones differ between environments more often than they should.

Worth another look if in-flight SLA instances ever start picking up calendar changes automatically.