Two calendars, one slot: why syncing does not stop double bookings

Two people are booked for eleven o'clock. One booked through your website last Thursday, the other was written into your calendar by a colleague on the phone five minutes later. Both got a confirmation. Neither did anything wrong, and neither did your colleague.

Search for a fix and you will find the same sentence on every vendor's page: turn on real-time two-way sync. Acuity's guide is representative — it lists the causes as "availability isn't accurately reflected, calendars aren't synced, or manual scheduling leads to overlapping appointments" and advises you to "ensure your bookings are synced across all platforms whenever a new appointment is scheduled." Sound advice. It is also, on that page, offered without a single caveat about sync being late or incomplete.

That is the gap worth writing about. Sync is not a switch that makes the problem go away. It is a mechanism with documented limits, and knowing them tells you which of your slots are genuinely protected and which only look it.

Nobody promised you every update

Start with the layer everything else sits on. Google's own Calendar API documentation, written for the developers building the scheduling tools you use, says this about the push notifications that make sync feel instant:

"Notifications are not 100% reliable. Expect a small percentage of messages to get dropped under normal working conditions."

And it tells developers what to do about it: "Handle missing messages gracefully to ensure your application still syncs even if push notifications fail to arrive."

Read that as a business owner rather than a developer. Under normal working conditions — not during an outage, not on bad wifi — a share of the "this slot just got taken" messages simply never arrive. The well-built tools compensate by also checking on a schedule. That check runs at an interval, and an interval is a window, and in that window your booking page is showing something that was true a few minutes ago.

Most double bookings are not a broken integration. They are somebody landing on your booking page inside that window.

The setting that excludes a calendar from the check

Here is the failure that makes owners feel stupid, and should not.

The list of calendars a tool writes bookings into, and the list of calendars it examines when deciding whether you are free, are two different lists. Calendly's own documentation says so in one line: "Make sure your Calendar to add events to is also marked as a Calendar to check for conflicts."

That sentence exists because the two can come apart. Your tool can be faithfully depositing every new appointment into a calendar it never consults for conflicts. Everything looks connected. Bookings show up where they should. And the tool is blind to half of them.

Two ordinary events produce this state without anyone deciding to. Somebody adds a second calendar — a new staff member, a room, a personal calendar that started holding work appointments — and the conflict-checking list is not updated to match. Or the plan changes: Calendly notes that "depending on your plan, you can connect between one and six calendar accounts per user," so a downgrade can drop calendar connections. The bookings keep working. The checking quietly covers less than it did.

There is a third one, subtler still. Free/busy rules let you allow booking over certain categories of event — personal events, focus time, breaks. Each of those is a deliberate decision that was probably right when it was made, and each is a category of thing that will not defend a slot.

The calendar you subscribed to is not a source of truth

If any part of your availability depends on a calendar you added by pasting a link — a partner's schedule, a shared room, a contractor's availability published as an ICS feed — treat it as decoration rather than data.

Google's official help page for subscribing to someone else's calendar explains how to subscribe and says nothing whatsoever about how often the subscription refreshes or how quickly changes appear. Numbers circulate in blog posts. I could not find them in the documentation, so I am not going to repeat them here. What matters is the shape of it: the refresh cadence is not a promise anyone has made to you, and a feed that updates on nobody's published schedule cannot be the thing standing between two clients and the same hour.

If a calendar matters for availability, connect it properly through the integration rather than subscribing to its link.

The booking nobody typed into the system

Every account of this problem assumes both appointments went through software. In a small business one of them usually did not.

Someone rings during a treatment, a class, a viewing. The person who answers writes the time on paper, or into their own phone, or into the shared calendar if they remember which one is shared. It reaches the booking tool later, if at all. For the length of that delay the slot is genuinely taken and universally advertised as free, and no synchronisation setting in the world can help, because the information has not entered any system yet.

This is why the pattern is so often "phone booking versus online booking" rather than "calendar A versus calendar B". The fix is not technical either. It is deciding that a booking is not a booking until it is in the one place everything else checks, and making that place reachable from wherever your staff answer the phone. A note to be transcribed at the end of the day is a double booking with a delay on it.

Buffers make the collision less painful, not less likely

Buffer time appears in every list of advice, and it is worth having, but be clear about what it does. A fifteen-minute buffer means two appointments that would have overlapped now sit back to back — you are late rather than double-booked, which is a real improvement and a different problem from the one you came here with.

What a buffer cannot do is stop two people being given the same start time. Buffers shape the space around a booking; they do not decide whether the slot was free. If your collisions are exact-time collisions, buffers will not touch them, and the time spent tuning buffer lengths is time not spent on the conflict-checking list.

What to do when it has already happened

The technical part is the smaller half. Two people are expecting you, and one of them is about to be told they are not getting what they were promised.

Decide by cost, not by order. First-booked is a tidy rule that ignores which appointment is harder to move. A client who took a morning off work, arranged childcare or is flying in is not equivalent to a regular who books you every month and lives ten minutes away. Ask which of the two can be moved with the least damage, then ask them, rather than announcing it.

Reach out before they travel. The difference between an apology received at home and one received in your waiting room is most of the damage.

Offer something specific. Not "sorry, can we reschedule" but two concrete slots and, where it makes sense, something that acknowledges the inconvenience. The goal is that the client tells this story as "they called me and sorted it" rather than "they double booked me."

Write down which failure it was. Overlapping window, calendar not in the conflict list, or a subscribed feed. These have different fixes, and without the note you will fix the wrong one.

The check that finds it before a client does

Half an hour, once, and most of this is behind you.

Open the settings and read the conflict-checking list against the actual list of calendars where appointments live. Every calendar that can hold a real commitment — staff, rooms, equipment, the owner's personal calendar if work ever lands in it — has to be in both lists, not just one.

Then test it the way it actually breaks. Put a busy event directly into one connected calendar, do not touch the booking tool, and immediately try to book over it from a private browser window. If the slot offers itself, you have found either a missing calendar or a category the rules allow booking over. Repeat for each calendar, because they fail independently.

Finally, look at your riskiest hour rather than a random one. If Monday morning is when the phone bookings and the online bookings collide, test Monday morning.

Where a tighter fix is worth paying for

For a single practitioner with one calendar, the checks above are the whole job.

It changes when the same slot can be claimed from more than one direction at once — a website form, a phone call written in by hand, a marketplace listing, a partner who books on your behalf. At that point no amount of sync configuration removes the window; it only shortens it. What removes it is a single place that decides, one booking at a time, whether a slot is still free — and every channel asking that place before it says yes.

That is a build rather than a setting, and it is worth knowing which of the two your situation actually needs before paying for either. Sorting that out is one of the things a process audit is for: $299, three business days, and it ends with a straight answer about whether your problem is a checkbox or a system.

Sources

I read these pages in August 2026. Vendor documentation moves; check the vendor's own page before acting on it.

The reliability of the sync layer everything sits on: Google on Calendar API push notifications.

Booking calendars and conflict-checking calendars being separate lists: Calendly on free/busy rules and Calendly on managing multiple calendars.

How the fix is usually presented: Acuity on avoiding double bookings.

What is not documented about subscribed calendars: Google's help page for subscribing to someone else's calendar, which describes how to subscribe and does not state a refresh interval.