Google Calendar says you are busy, but your WooCommerce booking page still offers the same time. Before you buy another scheduling plugin, check what your current connection actually controls. A visible calendar event is not proof that the store has reserved your time.
This guide covers the official WooCommerce Bookings extension and its Google Calendar integration, not every WordPress appointment plugin. It helps you separate a sync problem from a capacity rule, an unpaid reservation, or two genuinely conflicting bookings. The decision tables below are a troubleshooting framework, not a claim that Webless has tested your store.
First establish whether two customers really have the same slot
Start with one affected date, service and staff member or resource. Record the time zone shown to the customer, the appointment duration, and the booking references. Avoid changing settings while you are still establishing what happened.
WooCommerce maintains separate booking and order records. Review both, plus the payment provider’s result where relevant. A calendar screenshot cannot establish whether two orders were paid, whether one reservation awaits confirmation, or whether a customer simply abandoned checkout.
| What you can verify | What to investigate next |
|---|---|
| Two confirmed commitments exceed the capacity you can deliver. | Treat this as an operational conflict. Preserve both records and stop offering the affected capacity while a responsible person resolves the bookings. |
| One real booking appears in two calendar views. | Compare booking references before treating the mirrored display as another customer. |
| A personal appointment exists, but the store has no corresponding restriction. | Trace the calendar connection and the origin of that appointment. |
| A slot looks unavailable, but there is no completed sale. | Check reservation status and temporary holds before deleting data to reopen it. |
If a real customer has already paid, do not ask them to retry as a diagnostic step. Assign someone to reconcile the commitment and communicate the outcome. Keep private customer and payment information out of shared screenshots.
Why a busy Google Calendar can leave WooCommerce available
The official Google Calendar integration guide distinguishes one-way export from two-way sync. One-way sends store bookings outward; it does not import personal appointments. Two-way imports native events from the connected calendar into Store Availability, affecting all bookable products. Updates are polled and can take a few minutes.
There is another important limit: third-party iCal or subscribed calendar feeds displayed inside Google Calendar are not imported by this integration. Also, moving a store-created event in Google does not reschedule its original booking. Make that change in WooCommerce; edit Google-origin appointments in Google.
Before reconnecting anything, record the selected calendar, sync direction and event origin. Ask the person who manages appointments where this particular event was first created. “It is in my calendar” is not a sufficiently precise answer.
For multiple staff calendars, WooCommerce’s documented Zapier approach is an outward, one-way arrangement. Sending a copy to a staff member is not the same as importing that person’s availability. Write down which system is allowed to accept each appointment before adding another connection.
Check capacity before blaming calendar sync
Two bookings at 10:00 are not automatically wrong. A class with six places and a one-person consultation have different capacity requirements. Define what the business can actually deliver, including shared rooms, equipment and staff, before comparing the software setting.
WooCommerce’s availability settings include maximum bookings per block, buffers and rules at different levels. Resources can override the product’s booking limit. Lower numeric priorities take precedence over higher numbers, so read the complete rule set instead of assuming the last rule you added wins.
Make a small map on paper: service, required resource, available quantity, duration and preparation time. For example, two different services might both require the same treatment room. Testing each product independently would miss that shared constraint.
Do not fix an unexplained conflict by increasing capacity, removing buffers or disabling restrictions. That can make the warning disappear while allowing more appointments than the business can honour. If the intended capacity is unclear, settle the operational rule first.
A held slot is not necessarily a lost booking
The opposite symptom also matters: an apparently empty calendar with no bookable time. WooCommerce documents that in-cart bookings temporarily hold availability before checkout is complete. Automatic cleanup releases inactive reservations; a persistent hold may need investigation of the cleanup process.
Inspect the specific reservation rather than clearing every customer’s session. The store-wide session-clearing tool affects active carts too. On a live store, establish whether the shopper is still checking out before removing a hold. A busy period is a poor time for broad trial-and-error resets.
Keep these cases separate in your notes: time offered when it should be blocked, time blocked when it should be offered, and an order that exists without the expected payment result. Each needs different evidence and may have a different owner.
Prove the fix with a controlled booking rehearsal
Use an isolated staging environment with a dedicated test calendar, non-customer appointments and the payment gateway’s supported sandbox. Do not connect a cloned store to the live calendar or let test notifications reach customers. Back up the exact settings and record the current versions before making a change.
The following acceptance matrix is Webless’s recommended test design. It is not a record of completed tests on your website. Write the expected result first, then record what the store actually does.
| Controlled scenario | Evidence needed before approval |
|---|---|
| A native appointment on the dedicated connected calendar. | Compare the store’s restriction and customer-facing availability after synchronization; note the elapsed time rather than assuming instant delivery. |
| Two services competing for the same single-capacity resource. | Two independent customer sessions must not produce commitments beyond the intended shared capacity. |
| A reservation that reaches supported sandbox payment. | The booking time, order reference, gateway outcome and customer confirmation agree. |
| A reschedule and cancellation in the owning system. | The original slot and replacement slot follow the intended rules, with no duplicate commitment left behind. |
| A booking on mobile, followed by a fresh browser visit. | The visible time zone, chosen date and final confirmation remain understandable and consistent. |
Repeat the smallest failing scenario after one change. Save the before-and-after result and who approved it. If payment succeeded but reservation state is unclear, stop repeated payment attempts and reconcile the records. If a settings change produces unrelated availability changes, restore the recorded setting and investigate before releasing it.
A database rollback on a trading store is not a harmless undo button: newer bookings and orders need protection. Our WooCommerce checkout testing checklist covers the wider cart, payment, email and recovery checks that belong around a booking fix.
When you need configuration help or development
If a documented setting explains the behaviour and the controlled test passes, you may not need new software. Keep the evidence and add the scenario to your regular maintenance checks.
Escalate when the business needs several independent calendars, shared capacity across services, an external booking channel, or custom payment and confirmation rules. Explain the required behaviour before choosing a plugin or commissioning code. The useful question is not “can these calendars connect?” but “which system prevents the same capacity being sold twice?”
Webless’s WordPress development service is the relevant route for integration and custom-logic work. Ongoing maintenance helps retain the verified behaviour after updates; it is not a substitute for defining and implementing a missing booking rule.