Booking Systems: The Calendar Sync Is What Breaks

Almost every booking tool looks good in a demo. You pick a service, pick a slot, enter a name and a mobile number, and a confirmation appears. Nothing in that demo tells you whether the thing will still be correct in March, when one of your staff is on leave, a customer has rebooked twice, and somebody took a booking over the phone and wrote it straight into their own Google Calendar.

That is where these systems fail. Not at the booking form. At the calendar.

What a booking system is actually for

Strip away the feature list and a booking system does exactly three jobs:

It knows when you are free. Not when you said you were free in a settings screen six months ago — when you are actually free, today, including the dentist appointment one of your technicians added to their personal calendar this morning.
It stops two people taking the same slot. Including when one of them books online and the other rings up.
It reminds everyone. The customer, so they turn up; you, so you are ready.

Job two is the one that costs you money when it breaks, and job two depends entirely on job one. A booking system that cannot see your real availability is a form that emails you, with a monthly fee attached.

The two ways a calendar connects

When a vendor says "Google Calendar integration", they could mean one of two completely different things, and the price is often the same.

One-way: a feed your calendar subscribes to

The booking tool publishes a file — an ICS feed, which is just a plain text list of events in a standard format — and you add that URL to Google Calendar as a subscribed calendar. Bookings then appear in your calendar.

Two problems. First, information only travels one way: the tool pushes bookings out, and never looks at what is already in your calendar. Second, Google does not promise to refresh a subscribed external calendar promptly. In practice it polls on its own schedule, and that can be hours. A booking taken at 10am may not be visible on your phone until the afternoon. For a business where slots are taken days ahead that is survivable. For a clinic running same-day appointments it is not.

Two-way: a proper account connection

Here you sign in with your Google or Microsoft account and grant the tool permission. It can then do two things a feed cannot: query your free/busy information before offering a slot, and write the booking in as a real event it owns and can later update or delete.

	One-way ICS feed	Two-way account connection
Bookings show in your calendar	Yes, with a delay	Yes, immediately
Blocks slots when you add a personal event	No	Yes, if configured
Frees the slot when you delete the event	No	Usually — test it
Breaks silently	Rarely	Yes, and this is the problem

Two-way is what you want. Two-way is also what breaks.

Why two-way sync breaks, in order of likelihood

None of this is exotic. These are the ordinary failure modes, and a vendor who cannot answer questions about them has not thought about them.

The permission expires

When you connect your Google account, the tool receives a refresh token — a long-lived credential it uses to keep access without asking you to sign in again. These are not permanent. Google documents that refresh tokens for apps still in "Testing" publishing status expire after seven days, and that a token unused for six months stops working. Apps also lose access when you change your Google password in some configurations, or when an admin revokes permissions.

When the token dies, a well-built tool emails you loudly and keeps nagging. A badly built one logs an error nobody reads, keeps serving the last availability it knew about, and quietly double-books you for a fortnight.

The notification subscription lapses

To know instantly that you deleted an event, the tool subscribes to push notifications from Google's Calendar API. Those subscription channels have a fixed lifetime and must be renewed on a schedule. If the vendor's renewal job fails — server moved, cron stopped — notifications stop arriving. Everything still looks connected. Nothing is actually listening.

It is watching the wrong calendar

Your manager has a work calendar, a personal calendar, a shared "Shop Holidays" calendar and a birthdays calendar. The integration usually asks which calendar to write to and which calendars to check for conflicts. People configure the first and skip the second. Then a leave day sitting in the personal calendar does not block anything.

Half-hour time zones

India Standard Time is UTC+5:30. A startling amount of calendar code is written and tested in whole-hour offsets. The symptom is not random: appointments land exactly thirty minutes early or late, often only for all-day events or events created on mobile. If you test nothing else, test an all-day leave event.

All-day and recurring events

Ask directly: does an all-day event block the whole working day, or nothing? Does a recurring weekly event block every week, or only the first instance? Both behaviours exist in shipped products.

The phone booking

The most common real-world double booking in an Indian small business is not a software bug. Someone rings, your staff member opens WhatsApp or a diary instead of the booking tool, and the slot never reaches the system. Two-way sync fixes this only if staff enter phone bookings into a calendar the tool is watching. That is a training decision, not a software one.

The twenty-minute test before you pay

Do this during a trial, on a real staff calendar, not the vendor's sandbox.

Create an event in the staff member's personal Google Calendar for 3pm tomorrow. Refresh the public booking page. Is the 3pm slot gone? Note how many seconds it took.
Delete that event. Does 3pm come back? Within a minute, or at all?
Create an all-day event titled "Leave". Is the whole day blocked?
Make a real booking online. Check the calendar entry's start time to the minute. Check it contains the customer's phone number, not just a name.
Cancel that booking from the customer's confirmation link. Did the calendar event disappear?
Open two browser windows and try to book the same slot in both at almost the same time. One should fail.
Ask the vendor in writing: what happens, and who gets told, if the Google connection drops? If the answer is vague, assume nothing gets told.

Any tool that passes all seven is a serious product. Most of what gets sold to small businesses fails three and four.

Reminders, payments and no-shows

Reminders are where the actual return sits, because a no-show costs you a whole slot. Three honest points about them.

SMS through Indian operators requires registered sender IDs and pre-approved templates under the DLT (Distributed Ledger Technology) registration regime that telecom operators run. Your vendor either handles this or you will spend a fortnight on it. WhatsApp reminders through the official Business API also use pre-approved templates and are charged per conversation, so reminders are a running cost, not free. A reminder that goes out as a plain email to an address the customer never checks is not a reminder.

Taking a deposit at booking is the single most effective no-show control available to a small business, and it is a business decision more than a technical one. If you do it, be clear in writing about refunds. If your booking volume is low, a well-timed WhatsApp from a human the evening before beats any automation.

For reminders, follow-ups and the small chains of "if this, then that" around a booking, this is ordinary business automation work rather than a feature of the booking tool itself. And if bookings need to become customer records you can market to later, that belongs in a CRM system, with the booking tool feeding it.

What I would not buy

A booking engine built from scratch for a single-location business. An agency can bill happily for this. You will be paying to rediscover time zones, double-booking locks, cancellation flows and reminder delivery, all of which are solved problems. Custom is justified when your rules are genuinely unusual — equipment that must be shared across two appointments, pricing that changes by duration and staff seniority, multi-day hire with pickup windows. A salon with four chairs does not need it.

The booking plugin that came bundled free with your WordPress theme. These are bundled because they are a selling point, not because they are maintained. When the theme author stops updating, you are running a plugin that touches payments and personal data with no security updates. Check when it was last updated and by whom before you trust it with a single customer record.

Any tool with a one-way ICS feed sold as "calendar sync". Ask the direct question: if I put a private appointment in my own calendar, will your system stop offering that slot? If the answer is no, it is not sync.

Large prepaid SMS credit bundles bought before you know your volume. Buy a small pack, run a month, then size it.

A separate booking system per location when the rules are identical. You will end up maintaining four price lists.

One genuine uncertainty worth stating: there is no single right answer on whether to embed a third-party booking widget in your site or to build the booking flow into the site properly. The widget is faster, cheaper and someone else patches it; it also loads slower, often looks pasted-on, and the booking page usually lives on their domain rather than yours. For most small businesses the widget is the right trade. If bookings are the main thing your site does, building it in as part of your website is usually worth the extra cost.

What to do next

If you already have a booking system, run the seven-step test this week on a live staff calendar. Most owners discover at least one of steps two, three and five fails, and they discover it before a customer does. Then check who gets the alert when the Google connection drops — if the answer is nobody, add a recurring monthly reminder to check it manually until that is fixed.

If you are choosing one, shortlist two tools, trial both on the same real calendar, and let the test decide rather than the feature grid.

If you would rather someone else ran the comparison, wired the reminders and kept the connection monitored, tell us what your booking day actually looks like — how bookings arrive now, how many come by phone, and where it currently goes wrong. Ongoing checks of this sort sit under technical support.

Questions we get asked

Do I need a booking system if most of my customers ring up?

Possibly not yet. If nearly all bookings come by phone, the value is in one shared calendar your staff all use, not in an online booking page nobody visits. Add online booking when you have evidence customers are trying to book outside your opening hours — missed calls in the evening are a good signal.

Why does my booking page show slots that are already taken?

Usually one of three things: the tool is only reading one of several calendars, the account permission has expired without telling anyone, or the slot was filled by a phone booking that never got entered. Check the integration status screen first, then check which calendars it is set to look at for conflicts.

Is Google Calendar on its own enough?

For a solo practitioner with a handful of appointments a week, often yes — a shared calendar plus a WhatsApp reminder you send yourself works fine. You outgrow it when customers start wanting to book without talking to you, when you need deposits, or when more than two people need to see the same availability.

Should I take a deposit at booking?

It is the most reliable way to cut no-shows, but it also turns some casual enquiries away, so it depends on how costly an empty slot is to you. If a missed slot costs you an hour of staff time you cannot resell, take one. Publish your refund and reschedule rules in plain language on the booking page.

What happens to customer data in a booking tool under Indian privacy law?

The Digital Personal Data Protection Act, 2023 applies to personal data you collect, including names and mobile numbers in a booking form. Practically: collect only what you need for the appointment, say on the form what you will use it for, and know where your vendor stores the data and how you would delete a customer's record if asked.