A booking page that reflects your normal week is easy. A booking page that reflects the fortnight around a public holiday, with one member of staff on leave, reduced summer hours and a half day on the eve of the break, is where scheduling gets fiddly.
The mistake worth avoiding is treating all of these as one problem and solving it by hand editing the schedule week by week. They are four different kinds of exception and each has a tool that suits it. Get the tool right and maintenance drops to a few minutes a quarter.
This piece covers the four types, how far ahead to set each one, the trap that catches most businesses at least once, and a checklist for a holiday period. For a team the same exceptions apply per person and per site, covered in managing multiple staff and locations.
The Four Kinds Of Calendar Exception
| Exception | Shape | Right Tool | Set It How Far Ahead | Who Owns It |
|---|---|---|---|---|
| Public holiday | Whole day, everyone, predictable | Account level date override | A year, entered in one sitting | Whoever runs the diary |
| Staff leave | Whole days, one person | Per person override or a busy calendar event | As soon as it is approved | The person, checked by a manager |
| Seasonal hours | Changed weekly pattern, fixed period | A second working hours pattern with dates | A month before it starts | Whoever runs the diary |
| Partial day closure | Part of one day | Date override with different hours | Whenever it is known | The person affected |
Public Holidays Without Hand Editing Every Week
Public holidays are the easiest exception to automate and the one most often done by hand, because each feels small enough to handle when it arrives. The cost is not the five minutes, it is the one you forget.
Enter the whole year at once. Take the national holiday list, add regional days, add the non statutory days you close such as the working days between Christmas and New Year, and enter them all as closed date overrides in one sitting. Twenty minutes in January covers the year.
Three practical notes. Public holidays are jurisdictional, so a business with sites in two countries needs two lists, applied per person where staff are split. Some holidays move each year, including those tied to Easter and those that shift when they fall at a weekend, so the list is re-entered annually rather than copied forward. And a holiday is not always a closure: if you trade with reduced staff, the exception is different hours rather than closed, and it belongs to specific people.
If your scheduling tool can subscribe to a holiday calendar, that is worth using, with one check: confirm the subscribed events are marked busy rather than free, because a free event blocks nothing.
Staff Leave
Leave differs from a holiday in that it applies to one person while the business stays open. That distinction has to survive into the tooling, or one person taking a fortnight off closes the whole booking page.
Two mechanisms work, and the better one depends on your team:
- Per person availability overrides. Reliable, explicit, visible in the scheduling tool, and cannot be knocked out by a calendar change. Best where leave is approved centrally.
- Busy events in the person calendar. Fits how most people already record leave, and works well if the sync is solid. The catch is the free versus busy default: all day events are commonly created as free, and a free event blocks nothing at all. Check one real leave entry end to end before trusting this route.
Whichever you use, enter leave the day it is approved rather than the week before it starts. Leave approved in March and entered in July is three months of accepting bookings into a period that does not exist.
Bookings That Already Exist In The Leave Period
Blocking the dates stops new bookings. It does not touch the ones already taken. Every time leave is entered, the next step is to list existing appointments in that window and deal with them: contact each client, offer a specific alternative rather than a link, and move them yourself where you can. Doing this the moment leave is entered gives clients weeks of notice. Doing it the week before is the version people remember.
Seasonal Hour Changes
Seasonal changes are a different weekly pattern for a defined period: shorter summer Fridays, extended December opening, a school holiday timetable, a quiet season where you drop to three days.
Some tools support a dated alternative working hours pattern, which is the clean answer: define the pattern, give it a start and end date, and let it take over. Where that does not exist, either change the hours on the day the season starts and reverse them on the day it ends, with reminders in your own diary for both dates, or enter the whole period as date overrides, which is more entry up front and needs no discipline later.
The failure mode with seasonal hours is asymmetric. Forgetting to apply the change means you are open longer than intended, which is inconvenient. Forgetting to reverse it means you stay closed into your busy season while clients see no availability and go elsewhere, and nothing alerts you because an empty page looks the same as a quiet week. Set the reminder for the reversal, not the start.
Seasonal patterns are also the point at which it is worth checking whether your capacity matches demand, since a reduced season and a busy season need different numbers. Capacity planning for appointments has the calculation.
Partial Day Closures
Half days are the most frequent exception and the most often fudged. The eve of a holiday, a staff meeting that takes the morning, a delivery window, an early finish for a school event.
The right tool is a date override with different hours: on 24 December, open 09:00 to 13:00. What people do instead is block the afternoon with a placeholder calendar event, which works until the placeholder is deleted, renamed or marked free by someone tidying their calendar. An availability override lives in the scheduling layer and does not depend on a calendar entry surviving.
Remember the last slot rule. If you close at 13:00 and your service block is an hour including buffer, the last bookable start is 12:00, not 12:30 and not 13:00. If your last appointment on a half day keeps overrunning the closure, a missing buffer is the more likely cause than a wrong override.
The Trap: Forgetting To Close The Page Before A Break
Here is the sequence that catches people. The break is agreed in November. Everyone knows about it. Nobody enters it into the booking system, because it is obvious and it is weeks away. Through December the page keeps accepting bookings for the last week of the month. On the first day of the break, three clients arrive.
What makes this expensive is that the failure is silent in both directions. Nothing warns you that bookings are being accepted into a period you intend to be closed, and the clients have no way to know either, because a confirmed booking looks confirmed. By the time you notice, you are cancelling appointments people arranged their week around.
The countermeasures are unglamorous:
- Enter the closure as soon as the dates are agreed, before telling anyone, so the page cannot take a booking in the gap between the decision and the configuration.
- Cap the booking horizon to something you can see the end of. A page taking bookings twelve months out will always have periods nobody has reviewed.
- Check the diary at the start of each month for the next two months, looking for bookings in periods that should be closed. Two minutes, and it catches the ones entered late.
- Set an out of office message on the booking flow rather than only on email, so a client who reaches the page during a closure understands why it is empty and knows when you return.
An empty booking page with no explanation reads as broken. An empty page with a line saying "closed until 6 January, bookings open now for the new year" reads as a business that has its affairs in order. Where demand is strong, a waitlist for the reopening period turns the closure into a queue rather than a loss: see waitlist management.
A Holiday Period Checklist
Run this a month before any closure of more than a couple of days.
- Enter the closure dates as overrides, including any half days at either end.
- List existing bookings inside the closure and contact each client with a specific alternative.
- Check per person coverage. If some staff are working, confirm their availability is intact and the closure has not been applied account wide.
- Check the reopening date. Confirm the first day back shows slots, and that the seasonal pattern reverts if one was in force.
- Adjust minimum notice if needed. A 24 hour notice does not stop someone booking the first morning back from an inbox nobody is watching. Extend it over the break if that matters.
- Set the reminder cadence. Appointments either side of a break are the ones clients forget. Check that reminders will still send during the closure.
- Update the booking page message with the closure dates and the return date.
- Decide the cancellation policy for the period and say so, particularly if you take deposits.
- Open the following period. If your horizon is short, extend it so clients can book into the new season while they are thinking about it.
- Diary a check for the first working day back to confirm availability has returned to normal.
Reopening Cleanly
The first days back have their own shape: a backlog from the closure, an inbox of requests, and a slower start than a normal week. Two things help. Open the reopening period for booking before the break rather than after, so the queue forms in the system rather than in your inbox. And consider a reduced first day with more admin time, entered as a date override with shorter hours.
Managing This In appntmnts.io
appntmnts.io supports date specific overrides for closures, different hours and extra hours, applied per account, per person or per location, alongside the weekly working pattern. Connected calendars contribute busy time, so leave recorded in Google Calendar or Microsoft 365 blocks bookings provided the events are marked busy. A booking horizon limits how far ahead the page accepts bookings, which keeps unreviewed periods from filling up.
The features page covers the availability model, and pricing shows what the free plan includes. If you are setting exceptions for the first time, start with setting your availability rules so the base pattern is right before you add the exceptions on top.