Plan holiday coverage and understand its effect on SLA timing

Updated Wednesday, October 28, 2026 · Marcel Gravelle

Holiday schedules identify dates that a team does not count as normal service time for applicable business-hour SLA calculations. They help a B2B support team align measured commitments with its actual service calendar, especially when regional teams observe different holidays. A holiday schedule is only one part of coverage planning: you still need the correct team assignment, working hours, SLA clock and customer communication plan.

At a glance

For: support operations managers, team leads and administrators planning service coverage. Applies to: Supportbench Core.

Start here: Settings → Holiday schedules; Settings → Teams → Holiday schedule

Separate holidays, working hours and availability · Prepare the service and access decisions · Create and verify a holiday schedule · Assign the schedule to the correct team · Verify the SLA result, not just the calendar entry · Worked example: two regional teams and a priority customer · Maintain schedules without creating coverage surprises · Troubleshoot holiday timing and availability

Separate holidays, working hours and availability

Control or concept	What it represents	What it does not prove
Holiday schedule	Exact dates or date ranges excluded by applicable business-hour SLA calculations for a resolved team.	That every Case or every SLA clock pauses, or that the dates recur automatically next year.
Team working hours	The normal service windows used by the relevant process.	That a regional holiday has been entered or that every agent is available.
Elapsed-time / 24/7 SLA clock	A commitment measured continuously rather than through the same working-time exclusions.	That a business-hour holiday will stop its elapsed minutes.
Mark agent unavailable event category	An assigned agent’s unavailable/away state for applicable workload and reporting behavior.	That the team’s holiday schedule or every Case deadline changes.
Stop SLA timers event category	SLA timing treatment for applicable team/shared calendar events.	A substitute for checking the Case’s team, calendar and clock.
Global fallback holiday schedule	A fallback after no active schedule is resolved on the team or its parent-team hierarchy.	An override of an active team or inherited parent schedule, or a guarantee for a Case with no resolved team.

Use the dedicated configuration references for the full settings. Do not describe every calendar entry as an SLA pause. First identify which mechanism represents the actual service commitment, then validate it on the relevant Case path.

Prepare the service and access decisions

List the teams, regions and service commitments affected. Separate business-hour contracts from commitments that require continuous coverage.
Confirm the team’s regular working hours and the queues that route work to it. The holiday schedule should complement those settings.
Identify the administrator who will maintain dates. Editing schedules requires Administer global calendars. Changing the global fallback additionally requires Administer teams; assigning a schedule on a team requires team-edit authority.
Decide whether a shared fallback is appropriate or whether regional teams require their own schedules. Keep the naming understandable, for example “UK service holidays” rather than an unexplained internal code.
Prepare the exact dates and date ranges, including observed days when relevant to your own service policy. A date entered for one year is not a recurring rule.
Agree who provides urgent coverage, who monitors queues and what customers should be told. Calendar configuration does not itself send a customer notice or appoint an on-call agent.

Create and verify a holiday schedule

Open Settings → Holiday schedules and choose New Holiday Schedule.
Give the schedule a clear name and review Active schedule. An inactive schedule should not be relied on for current holiday exclusions.
Review Global fallback / Use as default holiday schedule only if you intend this schedule to be the fallback after no active team or parent-team schedule applies. Confirm the affected teams before changing the fallback.
Save the schedule first. Adding dates belongs to the saved schedule, so do not stop after entering its name.
Under Holiday dates, click once to select a single day, or select/drag a second date to make a range. Both endpoints are included. Review the selected dates before adding them.
Enter the holiday name in Name this holiday..., then choose Add Date. Repeat for each intended holiday or range.
Review the saved dates and names. Reopen the schedule to confirm the intended entries and active/fallback state. Check that a range has not accidentally included an additional working day.

Plan the next year explicitly

Holiday schedules store exact dates. Review the coming year as part of your coverage planning and add its actual dates; do not assume this year’s entries repeat. Keep a named owner and a review date so the service calendar remains current.

Assign the schedule to the correct team

Open Settings → Teams and edit the intended team. Confirm the team name and the queues it serves.
Find Holiday schedule and select the intended saved schedule. An active schedule on the team takes precedence. Without one, Core can inherit the nearest active parent-team schedule; the active global fallback applies only when no team-hierarchy mapping resolves.
Save the team, reopen it and verify the saved selection.
For a team intended to use the fallback, check that neither the team nor its parent-team hierarchy supplies an active schedule. Then confirm that the intended global fallback is active and contains the correct dates.
Check the Case routing that determines the team. Core first resolves the active queue hierarchy’s team and then falls back to the Case owner’s team. Do not assume the owner’s personal calendar always determines the Case’s holiday behavior.
Choose representative Cases for verification, including a team-specific schedule and a fallback team when both are used.

A Case with no resolved team does not have a guaranteed team holiday mapping. Resolve the intended queue/team ownership and service configuration rather than assuming that a global fallback applies universally. Moving work between teams can also change which service calendar is relevant; review commitments during a handoff.

Verify the SLA result, not just the calendar entry

Verification case	What to inspect	Expected interpretation
Business-hour SLA with a team-specific holiday	Case queue/owner, resolved team, selected active schedule, exact date and business-hour clock.	The configured holiday can be excluded from the applicable business-hour calculation.
Business-hour SLA on a fallback team	No active schedule on the team or parent hierarchy; correct active global fallback and matching holiday dates.	The fallback supplies the team’s holiday dates.
Continuous / elapsed-time SLA	The actual clock setting and the deadline or elapsed measure.	Do not expect the business-hour holiday exclusion to pause this clock in the same way.
Case routed to a different regional team	Queue hierarchy and team assignment after the handoff.	Use the calendar resolved for the relevant team; do not infer it from the customer’s country alone.
Agent unavailable but team open	The event category, assigned agent and team’s separate service hours.	Agent availability and the team’s SLA schedule are different controls.
Next-year holiday	The year and exact saved dates.	An old date does not establish a repeating annual holiday.

Inspect a representative deadline or elapsed-time result using the correct service context. Avoid promising that editing a calendar rewrites every historical deadline or report immediately. If an existing Case’s displayed timing does not match the intended policy, record the Case, clock, team and dates and ask the administrator to investigate the applicable calculation and refresh path. Do not change a live Case’s status merely to make its timer look right.

Worked example: two regional teams and a priority customer

An equipment supplier has a UK support team and a North American support team. Most contracts use each team’s business hours, while a small group of critical-service customers has continuous coverage. The operations lead creates separate regional holiday schedules and assigns each to the relevant team. A shared fallback is used only for teams that genuinely follow the same calendar.

Before a UK holiday, the lead reviews the affected queues, confirms the date in the UK schedule, and checks a representative business-hour Case. A continuous-coverage customer is handled through its separate commitment and coverage plan; the lead does not assume the holiday pauses that obligation. Agents receive an explicit handoff for urgent work, and customer communications explain the agreed service arrangements.

After the holiday, the team reviews overdue work and any surprising deadline. The useful outcome is a calendar that reflects the service agreement and a clear ownership plan. The schedule alone does not prove that incoming requests were monitored or that a customer was informed.

Maintain schedules without creating coverage surprises

Review the next quarter’s dates and the coming year before customers depend on them. Confirm observed holidays with the responsible regional service owner.
Recheck team-specific selections when teams or queues are reorganized. A new fallback does not replace an active team or inherited parent choice.
Before deactivating or replacing a schedule, identify the teams using it and review the intended replacement.
Keep agent absence, team service hours and SLA exclusions separately understandable. Avoid using a vaguely named event to represent several different policies.
When a commitment changes, update the customer-facing service explanation and the relevant operating guide alongside configuration.
Investigate exceptions with concrete Case IDs, dates and clock settings. Compare like-for-like commitments before deciding that a calendar is wrong.

Troubleshoot holiday timing and availability

Problem	Checks and corrective action
The SLA still runs during a holiday	Check whether the clock is elapsed/24/7, the Case resolves to the expected team, the schedule is active and the exact date is included.
A team ignores the global holiday	Inspect its own Holiday schedule and parent-team mappings; active team or inherited schedules take precedence over the global fallback.
One Case behaves differently from another	Compare clocks, queue hierarchy, owner/team and relevant service commitments. Similar subjects do not establish the same timing rules.
The schedule has a name but no effect	Reopen Holiday dates and verify entries were added after the initial save.
The holiday applies on the wrong day or year	Check the saved start/end dates and intended service date, then correct through the authorized schedule editor.
An agent is unavailable but customer deadlines remain	Review the separate event category and SLA calendar/clock. Agent availability alone does not establish a universal SLA pause.
The default schedule control cannot be changed	Check both calendar-administration and team-administration permissions.
The schedule cannot be assigned to a team	Confirm team-edit authority and the intended saved schedule’s availability.
A case with no clear team does not follow the fallback	Review queue/owner team resolution. A fallback schedule is not an unconditional account-wide clock override.
Last year’s holiday did not recur	Add and verify the current year’s exact dates; schedules are not automatically recurring rules.

Was this article helpful?