Skip to main content

Admin Pro Tip: Business Hours and Schedules - Reality vs. Theory

Updated

In theory, setting up Business Hours and Schedules in Zendesk is straightforward. You define when the organisation works, and Zendesk calculates when a ticket must be answered in order to meet its SLA. In practice, this is one of the most misunderstood and error-prone areas of Zendesk administration. An incorrectly configured schedule can, at best, produce confusing SLA times and, at worst, affect service agreements and customer trust.
You often see schedules that have not been updated in years, teams that struggle with time zones, and situations where a public holiday occurs without the system being updated. This article brings together experience, practical solutions and pro tips for getting schedules to reflect actual operations rather than a theoretical ideal state.

The foundation: Why Schedules are much more than a calendar

Before reviewing the pitfalls, it is crucial to understand what a schedule does in Zendesk. A schedule is not merely a note about opening hours. A schedule acts as the engine behind SLA calculations and specifies when "the clock is ticking" on a ticket and when it is paused.

When a ticket is created outside defined Business Hours, the SLA calculation only starts when the next Business Hour begins. The same applies to gaps between days. An SLA of 8 hours with opening hours of 9-5 does not mean 8 calendar hours, but 8 business hours. That is a crucial difference.

This engine is linked to three central places in Zendesk:

  1. SLA Policies: Here you define service targets (e.g. First reply time, Next reply time, Resolution time). Each policy is associated with a schedule.
  2. Views: Here tickets can be filtered based on whether the SLA is met or at risk of being breached, based on their schedule.
  3. Automations and Triggers: Here logic can be built that responds to whether a ticket is at risk, or if the SLA has been breached.

Errors in the schedule configuration therefore propagate through the entire support setup and can create a chain reaction of inaccurate data, incorrect alerts and, ultimately, a poor customer experience.

Common errors in schedule configuration – the pitfalls many encounter

There are a number of classic errors that often arise in schedule configuration. By knowing them, the most common and costly mistakes can be avoided.

Error #1: The "set and forget" syndrome

This is one of the most widespread errors. Time is spent setting up schedules, after which they are not maintained. Operations change: opening hours are adjusted, public holidays change, and teams expand or shrink.

  • How it looks: A primary schedule was created in 2019 and has not been updated since. A holiday schedule still contains "Great Prayer Day" (Store Bededag), even though it has been abolished.
  • Why it is a problem: SLA calculations gradually become more inaccurate. A ticket created on Wednesday evening can be given an incorrect delay if the opening hours have changed. It undermines trust in the data.
  • The solution: Make schedule reviews a fixed part of a quarterly or half-yearly Zendesk audit. Create a recurring task in a project management tool (Asana, Trello, Jira) with a repeating deadline: "Review and update Zendesk Schedules".

Error #2: Confusing "Business Hours" and "Agent Schedule"

Zendesk has two concepts that are often confused: Schedules (under Admin > Business Hours) and Agent Schedules (under Admin > People > Schedules). They have different purposes.

  • Business Hours Schedule: Defines when the organisation is open to provide support. This is the engine that drives the SLAs.

  • Agent Schedule: Used primarily to see who is on duty, and to assign tickets based on whether an agent is "online" or "offline" in a given period. This has no direct influence on SLA calculations.

  • How it looks: Attempts are made to manage things via Agent Schedules, and confusion arises because the SLAs keep running even though no agents are "online".

  • Why it is a problem: Time is spent configuring the wrong tool. The SLA engine (Business Hours Schedule) runs independently of duty rosters.

  • The solution: Keep the concepts separate. Use Business Hours Schedules to define service commitments to customers. Use Agent Schedules for operational planning and duty rostering. They can support each other, but they are not the same.

Error #3: Ignoring time-zone complexity

Even for a single team in one time zone, the time-zone setting is critical. Zendesk calculates everything based on the time zone the schedule is set to.

  • How it looks: A team in Copenhagen (GMT+1/GMT+2) has a primary schedule set to "Pacific Time (PT)".
  • Why it is a problem: Opening hours of 9-5 are understood as 9-5 PT, which corresponds to 6pm-2am Danish time. Tickets created in the morning in Denmark may be treated as created "outside opening hours", and the SLA only starts many hours later.
  • The solution: Choose the correct time zone when creating the schedule, and double-check the setting. A practical rule of thumb is to name schedules with the time zone, e.g. "Support DK - CET (GMT+1)".

Error #4: Overlaps, gaps and "orphaned" tickets

This is a subtle but risky error, especially with multiple shifts or coverage across time zones.

  • How it looks: A morning shift of 8-4 and an evening shift of 4-midnight are set as 8-4 and 4:01pm-midnight, or 8-3 and 4-midnight.
  • Why it is a problem: A gap (e.g. between 3:59pm and 4:01pm, or between 3 and 4) means that Zendesk considers the organisation closed during the period. A ticket created in this time frame gets a delayed SLA start, even though there is in fact staffing. This produces inaccurate reports and can make a ticket appear to be breached.
  • The solution: Make sure intervals align precisely. For a 24-hour schedule: e.g. 00:00 - 23:59. For shifts: e.g. 08:00 - 16:00 and 16:00 - 00:00. No gaps and no overlaps.

Handling holidays and sickness – the SLAs' number one enemy

Unforeseen absence or a forgotten public holiday can quickly affect the SLA overview. The approach below helps maintain control without panic.

The wrong way: Manually changing primary schedules

A typical reaction is to change the opening hours directly in the primary schedule for a holiday, e.g. "On Christmas Eve we are only open until 12".

  • Why it is a disaster: The method is error-prone. It is easy to forget to change it back. It creates history in the primary schedule and makes it harder to see "the norm". With multiple schedules, all of them must be changed. The solution is neither scalable nor safe.

The right way: Using Holiday Schedules

Zendesk supports Holiday Schedules. A holiday schedule is a separate schedule with specific dates and times when you are closed or have reduced opening hours.

Procedure:

  1. Create a Holiday Schedule: Go to Admin > Business Hours > Holiday Schedules. Create a new schedule, e.g. "Holidays DK 2024".
  2. Define the holidays: Add all Danish public holidays for the year. For a full closure, add the date with an interval that covers the whole day (e.g. 00:00 - 23:59).
  3. Handling "half days": For Christmas Eve or New Year's Eve with reduced opening hours, two periods can be used:
    • One period for normal opening hours (e.g. 09:00 - 12:00).
    • One period for the rest of the day as "closed" (e.g. 12:01 - 23:59).
      This specifies that SLAs only run in the 9-12 time frame that day.
  4. Link the Holiday Schedule to SLA Policies: Go into each SLA Policy and select the relevant holiday schedule under "Holidays". Zendesk will then automatically account for holidays in SLA calculations for tickets covered by that policy.

Proactive planning: The holiday calendar

A recommended practice is a dedicated task for holidays, carried out quarterly:

  • Q1: Review and add holidays for Q2.
  • Q2: Review and add holidays for Q3.
  • Q3: Review and add holidays for Q4 (incl. Christmas and New Year).
  • Q4: Review and add holidays for Q1 of the next year.

This reduces the risk of surprises and ensures up-to-date schedules well in advance.

Handling sickness: The human factor

Zendesk cannot predict sickness, and schedules should not be used to "close" support during absence. The focus should be on managing the consequences.

  • Approach: Views are used to monitor workload. In the event of sickness, a manager can quickly assess pressure via a view such as "Unanswered Tickets - Today".
  • Fallback mechanisms: For critical tickets, an escalation path can be used. If a ticket approaches the SLA limit and the assigned agent is off sick, a trigger can automatically send a notification to a group or a manager so that reassignment can happen.
  • Important: Sickness does not change Business Hours. The organisation remains "open" as defined. Changing the schedule because of sickness creates inaccurate SLA data; the focus should be on redistributing the work.

Multi-time-zone teams – the architecture behind a global support team

Global support across multiple offices requires a robust architecture.

The core principle: One schedule per time zone/region

A frequent error is trying to create one "global" schedule that covers all time zones. It quickly becomes unmanageable.

  • Method: Create a primary schedule per region/location:
    • Support København - CET
    • Support London - GMT
    • Support San Francisco - PST

Each schedule defines local opening hours for the team in question.

Follower Schedules – the elegant solution

To ensure coverage around the clock, when one team closes and another opens, Follower Schedules are used.

A follower schedule follows another schedule and is designed for exactly this.

Here is how to establish a "Follow the Sun" setup:

  1. Create the primary schedules: Create Support København, Support London, Support San Francisco with their respective time zones and opening hours.
  2. Create a "global" follower schedule: Create a new schedule, e.g. Global Support - 24/5. Set the time zone to UTC (often good practice for global schedules).
  3. Configure follower intervals: Instead of fixed times, select "Follows a different schedule" for each interval:
    • Interval 1 (Monday-Friday): Follow Support San Francisco - PST from start time to end time.
    • Interval 2 (Monday-Friday): Follow Support London - GMT from start time to end time.
    • Interval 3 (Monday-Friday): Follow Support København - CET from start time to end time.

The result is one consolidated schedule (Global Support - 24/5) that follows coverage across teams.

Practical example: Copenhagen–San Francisco–London setup

  • Primary schedules:
    • SF - PST: 09:00 - 17:00 PST
    • London - GMT: 09:00 - 17:00 GMT
    • CPH - CET: 09:00 - 17:00 CET
  • Follower schedule Global - 24/5:
    • Monday-Friday: Follow SF - PST from 09:00 to 17:00 PST.
    • Monday-Friday: Follow London - GMT from 09:00 to 17:00 GMT.
    • Monday-Friday: Follow CPH - CET from 09:00 to 17:00 CET.

Result: A ticket with a 2-hour SLA has the "timer" running, regardless of which team is on duty. If the ticket is created at 16:30 PST, the SF team has 30 minutes to respond. If they do not manage it, the timer "freezes" when SF closes and starts again when London opens, where the London team has the remaining 1.5 hours.

Important: Global SLA Policies must be linked to the Global - 24/5 follower schedule and not to the regional schedules.

Communication and handover protocols

Technology alone does not solve a multi-time-zone setup; communication is crucial.

  • Handover notes: An internal macro or a custom field can be used for short handover notes, e.g.: "Ticket set to 'Pending' by the SF team. Awaiting a reply from the customer. The CPH team will follow up tomorrow morning."
  • Shared Slack/Teams channel: A dedicated channel for "Global Support Handover" can be used to share links to tickets that require special attention at the next shift.
  • Joint meetings: A weekly 15-minute meeting between team leads from each time zone can be used to discuss trends, problems and upcoming changes.

Edge cases – when reality challenges theory

Unforeseen events such as outages, product launches or sudden changes in opening hours require a plan.

Edge case #1: The "extraordinary day" (outages, launches)

During major incidents, there may be a need for faster escalation and coverage outside normal opening hours.

  • Solution: A temporary "incident" schedule
    1. Create a temporary schedule, e.g. Incident Schedule - [Date] - 24/7.
    2. Set the schedule to be open 24/7 for the relevant day or period.
    3. Create a temporary SLA Policy, e.g. Incident Response - 30 min, and link it to the new Incident Schedule.
    4. Create a trigger that automatically adds a specific tag (e.g. incident_2024_10_26) and applies the new Incident Response SLA Policy to relevant tickets during the period.
  • Advantage: The change is controlled and temporary. When the incident is over, the trigger is deactivated, and the temporary schedule and policy can be removed. The normal setup remains unchanged.

Edge case #2: The "on-call firefighter" schedule

There may be a need for one person to be on duty outside normal hours, but only for the most critical enquiries.

  • Solution: A combination of tag, trigger and view
    1. Create a specific tag, e.g. urgent_on_call.
    2. Create a trigger that responds to the tag and can send an SMS or push notification via an integration (e.g. PagerDuty, Slack) to the relevant on-call person.
    3. Create a view, On-Call Queue, that shows all unanswered tickets with the urgent_on_call tag.
  • Important: The Business Hours Schedule should not be changed for this purpose. The SLA for these tickets can still be based on normal opening hours, while the notification ensures faster attention. This is an alert, not a change to the service commitment.

Edge case #3: Partial days (company party, training)

If the whole team is to leave early, the opening hours may be reduced for a single day.

  • Solution: Use Holiday Schedules
    This can be handled in the existing holiday schedule by adding a new day:
    • Date: [Date of company party]
    • Time 1: 09:00 - 14:00 (open)
    • Time 2: 14:01 - 23:59 (closed)

This is traceable and easy to roll back.

How to test schedules – assumptions are not enough

Schedules should be tested regularly to ensure correct functioning.

The sandbox environment

If you have access to the Zendesk Sandbox, changes can be tested without affecting production data.

  1. Clone the setup: Make sure the Sandbox is a recent clone with up-to-date schedules and SLA Policies.
  2. Create test scenarios: Work through the situations as described in this article.

Manual test: "Time machine" tickets

This is an effective testing method that can be carried out in the Sandbox and in production (with care).

  1. Create a test ticket: Create a new ticket.
  2. Manipulate the time: Before the ticket is submitted, change the creation time. Click the calendar icon next to "Due date" (or in advanced options) and set Created at to a future date and time.
  3. Test scenarios:
    • Holiday test: Set Created at to 10:00 on a public holiday. Submit the ticket and check the SLA gauge. It should be green, since the holiday schedule is active. Also check the "Due date", which should fall on the next open business day.
    • Multi-time-zone test: Set Created at to 17:30 San Francisco time on a Friday. Check when the SLA expires. It should be Monday morning London time, if the follower schedule is correctly configured.
    • "Gap" test: Set Created at to a time with a possible gap between shifts. Check whether the SLA responds as expected.

Using triggers and automations for verification

Simple triggers can support testing.

  • Example trigger:
    • Condition: Ticket > Is > Created | Ticket > Created at > Is > -X hours (e.g. -2 hours)
    • Action: Add tag schedule_test_2h_ago

You can then create a ticket with a creation time 2 hours in the past to see whether the tag is added. This can help verify time zones and calculations.

The checklist: What should be verified?

Testing should be carried out systematically:

  • Normal weekday: Is a ticket created at 10:00 on Monday handled correctly?
  • Outside opening hours: Is a ticket created at 20:00 on Wednesday paused until 9:00 on Thursday?
  • Weekend: Is a ticket created on Saturday paused until Monday morning?
  • Public holiday: Is a ticket created on a public holiday treated like a weekend?
  • Half holiday: Is a ticket created on Christmas Eve at 11:00 handled correctly, and a ticket at 13:00 paused?
  • Multi-time-zone: Is a ticket that crosses between three time zones handled correctly by the "winning" schedule?
  • Time-zone check: Create a ticket in a different time zone than the local one (via VPN or with help from a colleague). Does the SLA calculation look correct?

Red flags: Schedules that do not match operations

The following signals indicate that the setup may be heading off course:

  • The Holiday Schedule has not been updated in over a year. This often indicates that holidays have not been updated or that changes to existing ones have been missed.
  • Agents repeatedly experience that SLAs are "wrong". A lack of trust in the data is a clear sign of errors in the configuration.
  • Only one schedule is used, even though there are teams in multiple time zones. This often creates confusion and incorrect calculations.
  • Primary schedules are changed manually for holidays or special events. This is unsafe and unsustainable in the longer term.
  • Responsibility for schedules is unclear. Without clear ownership, maintenance is often deprioritised.
  • SLA reports show strange fluctuations around weekends and holidays. This can indicate that schedules do not handle pauses correctly.
  • "It has always been this way." In a schedule context, this is often a sign of a lack of review.

Green flags: Realistic schedules used in practice

The following characterise a healthy and reliable schedule architecture:

  • There is a documented and recurring process for review and updating (at least quarterly).
  • Schedules are named clearly and distinctly, including the time zone (e.g. Support_NAM_PST, Support_EU_CET).
  • Holiday Schedules are used as the standard method for closure days.
  • Follower Schedules are used to consolidate global coverage for multi-time-zone teams.
  • There is a test plan that is used for major changes to schedules or SLAs.
  • The support team can identify which schedule a ticket uses and understands the basic SLA calculation.
  • Schedules reflect actual coverage rather than desired coverage. If coverage is in fact lower on certain days, schedules should reflect this (e.g. via longer SLA times on Fridays).

Mastering Business Hours and Schedules requires ongoing attention, common sense and a willingness to reflect actual operations in the system. When the configuration works, it creates a foundation of reliability and precision that strengthens the entire Zendesk setup. It is not the most visible part of the work as a Zendesk admin, but it is among the most crucial.

Powered by Zendesk