Photo by Pavel Danilyuk · CC Pexels License undefined

How to stop double‑booking when you add online booking

September 8, 2026 · 9 min read

Practical steps to stop double-booking with online scheduling: sync right, add buffers, handle staff/resources, bulletproof reminders, and fix DST gotchas.

Why am I getting double bookings after adding online booking?

You connected a booking widget, customers can pick a time, and now you’re seeing overlaps. That’s not your team being sloppy — it’s almost always configuration.

Typical failure modes we see:

• Your booking tool isn’t checking every calendar that can block time (staff personal calendars, room/vehicle/resource calendars). Tools read “free/busy” from connected calendars; if the right ones aren’t connected, the slot looks open. [Calendly’s help] explains the free/busy check and how to connect multiple calendars for conflict detection and choose which calendar gets the final booking written to: it hides busy times from the booking page and avoids double‑booking when configured properly. Calendly Help
• You gave the tool read‑only free/busy but not permission to write to the same calendar your staff actually look at, so your team’s primary calendar shows nothing while the system thinks the slot is held elsewhere. This “read one calendar, write to another” mismatch shows up in admin threads often. Example: a sysadmin discussion notes free/busy sharing and write permissions don’t always align, causing phantom availability. r/sysadmin
• You’re relying on manual ICS imports/exports instead of real‑time sync. ICS drops are stale by design; by the time the file imports, someone else may have booked that slot.
• Buffers aren’t set or are visible to customers instead of hidden, so clean‑up or travel time overlaps with the next booking. Vendor docs describe before/after buffers and “hidden” buffers that don’t lengthen what the client sees. Salonized Help
• Time‑zone rules are out of date or you’re using fixed UTC offsets instead of IANA zone IDs (like America/New_York). That breaks around daylight‑saving transitions and can shift events by an hour. IANA Time Zone Database and its theory notes why local clock strings and fixed offsets cause errors around DST. IANA tz theory

Under the hood, booking systems use calendar “free/busy” to decide what to show. The iCalendar spec defines a VFREEBUSY component for exchanging availability; if the right calendars aren’t included, the tool can’t see the conflict. RFC 5545 iCalendar

Set up calendar sync so the system actually sees your conflicts

Do this once per staff member and per resource (room, chair, vehicle, machine):

1. List every calendar that can block availability

• Personal/work calendar (Google/Microsoft/Apple) the person actually uses
• Any room/resource calendars your team reserves
• On‑call or shift calendars that change who’s bookable

2. Connect all of them to your booking tool for free/busy checks

• Most tools let you connect multiple calendars per user and will remove busy times when calculating availability. See configuration patterns in Calendly Help.

3. Pick the one calendar to write confirmed bookings into

• You must select the “destination” calendar that should hold the booked event and mark it busy. Choosing the wrong destination is a direct path to overlaps because your team looks at one calendar while the tool writes to another. Again, the connect-and-select model is documented in Calendly Help.

4. Permissions: grant read for all conflict calendars, write for the destination calendar

• If your stack supports resource calendars (rooms/vehicles), grant read so those blocks are respected. The common misstep is read access to Calendar A while all real events live in Calendar B or a separate resource calendar. The sysadmin thread above shows how free/busy sharing on one calendar doesn’t imply others are included. r/sysadmin

5. Test a real conflict

• Put a personal event on the staff calendar for 2:00–3:00. Open your booking page in a private window: that time should disappear. Then book a 3:00 test and confirm it lands on the correct destination calendar.

Underneath, this works because the booking tool asks connected calendars for free/busy windows using standard availability components (VFREEBUSY, CalDAV extensions). If a calendar isn’t connected, the system has no signal to block that time. RFC 5545 iCalendar

Choose the right buffer times without bloating your day

Buffers protect setup, clean‑up, payment, notes, and travel. Configure them at the service level so they’re applied every time.

• Before/after vs. service‑level buffers: Vendor docs describe both approaches and allow hiding buffers from clients so a “60‑minute massage” can still appear as 60 minutes while your bookable grid reserves extra time. Salonized Help
• Practical ranges by use‑case: Operator guides suggest example buffers, not standards — short services often use 5–15 minutes; higher‑touch services 15–30 minutes or more. Hair stations commonly need around 10–15 minutes for cleanup; simple consults 5–10; complex procedures 20–30. These are practice‑based suggestions. Book and Go
• There’s no single authoritative “best” number. Vendors present ranges and let you choose per service. Book and Go

How to pick:

• Time yourself on one real appointment, door‑to‑door: client greeting to ready‑for‑next. Include payment, notes, and cleanup. That becomes your default buffer.
• For mobile work, add realistic travel time for the coverage area you actually serve on busy days.
• If your schedule is tight, hide buffers so clients see clean slots while your calendar still protects your time. Salonized Help

Staff, rooms, and equipment: prevent overlaps across resources

Double‑booking often involves a shared constraint: not enough chairs, rooms, lasers, or vans. Fix it like this:

• Give each resource its own calendar and connect it for availability checks. If Room 1 is busy 2–3 PM, the booking tool must see that before offering a slot.
• For staff, connect each person’s real calendar and choose the correct destination calendar for their bookings. Don’t write everyone’s bookings into a single generic calendar unless your team also lives in that view. Calendly Help
• If services require both a staff member and a room/equipment, make sure the booking product can check both calendars before offering a time. If your current tool can’t do multi‑resource checks, you’ll need a different setup or a custom integration that reads free/busy from both and only offers intersections. The mechanism is the same free/busy check defined in iCalendar/CalDAV. RFC 5545 iCalendar

Confirmations and reminders that reduce no‑shows and conflicts

Reminders aren’t just about attendance — they also flush out conflicts before the day starts.

• Automatic confirmation message: Send right after booking with the exact time zone in the subject and body, and an “Add to Calendar” link. Ensure the event is created on the staff destination calendar too.
• Require client confirmation for sensitive slots: For high‑demand services, include a “Confirm or Reschedule” link. Unconfirmed appointments can be flagged for follow‑up.
• Reminder cadence: Send at least one reminder before the appointment and one on the day. Make both reschedulable via link so clients fix conflicts themselves instead of no‑showing.
• Policy notices: Include cut‑off windows for rescheduling/cancellations in the reminder template so clients don’t try to move last minute.
• ICS details: The calendar invite should carry the correct location, duration including hidden buffers (so your staff calendar reflects true busy time), and a clear callback number.

Time‑zone and daylight‑saving traps (and how to avoid them)

Scheduling errors spike around DST and for teams booking across time zones. The root cause: time rules change and many systems track them poorly.

• Use IANA time‑zone identifiers everywhere: America/New_York, Europe/London, etc. Avoid fixed UTC offsets or plain clock strings. The IANA tz theory explains how fixed offsets break when DST starts/ends, creating ambiguous or missing local times. IANA tz theory
• Keep tzdata current on servers and devices: The IANA Time Zone Database is updated to reflect government changes; stale tzdata means your app or phone may show the wrong local time. IANA Time Zone Database
• Expect frequent DST rule changes: An analysis of tzdb updates found 76% of updates include DST changes, which is why outdated rules bite so often. IRTF ANRW paper
• Beware the “missing” and “double” hours: During spring‑forward, a local clock time may not exist; during fall‑back, an hour repeats. If the client and server use different tz rules, the same local time can map to different UTC instants, causing overlaps or gaps. IANA tz theory

Practical steps:

• Store bookings in UTC internally; render in the user’s IANA zone at the edges.
• Stamp confirmation emails with both the local time and the time zone name, not just the abbreviation.
• Lock your booking page to the business’s time zone unless you truly need client‑side auto‑detection; when you do detect, display the detected zone explicitly and let the user switch.

Quick troubleshooting checklist (use this to stop double‑booking this week)

• Calendars connected: Every staff and resource calendar is connected for free/busy checks. Calendly Help
• Destination calendar: Confirmed bookings write into the same calendar your staff actually watch. Calendly Help
• Permissions: Read for all conflict calendars; write for the destination calendar. If you only see free/busy from one calendar but events live in another, fix sharing. r/sysadmin
• Real‑time sync: No manual ICS imports/exports; use native Google/Microsoft/CalDAV sync.
• Buffers: Service‑level buffers set (before/after as needed), hidden from clients if you want clean durations. Salonized Help Book and Go
• Multi‑resource: Services that require both a person and a room/equipment check both calendars before showing times. RFC 5545 iCalendar
• Reminders: Automatic confirmation + at least two reminders, both with reschedule links.
• Time zones: Use IANA zone IDs, update tzdata on servers/devices, show the time zone in messages. IANA Time Zone Database IANA tz theory
• DST week: For the week DST changes in your locale, sanity‑check next week’s calendar for shifted times. The high change rate in tzdb updates (76% include DST changes) justifies the extra check. IRTF ANRW paper

If you’d rather have a team wire this up, Fluxaro builds custom booking flows, lead capture, and workflow automations as part of hand‑coded websites and bespoke tools — no templates, and built around how you actually work. See what we build on our Services page. Services

How to sync with Google or your staff calendar (step‑by‑step)

This walk‑through mirrors how most booking tools work; use your vendor’s UI, but follow this logic:

• For each staffer, connect their Google/Microsoft/Apple account. Grant read on all calendars that can block time; grant write on the calendar they actually maintain. Calendly Help
• In the booking tool, choose “Calendars checked for conflicts” (include personal + resource calendars) and “Calendar to add new events to” (the destination). Calendly Help
• If you have shared rooms/gear, create calendars for them and connect those too. Bookings should only appear when both the staff and the resource are free. The intersection is standard free/busy logic per iCalendar. RFC 5545 iCalendar
• Create a test service with a visible 5‑minute duration difference from your normal, add a buffer, and run two test bookings back‑to‑back. Verify:
  • The first blocks the right calendars for the whole busy window (service + buffer)
  • The second can’t land in the buffer
  • Both invites arrive with the correct time zone string
• Switch one staffer’s device to a different time zone and create a booking to confirm the server stores in UTC and renders correctly per user. Keep tzdata up to date across devices. IANA Time Zone Database

If you hit a wall or need custom logic (multi‑location routing, travel windows, AI receptionist booking by phone or chat), this is exactly the kind of workflow we build into websites and internal tools. Here’s a look at live builds. Examples

Common timezone/DST mistakes you can prevent today

• Using fixed offsets like “UTC‑5” instead of America/New_York. Offsets don’t track DST. IANA tz theory
• Treating the display string “2:00 PM” as the source of truth. Store the UTC instant, display local time per user.
• Servers or phones running outdated tzdata after a government change. Update OS packages regularly; tzdb updates are routine. IANA Time Zone Database IRTF ANRW paper
• Forgetting that the “fall back” hour repeats. If you book across the repeat boundary, rely on the unique UTC instant instead of local clock time.

Take five minutes now: pick one staffer, connect the right calendars, set a hidden buffer on a popular service, and run the two‑booking test above. If you want help wiring it into your site and CRM, book a quick call. Book a call