WooCommerce Bookings

A bookable product is a product whose stock is a slot in a calendar. Everything unusual about bookings follows from that: two people cannot buy the same hour, availability changes by the minute, and the thing being sold expires whether or not anyone buys it.

WooCommerce handles the money, the customer record and the order history well. The calendar is what you are actually buying an extension for.

First: is a store the right shape at all?

If you already run a shop, keeping bookings in the same checkout is worth a great deal — one customer account, one order list, one tax setup, one set of emails. If you do not, a booking plugin is usually a better fit and a lighter dependency. The comparison of standalone tools is in booking plugins.

Model availability before configuring anything

Write these down first. Every booking setup that fails, fails because one of them was never decided:

• What is the unit? A fixed 60-minute appointment, a night, a whole day, an arbitrary range?
• What is being consumed? Your time, a room, a piece of equipment, a person? This becomes a resource, and a booking may consume more than one.
• How many can run at once? One customer per slot, or eight seats in a class?
• When are you open? Recurring weekly hours, plus exceptions for holidays and one-off closures.
• How much notice do you need? A minimum lead time stops someone booking a slot ten minutes from now.
• How far ahead can people book?
• What happens between bookings? A buffer for cleaning, travel or setup is what stops a calendar that is technically valid and physically impossible.

Buffers and lead times are the two settings most often left at their defaults and most often responsible for an unworkable schedule.

Slots must be held, not just sold

The defining question: when does a slot stop being available to everyone else?

• If it is held when added to the cart, an abandoned cart blocks the slot until it expires — so cart expiry has to be short and actually configured.
• If it is held only at checkout completion, two customers can be paying for the same hour simultaneously.

Neither is wrong; not knowing which you have is. Test it directly: add a slot to the cart in one browser, then try to book the same slot in a private window.

Then check caching, because a cached product page shows availability from whenever it was cached. Bookable product pages and the availability endpoints must be excluded from page caching — the exclusion rules are in choosing a cache plugin, and the symptom when they are wrong looks exactly like products not showing or a filter returning nothing.

Time zones

The site has a time zone. The customer may be in another. The staff member may be in a third.

• For in-person services, display everything in the venue's local time and say so on the page.
• For remote services, display slots in the customer's own zone and confirm the zone in the booking email.
• Check behaviour across a daylight-saving change, which is where recurring availability rules quietly shift by an hour.

Set the site's time zone to a named city rather than a UTC offset, so daylight saving is handled for you.

Money: deposits, cancellations, no-shows

• Deposits or full payment? Partial payment reduces no-shows and needs the extension to support it, plus a policy for collecting the balance.
• A cancellation window that is enforced by the system rather than by argument.
• Refund rules — full, partial, or credit — written on the product page, not just in your head.
• Rescheduling, which customers will want and which is a different operation from cancel-and-rebook.
• No-shows, and whether the slot is released.

Email is the product

A booking that does not produce a confirmation is a booking the customer does not believe in. You need: an immediate confirmation with the date, time and time zone; a reminder before the appointment; a notification to whoever is delivering it; and a message when anything changes.

Send through an authenticated service rather than PHP mail, and verify delivery before launch — WooCommerce emails not sending is the diagnostic path. A calendar attachment or an "add to calendar" link in the confirmation reduces no-shows more than a reminder does.

Calendar sync

If staff keep their own calendars, one-way export is not enough: a booking taken in WooCommerce must block the staff calendar, and a personal appointment must block WooCommerce. One-way sync produces double bookings that look like a system fault and are a configuration choice.

Check what happens when sync fails. Silent failure is the worst option and the most common default.

Common mistakes

• No buffer, producing back-to-back bookings in two different places.
• Cart holds with no expiry, so abandoned carts block the calendar all week.
• Cached availability, showing slots that were taken an hour ago.
• Time zones left implicit, producing customers who arrive at the wrong hour.
• One-way calendar sync, then double bookings.
• Testing only the happy path and never a cancellation or a reschedule.

Test before taking a real booking

On a staging copy, with the gateway in test mode:

1. Book a slot and confirm it disappears from availability immediately.
2. In a private window, attempt the same slot — it must be refused.
3. Complete payment and confirm the customer and staff emails both arrive.
4. Check the booking appears in the synced calendar, and that a calendar entry blocks the site.
5. Cancel inside the window, then outside it, and confirm the refund rules apply.
6. Reschedule a booking.
7. Book across a daylight-saving boundary and check the displayed time.
8. Abandon a cart with a slot in it and confirm the slot returns.

Step eight is the one nobody runs, and it is the one that quietly closes your calendar.