Booking & Appointment Plugin for WooCommerce - WordPress Plugin

Booking & Appointment Plugin for WooCommerce Setup Guide for Real-World Bookings

Booking & Appointment Plugin for WooCommerce is not just for displaying a calendar on a product page. In this guide, we will break down how to turn a standard WooCommerce product into a managed booking for a service, rental, stay, class, consultation, or extended order with dates, times, resources, confirmation, and result verification.

This guide is written for store owners, WooCommerce administrators, and developers who need to implement booking without modifying the WordPress core, the theme, or the plugin itself. We will go from site preparation to a test order, then separately cover resources, booking types, the available bookings block, calendar sync, notifications, templates, and troubleshooting common issues.

The core idea is simple: the plugin is only truly useful when you model your business rules in advance. You need to define what counts as the product, what counts as time, what should be treated as a resource, where the price changes, when a slot becomes unavailable, and what status the customer should see after placing an order. If you map out that logic before publishing, Booking & Appointment Plugin for WooCommerce works as part of your store instead of acting like a separate booking form.

What Problem the Plugin Solves in a WooCommerce Store

In WooCommerce, a product is sold by default as a catalog item: the customer chooses a quantity, a variation, and sometimes extra options, then pays for the order. That is not enough for services and rentals because the same product may only be available on certain dates, at specific times, for a limited number of people, or only when a particular specialist, room, piece of equipment, vehicle, tour seat, or other resource is available.

Booking & Appointment Plugin for WooCommerce adds a booking layer on top of the standard product model. The customer still follows the familiar WooCommerce flow - product page, cart, checkout, email, and account area. But before adding the product to the cart, they choose a date, date range, time slot, duration, resource, or number of participants, if those parameters are enabled for that specific product.

This approach is especially useful for stores that already rely on WooCommerce for payments, taxes, coupons, email notifications, order statuses, and customer accounts. You do not build a separate booking system next to the store - you use the WooCommerce infrastructure you already have. The plugin adds availability rules, price calculation, and admin screens for managing bookings.

What Counts as a Bookable Product

In this guide, a bookable product is a standard WooCommerce product with booking logic enabled. It can be a one-day service, a guest house room, a bike rental, an event venue, an online consultation, a multi-session course, equipment rental, or an appointment with a specialist. The difference is not in the product name, but in which fields appear in the Booking Meta Box and which rules apply when the customer selects a date.

Tyche's official product page shows that the plugin supports several different models: single-day booking, multiple-night booking, fixed time slots, duration-based time, multiple dates, and multiple days with time. In practice, that means you should choose the time model first and only then add pricing, resources, restrictions, and field labels. If you choose the wrong booking type, the administrator ends up fighting symptoms: slots are blocked incorrectly, prices calculate unexpectedly, the customer sees extra dates, or cannot select the range they actually need.

Where the Plugin Fits into the Standard WooCommerce Flow

The product's strength is that booking moves through the store's familiar touchpoints. A calendar or date and time selection fields appear on the product page. In the cart and at checkout, the customer sees the selected booking details. In the order, the administrator gets the booking record, can view it in a list or calendar, send reminders, confirm or cancel the booking, and, with Google Calendar integration enabled, sync the event.

You need to test more than just the product page - test the entire flow through the order and email. In practice, most issues do not appear at the moment the plugin is enabled, but later: when switching a variation, selecting multiple people, changing the date in the cart, dealing with a resource conflict, translating a string with WPML, caching the product page, or using an incompatible theme.

Who This Plugin Is For and When Another Approach Is Better

Booking & Appointment Plugin for WooCommerce is a strong fit for businesses that sell time, availability, or rentals directly through WooCommerce. If you already have a catalog, payment methods, tax settings, coupons, customer accounts, and order tracking in place, it makes sense to add booking to your existing commerce flow. That matters most when the booking needs to be paid for as an order, stored in the customer's history, and handled through standard WooCommerce processes.

The plugin is also useful for projects where a simple calendar cannot describe the booking logic. For example, a venue may be rented by the hour but cost more on holidays; one specialist may handle several services but cannot be booked twice at the same time; equipment rental may allow different start and end dates; an online class may need participant limits; and a tour operator may want to accept requests with manual confirmation before payment.

Good-Fit Scenarios

• Salons, clinics, consultations, lessons, and service centers where the customer chooses a date and a fixed time slot.
• Hotels, guest houses, venue rentals, and travel services where nights, date ranges, and minimum and maximum duration matter.
• Car, bike, sports court, studio, and equipment rentals where you need to block either the full range or only selected slots.
• Stores with multiple staff members, rooms, or equipment units where the resource must be shared across different products.
• WooCommerce marketplaces where vendors using Dokan, WC Vendors, or WCFM manage their own bookings, resources, and holidays.
• Projects connected to an external operations system that needs REST API or webhooks to exchange booking, product, and resource data.

When to Be More Careful

The plugin may be overkill if you only need a simple inquiry form without payment and without tracking open slots. In that case, a standard contact form with notifications may be faster to launch and easier to maintain. It also does not replace a full hospitality management system if you need a complex room grid, housekeeping, check-ins, channel managers, and integrations with a large number of external booking platforms. For those projects, WooCommerce can still serve as the storefront, but the operational system is usually better handled separately.

Another factor is setup complexity. The plugin has many capabilities, and that is only an advantage when the administrator understands the structure: global settings, product settings, and tabs for availability, resources, pricing, reminders, integrations, display, and customer-facing labels. If you need a manager with no training to create ten service types in one evening, you should first build product templates and an internal process, otherwise flexibility turns into chaos.

Practical takeaway: choose this product when booking needs to live inside the WooCommerce order and reflect actual availability. If all you need is a simple "call me back" request, this tool is more powerful than necessary.

What to Check Before Installation and Initial Setup

You do not need a complex infrastructure before installation, but you do need to get the basics in order. Booking & Appointment Plugin for WooCommerce sits at the intersection of WordPress, WooCommerce, the theme, payment methods, emails, translations, and sometimes calendars. That preparation lowers the risk of chasing a plugin bug when the real issue is cache, a theme conflict, or the wrong product model.

Platform and Environment

Make sure WooCommerce is installed, activated, and set up at a basic level: currency, taxes, cart and checkout pages, emails, order statuses, and payment methods. Tyche publishes current compatibility on the product page, so compare those requirements with your WordPress, WooCommerce, and PHP setup before you roll it out. You do not need to list versions in the public guide on the site, but for the administrator this is a required checkpoint before an update or launch.

Also check your permalink structure if you plan to use the REST API or external integrations. In the documentation for both the legacy and updated Tyche API, they specify requirements for WooCommerce keys, permissions, and pretty permalinks. Even if you do not need the API yet, it helps to understand upfront that external integration depends on correct WooCommerce configuration, not just an active booking plugin.

Backup and Test Environment

Any plugin that changes product and order behavior should be tested on a copy of the site, or at least during off-peak hours. Create a full backup of the files and database, then build one test product with a minimal rule set. Do not start by migrating your entire catalog and dozens of exceptions. First verify one clean flow: the date can be selected, the price recalculates, the product goes into the cart, the order is created, the booking appears in the admin panel, and the emails include booking details.

If your store already uses page cache, JavaScript optimization, checkout blocks, WPML, product add-ons, bundles, subscriptions, multi-vendor plugins, or a custom theme, make a separate checklist for them. Tyche's changelog shows that many fixes throughout the product's history were tied to the storefront calendar, slot availability, checkout blocks, themes, variations, resources, and integrations. That is not a reason to avoid the plugin, but it is a reason to test the scenarios your site actually uses.

A Business Rules Map Before Clicking Through the Admin

Before turning on settings, answer a few questions in writing. What exactly is being booked: a service, a room, a person, a unit of equipment, a seat in a group, or a time range? How many customers can choose the same slot? Are same-day bookings allowed? Is there a buffer between orders? Does the administrator need to confirm before payment? What happens on cancellation? Does the price depend on the day of the week, duration, resource, number of people, or a specific date?

If you cannot explain a business rule in a single sentence, you cannot safely configure it by guesswork. For example, "venue rental" might mean a full-day rental, hourly rental, several fixed blocks, or a request that requires confirmation. Each version calls for a different booking type and a different result check.

Installation, Activation, and First Launch

Installation works like any standard premium WordPress plugin: the administrator uploads the ZIP archive through Plugins > Add New > Upload Plugin, installs it, and activates it. Tyche's documentation separately notes that WordPress and WooCommerce should already be installed before you upload the product archive. Do not move files manually into a live site when you can use the standard WordPress installer and normal administrator access.

After activation, the Booking & Appointment screens and the initial setup wizard appear. The Setup Wizard helps you walk through core options: date and time format, calendar theme, booking type, available days, whether cancellation or rescheduling is allowed, field labels, and diagnostic data sharing. You can skip the wizard if you want to review the settings manually first. For a more complex store, that is often the better choice: the wizard is helpful for orientation, but the final rules should still be checked against the specific product.

What to Configure Right After Activation

Start with the global settings and the calendar appearance. Check the language, date format, time format, first day of the week, number of months shown in the calendar, and the calendar theme. These options affect more than just appearance - they shape how the customer interprets the form. For example, the time format should match what your audience expects, and the first day of the week should not conflict with local conventions.

Next, review your WooCommerce email settings. The plugin has its own email templates for different events: new booking record, confirmation, cancellation, reminder, waiting for confirmation, Google Calendar import, and others. Even if you do not edit the templates, place a test order and make sure the email includes the date, time, resource, customer name, and order link.

The third checkpoint is the customer view. Open the product in a regular browser window where you are not logged in as an administrator, and check how the booking fields appear. The admin panel may show correct settings, but the visitor only sees the real result after the theme, WooCommerce variations, calendar scripts, and availability rules all work together.

Your First Test Product

For the first test, it is best to create a separate product such as "Test Consultation" or "Test Rental," keep it out of the main menu, and assign it a simple price. In the Booking Meta Box, enable booking, choose one clear booking type, add a few available days or time slots, save, and check the product page. Then add the product to the cart and complete the checkout flow using a test payment method.

Do not test every mode at once. If the first product is configured as a fixed time appointment, first make sure the selected date shows the correct slots, that a booked slot disappears or becomes blocked after the order, and that the booking details are saved in the order item meta. Only then move on to resources, people, pricing ranges, and calendar synchronization.

Settings Map After Installation: What Lives Where and What It Changes

An important characteristic of Booking & Appointment Plugin for WooCommerce is that some rules live globally while others live at the product level. Global settings define the overall calendar language, field behavior, bulk settings, integrations, appearance, some permissions, and general restrictions. Product settings define how that specific product is booked: by day, night, slot, duration, multiple dates, resources, people, pricing, availability, and confirmation.

Global Settings

The global level should be reviewed like a checklist. In WooCommerce > Booking & Appointment and related sections, review the calendar appearance, date and time formats, field labels, global holidays or blackout days, cancellation behavior, message settings, calendar integrations, reminders, and bulk booking settings. If you use a multi-vendor setup, review vendor options separately: that is where you can hide certain settings from vendors, such as the ability to enable Requires Confirmation or allow customer cancellations.

Global settings are best for consistent store-wide rules: calendar language, first day of the week, the default display of booking details, shared field labels, and restrictions that should not vary from one product to another. But do not turn the global level into a dumping ground for every exception. If only one product has custom holidays, special pricing, or unique availability, configure that at the product level.

Booking Meta Box on the Product

The real work happens on the product edit screen. Once booking is enabled, the Booking Meta Box becomes the control center: booking type, availability, resources, persons, block pricing, confirmation, cancellation, integrations, and in some cases template-based settings. The exact set of tabs depends on the booking type you choose and any related extensions that are active.

A practical order is this: first choose the booking type, then configure basic availability, then add capacity or max bookings, then resources and people/persons, then pricing, then appearance and labels. If you do it in reverse, you may configure pricing for a mode that you later change, or add a resource before deciding how the slot should actually be blocked.

Bulk Booking Settings and Product Availability

Bulk settings and Product Availability are useful when many products follow a similar schedule. For example, a school may run ten courses on the same calendar, or a rental business may have several equipment units available within one season. Tyche's documentation shows scenarios where availability can be controlled by dates, months, weeks, days, and time ranges. That is far more efficient than manually repeating the same rules on every product.

At the same time, bulk settings require discipline. Before applying them to a group of products, document which products are affected, which fields change, and how you will verify a rollback. If dates disappear from the storefront after a bulk change, do not blame the cache first - check the availability logic itself: range type, priority, bookable or non-bookable state, max booking, and overlap with product-level rules.

Which Options to Enable Only When You Need Them

Do not enable resources, people, confirmation, calendar sync, reminders, REST API, or template overrides just in case. Every additional mechanism creates more dependencies. A resource can restrict availability across several products at once. Persons can affect both pricing and capacity. Requires Confirmation changes checkout and payment behavior. Calendar sync depends on OAuth, redirect URI, the selected calendar, and external events. Template overrides need to be maintained after updates.

A safe baseline configuration for the first launch is one product, one booking type, clear availability, a small number of slots, a test order, an email check, and a booking record in the admin calendar. Add everything else in layers, and verify each layer with a separate order.

Booking Types: How to Choose the Right Mode Without Rebuilding the Product

Choosing the booking type is the decision that shapes everything that follows. Tyche's documentation gives booking types their own section, and for good reason: you cannot configure a one-hour consultation, a multi-night stay, a car rental with separate start and end times, and a course made up of several separate sessions in the same way.

Single Day: When the Date Matters but the Time Does Not

Single Day is a good fit for services or events where the customer chooses a date, but time is not part of the booking decision. Examples include a daytime venue rental, registration for a one-day event, or a service booked for a specific day without individual time slots. In this mode, enabled weekdays, specific dates, holidays, and max bookings per date are especially important.

Result check: on the product page, the customer should see the available dates, and once the limit is reached the date should become unavailable or display the correct message. If the date remains active after the limit is reached, check max bookings, product quantity in the order, order status, and any rules that may be applied on top of standard availability.

Multiple Nights: Stays, Rentals, and Extended Orders

Multiple Nights is the right fit when the booking revolves around a range from a start date to an end date. This covers hotels, guest houses, bundled rentals, and rentals priced by nights or days. The documentation separately covers minimum and maximum number of nights, as well as price by range for multiple nights. This mode works especially well when pricing depends on duration. For example, a short rental may cost more per day, while a longer rental receives a discount.

The main trap is treating multiple nights like a set of separate days. For the customer, this is one continuous period. So do not test only the first and last date - test the full range. If there is a disabled day or holiday in the middle, decide in advance what should happen: should the whole range be rejected, should the price include only the available days, or does your business allow an exception? Tyche's changelog has included fixes around disabled days and pricing calculations, so those scenarios deserve extra attention.

Fixed Time and Duration Based Time

Fixed Time is best for predefined slots: a consultation from 10:00 to 11:00, a doctor's appointment, an instructor-led lesson, or a workshop. The administrator creates a set of time intervals, and the customer selects one of them. Duration Based Time is better when the customer chooses a start time and a duration within a working range: renting a studio for two hours, a hall for several hours, or equipment for a flexible period.

Both modes depend on careful time availability setup. The Manage Time Availability documentation shows that rules can be defined by date range, months, weeks, days, and time ranges, and can also be assigned a priority. That is not just cosmetic - when rules overlap, priority determines what is actually bookable. If you have a rule such as "every weekday from 9:00 to 18:00" and another rule that says "Friday 12:00 to 16:00 is unavailable," make sure the Friday restriction truly overrides the broader range.

Multiple Dates and Multiple Days & Time

Multiple Dates is used when the customer selects several separate dates under one order. That could be a course, a package of consultations, a series of visits, a service with several scheduled dates, or a training program. Multiple Days & Time, which was introduced as a separate type in the current product line, covers a more complex scenario: the customer selects a start date, start time, end date, and end time, and the administrator decides whether to block the entire range or only the selected time slots.

The difference matters for rentals and transportation. If a vehicle is booked from morning to evening, you often need to block the full period so no one else can take an overlapping range. If you are dealing with ferry rides or recurring hourly trips, it makes more sense to block only the selected slots and leave the rest available. The wrong blocking type leads directly to overbooking or lost sales.

How to Choose a Booking Type for Your First Product

Scenario	Best-Fit Mode	What to Check
A one-day event with no time selection.	Single Day.	Available dates, holidays, max bookings per date.
A guest house or rental spanning several nights.	Multiple Nights.	Minimum and maximum nights, price ranges, unavailable dates within the period.
Appointments at predefined times.	Fixed Time.	Slot list, max bookings per slot, whether booked slots disappear.
Hourly rental with flexible duration.	Duration Based Time.	Working range, duration, gap, time availability rules.
A course made up of multiple separate sessions.	Multiple Dates or Multiple Dates with Fixed Time.	Number of dates, shared time, correct storage of all selected dates in the order.
A rental with date and time for both start and end.	Multiple Days & Time.	Blocking type, time slots, pricing, overlapping ranges.

Resources, People, and Protection Against Double Booking

One of the most product-specific features in Booking & Appointment Plugin for WooCommerce is Resources. A resource can be a staff member, hall, car, bike, piece of equipment, instructor, room, specialist, or any other asset shared across multiple services that should not be booked twice at the same time. Tyche's documentation makes it clear that resource availability is global across the bookable products to which that resource is assigned.

How a Resource Works

The resource is first created globally, with its own name, available quantity, menu order, and availability. It is then assigned to a specific product through the Resources tab in the Booking Meta Box. Depending on the settings, the customer may choose the resource manually, or the plugin may assign an available resource automatically. If the resource is already booked through one product, it should be unavailable for another product during overlapping time.

Example: a salon sells "Haircut," "Coloring," and "Styling." One stylist can perform all three services, but only one of them in the same hour. If that stylist is created as a global resource and assigned to all three services, the stylist's occupancy becomes shared. Without resources, each product would behave independently, and a customer could book the same stylist for two services at the same time.

Resource Quantity and Real Capacity Limits

Available quantity on a resource means how many units of that resource can be used at the same time. For one stylist, that is usually 1. For identical bikes, it might be 5. For a hall rented as a whole, it is also 1. Do not simply copy your WooCommerce stock quantity into this field without thinking it through. The resource controls availability in the context of time, while product quantity covers standard inventory logic.

If the service also uses persons or group booking, decide how people affect capacity. The official product page notes that person types can have minimums, maximums, their own pricing, and an option to count each person as a separate booking record. That is useful for tours, classes, group sessions, and seat-based rentals, but it needs testing: one order for three people should reduce availability in the way your business expects, not just create a single record.

Position of the Resource Field in the Form

Tyche's changelog notes a setting for the position of the resource field in the booking form: the resource can appear before or after the date and time selection. The practical meaning is straightforward: if the resource depends on the selected date and time, it makes sense to let the customer choose the slot first and then show only the available staff members or assets. If the resource is the main decision point - for example, the customer wants a specific stylist - you can show the resource first, but then you need to explain clearly why some dates are unavailable.

How to Test Protection Against Double Booking

1. Create two products that share the same resource.
2. Configure overlapping slots or dates for both products.
3. Place a test order for the first product with that resource selected.
4. Open the second product in a clean browser and check the same slot.
5. Make sure the slot is unavailable, marked as booked, or behaves according to your selected setting.

If the slot is still available, check that the resource is actually assigned to both products, that the order has a status the plugin counts toward availability, that unlimited bookings is not enabled, and that there is no conflicting time availability rule. Then clear the product page cache and repeat the test while logged out.

Pricing, Limits, and Availability Rules Without the Confusion

Pricing in bookings is more complex than a standard product price. The customer may pay by day, night, hour, slot, number of people, resource, duration range, season, specific date, or a combination of several factors. Tyche documents price by range for multiple nights, special prices for weekdays and dates, fixed blocks, extra charges per resource, and pricing changes in the changelog.

Base Price and Booking Price

For your first product, set a standard WooCommerce price and check how the plugin displays the booking price after the customer selects a date. Tyche notes on the product page that the plugin can display the price based on the selected booking details. The update history also includes fixes for cases where the price displayed as 0, recalculated incorrectly when the start or end date changed, or handled persons and multiple nights incorrectly. That makes price testing a required part of launch, not a cosmetic check.

A proper price check is always done in three places: on the product page after selecting dates, in the cart after adding the product, and in the order details after checkout. If the totals do not match, look for a rule that applies at one stage but not at another: variation price, product add-on, persons, resource charge, coupon, tax, special date price, price by range, or disabled-day blocking.

Special Prices and Price by Range

Special prices are useful for holidays, weekends, seasonal demand, peak dates, and individual weekdays. Price by range is more appropriate for longer bookings where the price changes based on the number of nights or days. For example, a one- or two-day rental may cost more per day than a week-long rental. The official documentation specifically notes that Price By Range Of Nights applies to multiple night bookings, so do not try to use that mechanism in a mode it was not designed for.

A practical pricing workflow is to first get availability working correctly without any special pricing, then add one price range and place a test order, then add a second range or a special date. If you introduce several overlapping pricing rules at once, it becomes much harder to understand why the final amount changed.

Advance Booking Period, Minimum, and Maximum

Minimum lead time before booking protects the business from last-minute orders. The maximum booking window prevents customers from selecting dates too far in advance when the schedule is still unknown. In Multiple Nights, you also use minimum and maximum number of nights. These restrictions should be explained in the product text so the customer does not interpret an unavailable date as a site error.

If a date is inactive, do not start with the assumption that "the calendar is broken." First check the advance booking period, holidays, disabled weekdays, max booking, time availability, resource availability, and the selected booking type. Many symptoms look the same on the storefront, but the underlying cause is different.

Overlapping Time Slot Booking and Blocking Type

Overlapping Time Slot Booking and blocking type are especially important for duration-based modes and multiple days with time. If you block the entire range, overlapping orders become impossible. If you block only the selected slots, you can accept multiple customers in different parts of the same day. The changelog shows that Tyche has fixed cases where a partially overlapping slot blocked the entire day or where availability was reduced incorrectly. That means overlap testing should be repeated after updates.

A simple test is to create several short slots, book one in the middle of the day, then try booking a slot before it, after it, and one that overlaps it. Define the expected behavior in advance. If the plugin allows overlap where it would be risky, review the blocking type, resource, max bookings per slot, and order status.

Available Bookings Block and Shortcode for a Schedule Page

One scenario that is often underestimated is displaying available bookings not only on the product page, but also on a dedicated schedule page. Available Bookings Block lets you show bookable products in either List or Calendar view, filter them by all products, booking type, specific products, categories, or resources, and control duration, the quantity selector, times, navigation, and whether booked dates are greyed out.

When the Block Is More Useful Than a Standard Product Page

The product page works well when the customer already knows which service they want to book. A page with Available Bookings Block is more useful when the customer starts with the question, "What is available on the day I need?" For example, a salon may offer many services and staff members, a studio may have several rooms, a tour business may run several tours, or a rental company may offer different equipment categories. It is easier for the customer to see availability in one place than to open each product separately.

Filter choice matters especially on a schedule page. All Products can work well on a small site, but it overwhelms the customer on a large catalog. Specific Categories is well suited to sections such as "Venues," "Rentals," or "Consultations." Resource Based is useful when the customer chooses a staff member, room, or piece of equipment. Booking Type helps separate day-based, night-based, and time-based offers.

Setting Up the Block in the Editor

In the block editor, create a page, add the Available Bookings Block, and configure it through the right-hand panel. Under Display Settings, choose List or Calendar, then choose the duration: day, week, or month. If the service depends on time slots, use Show Times intentionally: a large number of slots can make the list long, but the customer will see the exact times. If quantity matters, leave Show Quantity enabled; if the service is always booked as a single unit, you can hide the quantity field and let it default to 1.

The Grey Out Booked Date option helps you avoid hiding fully booked dates altogether. Instead, they can appear as sold out or visually unavailable. That is helpful for transparency: the customer sees that the date exists, but it is taken. If you prefer not to show booked products at all, the option can be turned off.

Shortcode for Classic Editor and Technical Pages

For Classic Editor and pages where a shortcode is more convenient, Tyche documents the [tyche-bookings] shortcode with attributes. It can be used for a list, calendar, category filter, product filter, or resource filter. For example, to display a weekly calendar of all available products, use this form:

[tyche-bookings view='calendar' duration='week']

For a category, you can specify the category ID:

[tyche-bookings filter='categories' categories='27']

For a specific resource, you can show that resource's day-level availability:

[tyche-bookings filter='resources' resources='507' duration='day']

Do not copy these examples without replacing the IDs. First find the real product ID, category ID, or resource ID on your own site, then check the page on the public-facing site. A shortcode is only considered configured after you verify the result in the browser, not just after saving the page.

Practical Example: A Consultation with a Specialist and a Shared Resource

Let us walk through a scenario that shows the plugin's mechanics clearly: a salon sells an "Individual Stylist Consultation," the customer chooses a date and a fixed slot, the resource is a specific specialist, the price is slightly higher on weekends, and the administrator wants to verify that a second product using the same specialist cannot accept a booking for an occupied time.

Goal

Create one bookable product that can only be added to the cart after the customer selects a date, time, and available specialist. After a test order is placed, the slot should become occupied, the booking record should appear in the admin panel, and the customer email should include the date, time, and service name. If the same specialist is assigned to another product, the occupied slot should be unavailable there as well.

Preparation

• WooCommerce is configured, a test payment method is available, and the cart and checkout pages are working.
• The plugin is installed and activated through the standard WordPress uploader.
• The global settings for calendar language, date format, time format, and first day of the week have been checked.
• A resource named "Stylist Anna" has been created with available quantity set to 1 and with baseline availability.
• A second test product is prepared so the same resource can be assigned to it when testing the shared constraint.

Product Setup Steps

1. Open Products > Add New and create a service product with a standard WooCommerce price.
2. In the Booking Meta Box, enable the booking option and choose the Date & Time mode with fixed time slots if the service follows a predefined schedule.
3. In the Availability tab, enable working days and add time slots, for example four appointments per day.
4. Set max bookings per slot to 1 if the specialist only sees one client per slot.
5. In the Resources tab, enable the Resource Module and assign "Stylist Anna." If the customer should choose the specialist, leave it as a manual choice; if there is only one specialist, assignment can be automatic.
6. Add a special price for weekends or a specific date if the price genuinely needs to differ.
7. Save the product, open it on the storefront, and select an available slot.
8. Add the product to the cart, go through checkout, and complete the test order.

Result Check

After checkout, open the bookings list or the calendar view in the admin panel. The record should include the order ID, product name, customer name, start date, and end date or time if a time-based mode is used. Then open the same product page in a clean browser and verify that the slot can no longer be selected. After that, open the second product that uses the same resource and check the same slot there.

The customer email should include the booking details. If Google Calendar integration is enabled and OAuth is configured, also verify that the event is exported to the selected calendar. If synchronization is not enabled, do not treat that as a plugin error: first configure the integration mode, redirect URI, Client ID, Client Secret, and selected calendar.

Important Detail: Confirmation Before Payment

If the salon needs to manually approve the booking before payment, enable Requires Confirmation in the product settings. In that case, instead of making a regular payment at checkout, the customer submits a request, the order moves into a waiting state, the administrator confirms or cancels the booking, and the customer receives the corresponding email. This mode is useful for premium services, limited-capacity events, rentals that require pre-screening, and any case where you should not collect payment automatically before a manual review.

Check more than just the checkout button - also verify the next state in My Account > Bookings. The customer should understand that the request has been received and is awaiting a decision. If automatic cancellation of unconfirmed bookings is enabled after a set number of hours, make sure that behavior is described in the service terms, otherwise users will interpret the cancellation as a technical failure.

How to Verify the Setup Before Going Live

Once the first product is ready, do not publish it to all customers immediately. First walk through a control scenario both as a real buyer and as an administrator. The plugin touches several store layers, so the verification should run all the way from date selection to the admin record and the customer response.

Public-Facing Checklist

• The calendar or date selection fields display correctly and do not overlap theme elements.
• Unavailable days, holidays, and booked slots look unavailable rather than simply blank.
• The price changes after selecting the date, resource, duration, or persons if those rules are enabled.
• The Add to Cart button does not allow checkout without the required booking details.
• The cart and checkout show the selected date, time, resource, people/persons, and final amount.
• After changing quantity or variation, the price and availability still match the product page.
• The Order Received page shows clear booking details and the next status.

Admin Panel Checklist

• The new record appears in View Bookings and in the calendar view.
• The booking is linked to the correct WooCommerce order and the correct product.
• The booking status matches the selected mode: confirmed, paid, pending-confirmation, or cancelled.
• When the order is cancelled, availability is released in the way your business rule expects.
• CSV export or printed bookings include the fields your managers need, if they rely on exports.
• Reminders and emails are sent only for future bookings and are not duplicated.
• Google Calendar or webhook, if enabled, shows the event and delivery log.

Checks After a Plugin Update

After updating the plugin, run a short regression test: product page, booked slot, cart, checkout, email, booking calendar, and resource conflict. The product changelog shows that updates often fix specific edge cases around availability, resources, persons, checkout blocks, themes, and plugin conflicts. That is normal for a complex WooCommerce plugin. What matters is not guessing, but maintaining your own list of store-critical scenarios.

Do not skip the test order. The setup is only complete once you have seen the booking in the admin panel and rechecked the occupied slot on the storefront.

Integrations: Calendars, Notifications, Marketplaces, and External Systems

Integrations should be added only after the base booking model is working. Otherwise, it becomes hard to tell whether the issue is in the product, availability, calendar, OAuth, email, cron, vendor permissions, or webhook delivery. Booking & Appointment Plugin for WooCommerce supports several major integration directions, and each one solves a different problem.

Google Calendar Sync

The official documentation describes OAuth integration with Google Calendar: you need to create a project in Google Developers Console, enable the Calendar API, configure the OAuth consent screen, create an OAuth client ID, specify the authorized redirect URI, and save the Client ID and Client Secret in the plugin settings. The redirect URI differs between the global level and the product-level setup, so copy the exact URI shown by your site.

After the connection is successful, a connect to Google Calendar button appears, and then you choose which calendar will receive the bookings. In the settings, you can customize Event Location, Event Summary, and Event Description using placeholders such as SITE_NAME, CLIENT, PRODUCT_NAME, RESOURCE, PERSONS, ORDER_NUMBER, EMAIL, and ZOOM_MEETING. That is helpful for managers because the calendar event should be self-contained, not just a generic "Booking."

Customer add-to-calendar buttons are also available on the Order Received page, in customer notification emails, and in My Account if those settings are enabled. By default, those buttons may be turned off, so verify them explicitly. For importing external events, the plugin uses an iCalendar/.ics Feed URL, a cron interval, and then mapping imported bookings to products.

Reminder Emails and SMS

Reminder workflows cover the post-sale part of the process. In the WooCommerce email settings, you can enable Booking Reminder and configure the subject, email heading, and email type. Then under WooCommerce > Booking & Appointment > Reminders, you can create automatic reminders or manual reminders. Tyche's documentation describes reminders before and after the booking date, active or inactive status, drafts, and manual sending by Order ID, Booking ID, or Product.

Do not start with several automatic reminders. For the first launch, one email before the event is enough. Then verify that it is sent only for future bookings, includes the correct date, time, and product name, is not sent again after a status change, and does not conflict with your WooCommerce email template.

Marketplace Plugins: Dokan, WCFM, and WC Vendors

For multi-vendor stores, what matters is not just the ability to create a booking product, but vendor permissions as well. Tyche's documentation includes separate material for Dokan, WCFM, and WC Vendors: creating bookable products, viewing booking details, calendar view, holidays, resources, manual bookings, and reminders. At the admin level, you can hide certain vendor options so sellers do not enable features you do not want delegated to them.

The practical risk in a multi-vendor setup is blurred responsibility. The administrator is responsible for global settings, updates, integrations, payments, and permissions. The vendor is responsible for their own product, availability, holidays, resources, and handling requests. If the vendor is given overly broad settings, one incorrect rule can affect the calendar and support load. That is why it is best to test the role with one vendor first.

REST API and Webhooks

The REST API is useful when bookings need to be read or updated by external systems: a CRM, an internal dashboard, a mobile app, an operator panel, analytics, or an integration layer. Tyche provides both older API documentation and an updated version under the wc/v3 namespace. They list endpoints for bookings, resources, and products, along with GET, POST, PUT, and DELETE methods, plus filters for product_id, customer_id, resource_id, order_id, quantity, price, start_date, end_date, status, and fields.

Webhooks solve a different problem: they do not wait for an external request, but instead send an event when a booking product, resource, or booking is created, updated, or deleted. They are configured through WooCommerce > Settings > Advanced > Webhooks. For troubleshooting, the documentation recommends checking the delivery endpoint, a RequestBin-style receiver, and WooCommerce logs. Always test any webhook on a test endpoint first, not on a live CRM.

Bookable Product Templates: A Faster Start Without Losing Control

Tyche's documentation includes a dedicated section for Bookable Product Templates. This is an important feature for stores where the administrator needs to create a standard bookable product quickly and avoid breaking the base structure. A template is not a restriction and does not block further customization. It creates a new product in draft status with logic already applied for a specific scenario, and then the administrator adjusts availability, pricing, resources, persons, and restrictions for the real use case.

This approach becomes especially useful after the first manual setup. Once you understand how the calendar behaves, you can use templates as starter drafts for similar products. That reduces the chance that one manager chooses fixed time slots, another chooses duration-based time, a third forgets max bookings, and a fourth publishes the product without testing. Even then, templates do not replace a final test order.

What Scenarios the Templates Cover

The official documentation lists several practical starter templates: Event Hall / Banquet Booking, Hotel Room / Guest House Stay, Doctor / Salon / Consultant Appointment, Game Studio / Music Room / Sports Ground Rental, Car / Bike Rental, House Cleaning / Maintenance Service, and Online Classes / Coaching Sessions. These labels are helpful not as a ready-made marketing list, but as cues for choosing the right booking type.

For example, Hotel Room / Guest House Stay naturally points toward Multiple Nights and testing the check-in and check-out range. Doctor / Salon / Consultant Appointment suggests fixed time slots and resource or staff control. Game Studio / Music Room / Sports Ground Rental more often needs hourly or duration-based settings. Online Classes / Coaching Sessions may require Multiple Dates or dates with fixed time if the customer is buying a series of sessions.

A template speeds up product creation, but it does not know your real constraints. It does not replace capacity planning, staff schedules, seasonal pricing, holidays, cancellation rules, terms text, or checkout verification. Right after applying a template, open the product in draft status and review every tab in the Booking Meta Box.

How to Use Templates in a Real Workflow

1. Open Bookings > Add Product or the equivalent screen for adding a bookable product.
2. Choose the template that is closest to the real scenario, not just the business label.
3. Leave the product in draft status and rename it for the specific service.
4. Check the booking type, because that single choice determines the remaining tabs and pricing logic.
5. Configure availability, max bookings, resources, persons, and pricing.
6. Open the product preview and place a test order before publishing.

If the store offers many similar services, the template can become an internal standard. For example, a "specialist consultation" can always be created from one template, and the manager only changes the title, price, description, staff member, and slots. That is better than rebuilding the structure from scratch every time.

Where Templates Can Cause Problems

A template becomes risky when it is chosen by its nice-sounding label instead of by its actual mechanics. "Car / Bike Rental" may seem suitable for any rental business, but a full-day rental, a rental with separate pickup and return times, a rental by hourly slots, and a rental with multiple equipment units all require different checks. If the template creates a product with logic that is close but not exact, the administrator may start patching the symptoms by adding holidays, changing the price, or editing resources, when the real fix was to choose a different booking type.

So the rule is simple: use a template if it matches the main way the customer selects time. If only the industry matches but the logic does not, create the product manually or change the booking type before adding more complex rules.

Manual Bookings and the Manager's Calendar

Online booking does not eliminate manual work for the manager. A customer may call, send a message, ask to move a date, book a service for a corporate group, or request a custom slot. Booking & Appointment Plugin for WooCommerce supports administrative booking management: list view, calendar view, manual creation, editing, cancellation, filters, printing, and CSV, depending on the settings and product version.

Why View Bookings Matters

View Bookings is an operations screen, not just an order archive. In the WooCommerce order list, a manager sees the order as a commercial document. In the booking calendar, they see the schedule: when a service is occupied, which product is booked, which customer is linked to the event, where overlaps exist, and which records need action. Tyche documents the calendar view with week, month, and day switching, plus a qtip showing event details such as order ID, product name, customer name, start date, and end date.

For the business, that means the manager can work from the schedule without constantly opening each order. A salon may look at the day, a rental business may look at the week, a hotel may look at the month, and an event organizer may filter bookings by product or customer. If those built-in screens are not enough, you can add API or webhooks later, but the standard calendar is the right place to start.

Creating a Booking Manually

A manual booking record is useful for phone requests, offline sales, internal reservations, compensated reschedules, and corporate clients. Tyche's product history includes support for manual bookings, including order-based and order-free scenarios via the REST API. In the standard admin interface, the important thing is to understand whether you are creating the booking as part of a WooCommerce order or simply blocking a slot.

If the booking is tied to payment, refunds, emails, and accounting, it is safer to attach it to a WooCommerce order. If you only need to temporarily close a slot for an internal check, an administrative booking record may be enough, but make sure the reason is documented in the manager notes. Otherwise, a week later no one will know why the slot is occupied.

How Managers Should Work Without Causing Conflicts

Create a short internal process document. It should answer: who can create manual bookings, who confirms pending bookings, who cancels a booking, when reminders are sent, how reschedules are recorded, when test records are cleared, and who verifies calendar sync. In a multi-vendor store, also define the boundary between the store admin and the vendor: vendors can manage their own bookings, but global holidays, integrations, permissions, and system settings remain with the administrator.

The most dangerous manual action is changing the date without checking availability first. Before rescheduling, the manager should open the calendar and check the resource, slot, persons or capacity, and the order. After the move, they should verify the customer email and the availability of the old slot. If the old slot was not released or the new slot was not blocked, the problem will show up on the storefront next.

Timezone Conversion for Online Services and International Customers

If you sell local services such as venue rental or salon appointments, the timezone is usually obvious. But for online classes, consultations, webinars, coaching, and international customers, timezone becomes part of the user experience. Tyche documents Timezone Conversion: when it is enabled, time slots are displayed in the customer's local timezone, while the booking details remain linked to the store's original time.

This reduces "I thought that was my time" mistakes. But it requires clear communication. The form should display timezone information, and the emails, cart, checkout, Order Received page, and My Account should show the time in a way that both the customer and the administrator interpret consistently. If your team works in one timezone and your customers are spread across several, this setting is useful. If the service is physical and happens at a specific location, it may be safer to state the local venue time explicitly instead.

Where to Verify the Timezone

You should not check timezone behavior only on the product page. Run a test from a browser set to a different timezone, or ask a colleague in another region to go through the customer flow. Compare the time slots on the product page, cart, checkout, order received page, email notification, and edit booking page. Then check the Google Calendar event if sync is enabled. A mismatch at any stage creates conflict: the customer arrives at the wrong time, the manager sees a different time, or the calendar sends the reminder at the wrong moment.

If you use fixed time slots, timezone conversion needs to be especially clear. The buyer selects a slot in their local time, but the underlying booking record is still tied to the store's schedule. That is why the service description should include a plain-language note such as "Times in the booking form are shown in your local timezone" or "All in-person appointments follow the local time of the service location." Pick one approach and use it consistently across the site.

When It Is Better Not to Enable Timezone Conversion

Do not turn on timezone conversion just because the feature exists. For offline services tied to a physical address, the local time of the service location is often safer. If a restaurant in Moscow accepts table reservations, the visitor should see the restaurant's time, not the temporary browser timezone they happen to be in while traveling. For an online course with students in different countries, by contrast, timezone conversion may be essential.

The check is simple: ask which time actually governs the service delivery. If it depends on the business location, show the business's local time and explain that in the text. If it depends on the customer, enable timezone conversion and test the full flow through the email.

Migration, Updates, and Compatibility with Neighboring Plugins

On its product page, Tyche specifically mentions migration from WooCommerce Bookings while preserving orders, customer data, and related booking data. That is useful for stores that have already been accepting bookings and want to move to another tool. But migration is not just a settings import. You need to verify how old booking products, orders, resources, persons, time slots, statuses, and emails behave after the transfer.

How to Approach Migration

A safe sequence looks like this: create a full backup, use a staging copy, run a migration preview if available, and only then transfer the real data after reviewing the results. Do not run a migration on Friday evening right before active ordering hours. After migration, check old orders, future bookings, the calendar, occupied slot availability, emails, the customer account, and reports. If Google Calendar, CRM, or webhooks are involved, test them separately.

An important nuance is that availability rules are not always equivalent across plugins. Even if both products use terms like resources, persons, availability, and booking duration, the internal logic may still differ. So after migration, it is not enough to see the records appear in a list. You need to place a new test booking on top of previously occupied dates and make sure overbooking is impossible.

Compatibility with WooCommerce Extensions

Tyche documents compatibility and separate materials for WPML, Product Bundles, Composite Products, WooCommerce Product Addons, Gravity Forms Product Addons, WooCommerce Subscriptions, and multi-vendor solutions. The changelog also includes fixes for themes, checkout blocks, Germanized for WooCommerce, WoodMart, Porto, GreenShift, and other environments. That shows the real complexity: a booking plugin does not live alone, but alongside a large stack of WooCommerce layers.

If the product uses Product Addons, is a variable product, bundle, or composite product, your price and availability test must include that exact combination. For example, an add-on price may be calculated per day or not per day, a bundle may include child products, a variable product requires published variations, and a subscription product may add its own recurring payment logic. Do not assume that a test result for a simple product automatically applies to a more complex one.

Cache, Optimization, and Pages with Dynamic Availability

The booking form depends on dynamic data: the current date, selected days, occupied slots, resource, number of people, variations, price, and the cart session. That means pages for bookable products cannot be cached as aggressively as a static article. If cache or JavaScript minification saves stale HTML or breaks calendar events, the customer may see a slot that no longer exists or may be unable to select a date at all.

The practical minimum is this: exclude cart, checkout, my account, and when necessary bookable product pages from full page cache; check deferred or delayed JavaScript for the calendar; do not combine scripts blindly; and clear cache after changing availability. If the issue appears only for logged-out visitors while everything works for the administrator, the problem is almost always in caching, optimization, or theme-side client scripts.

Combined Scenarios with Complementary Products

Booking & Appointment Plugin for WooCommerce can serve as the core of your booking logic, with additional products added alongside it when they are genuinely needed. The important thing is not to confuse integration with coexistence. Integration means the products exchange data or are officially compatible. Coexistence means both plugins run on the same site, but each is responsible for its own part of the workflow.

Product Input Fields for Extra Customer Data

On the bundle page, Tyche mentions the Appointment Enhancement Trio Pack, which includes the Booking & Appointment plugin, Product Input Fields for WooCommerce, and the Partial deposit addon. For services, this is a logical combination: the booking plugin handles the date, time, resource, and order, Product Input Fields collects additional information, and the deposit addon can split payment if the business requires it.

Example: a stylist consultation uses the booking form for date, time, and specialist, while Product Input Fields collects size, preferences, a reference link, or a comment. The boundary of responsibility is clear: do not force the booking resource to store freeform customer answers, and do not expect custom fields to manage scheduling. After configuration, verify that the extra fields appear in the order and the email alongside the booking details.

Partial Deposits for Prepaid Bookings

Partial Deposits Addon is useful when the business does not want to collect the full amount upfront: rentals, tours, events, premium services, or bookings secured with a deposit. At the same time, do not combine deposits with requires confirmation without separate testing. One mechanism controls partial payment, the other controls manual approval before payment. Depending on your store rules, the customer should understand clearly when they pay, what the administrator confirms, and what happens in case of cancellation.

A good test scenario includes the product with booking details, the deposit amount, a test checkout, the email, order status, booking status, remaining balance, cancellation, and slot release. If any step is unclear, simplify the initial launch and add deposits later.

Seasonal Pricing and Rental System Addon

Seasonal Pricing Addon and Rental System Addon are worth considering when standard special prices and multiple nights are no longer enough. Seasonal pricing helps manage seasonal periods, while the rental addon adds rental-specific settings, such as sale-and-rent scenarios or blocking days before and after a rental depending on what the add-on supports. These are not required extensions for every store. They are useful when the business logic clearly goes beyond baseline pricing and availability.

A safe rollout order is this: first configure the base booking product, then verify the ordinary price, then add one seasonal rule or rental rule, then test a normal date, a peak date, a blocked date, and an order cancellation. If price or availability behaves unexpectedly, temporarily disable the add-on rule and compare the result.

How to Document the Setup for the Support Team

A large booking site cannot be maintained from one administrator's memory alone. A few months later, no one will remember why one product has Requires Confirmation enabled, why a resource has available quantity set to 2, why Friday is closed from 12:00 to 16:00, why a shortcode uses a specific category ID, or why one template override lives in the child theme. That is why you should create an internal documentation page after setup.

What to Record for Each Bookable Product

• Product name and edit link.
• The selected booking type and why it was chosen.
• Availability rules: weekdays, specific dates, holidays, time ranges, and priority.
• Capacity: max bookings, persons, resources, resource quantity, and blocking type.
• Pricing: base price, special prices, price by range, resource charges, and add-ons.
• Customer-facing text: terms description, cancellation policy, timezone note, and form hints.
• Test path: which slot was checked, which order was created, and what should be visible after booking.
• Integrations: calendar sync, reminders, webhook endpoint, or API consumer, if used.

This kind of documentation saves support time. When a customer says, "I can't select a date," the manager first compares the product against the expected rule instead of making random changes in the settings.

How to Record Changes After Updates

After updating the plugin or WooCommerce, create a short record of what was updated, which scenarios were tested, which issues were found, and which settings were changed. Tyche's changelog often includes fixes for specific cases: checkout block compatibility, resources, persons, grouped products, theme conflicts, time slot availability, Google Calendar import, and REST API. If your store relies on one of those scenarios, add it to your regression checklist.

For developers, it is helpful to maintain a list of template overrides and custom snippets. Each override should have its path, purpose, date of change in the internal documentation, link to the original template, and rollback method. That becomes especially important when the theme is updated separately from the plugin.

Safe Appearance and Text Customization

The booking form should be clear for the customer and visually consistent with the store theme, but changes should be made carefully. Tyche documents two safe directions: global appearance and label settings, and template overriding through a child theme or hooks. You should not edit the plugin files directly, because an update will overwrite the changes and may leave the site without a fallback template.

Labels and Calendar Without Code

Start with the built-in interface settings. In the Setup Wizard and global sections, you can configure labels, messages, calendar language, date format, time format, first day on calendar, number of months, and calendar theme. That is often enough to make the form clear: labels such as "Choose Date," "Choose Time," "Number of Participants," "Resource," and similar field text can usually be adapted without touching the templates.

If the site is multilingual, use WPML String Translation and the official WPML compatibility documentation. Do not translate strings directly in the plugin files. If you use WooCommerce Multilingual, also verify that booking details stay in sync between languages and that variations, fixed blocks, and statuses are not lost after duplicating the product.

Template Override Only for Stable Changes

If you need to change the markup of the booking form, email, or vendor dashboard, use the documented template override system. The plugin templates are stored in /woocommerce-booking/templates/, and copies are placed in the woocommerce-booking folder inside the active theme or child theme. For example, the booking form path may look like this:

wp-content/plugins/woocommerce-booking/templates/bookings/bkap-bookings-box.php
wp-content/themes/your-child-theme/woocommerce-booking/bookings/bkap-bookings-box.php

This is not a recommendation to rewrite a template right away. It is the safe path when a markup change is the only way to solve the problem. Before applying an override, make a copy, introduce the smallest possible change, then test the product page, cart, checkout, email, and My Account. Rolling back is simple: remove the file from the child theme, and the plugin will use its own template again.

A Small Custom CSS Adaptation

If you only need to improve the readability of the booking block slightly, start with CSS in the child theme or in the theme's built-in Additional CSS section. The basis for that change should be the public form markup on your own site and the documented template layer, not a hidden API. Do not use unverified classes from random examples. The snippet below is not a universal selector, but a safe principle: scope the change to the product page container and confirm the real classes in browser developer tools.

/* Custom adaptation: apply only after checking the actual classes on your site. */
.single-product .booking-form-wrapper {
  margin-top: 1rem;
}

.single-product .booking-form-wrapper label {
  font-weight: 600;
}

.single-product .booking-form-wrapper .booking-error {
  margin-top: .75rem;
}

Verification: open the product on desktop and mobile, select a date, trigger an error by leaving a required field empty, and add the product to the cart. Rollback: remove the CSS block and clear the cache. If the actual classes are different, do not force the CSS blindly - find the real booking form wrapper on your site first.

Product Video in the Context of WooCommerce Bookings

In an independent StoreApps article about WooCommerce bookings, there is an embedded video tied to the Booking & Appointment Plugin for WooCommerce section. It is useful as quick visual context: it shows the product being discussed specifically as a WooCommerce solution for bookable products, availability, Google Calendar, a search widget, changing booking details in the cart and at checkout, and approval-based booking. The video does not replace following Tyche's documentation for setup, but it does help show where the plugin sits among similar WooCommerce booking solutions.

After watching it, go back to your own products and check not the generic feature list, but the actual connections: which booking type is selected, how the price is calculated, where the booked slot appears, what the customer receives in the email, and how the administrator manages the booking.

Troubleshooting Common Booking Issues

In a complex WooCommerce booking plugin, errors rarely look like one clean failure. The customer sees "no slots available," "price is 0," "the button does not work," "the date is available but checkout fails," or "the email arrived without details." The administrator needs to break the symptom down across the chain: product, booking type, availability, resource, persons, cart, checkout, order status, cache, theme, and integration.

No Available Dates Appear on the Product

Symptom: the calendar is visible, but dates are unavailable, or a message appears saying there is no available time instead of showing slots. Possible causes: booking option is not enabled on the product, the wrong booking type is selected, all weekdays are disabled, the advance booking period is in effect, holidays cover the dates, range priority marks the required range as non-bookable, the resource is already occupied, max bookings has been reached, or the page is being served from cache.

Check: open the product in the admin area, make sure the booking type matches the scenario, then review the availability tab and the resources tab. After saving, clear the product page cache and open the storefront in a clean browser. If resources are involved, temporarily test the same slot on a product without the resource restriction. The fix depends on the cause: enable the correct weekdays, change the priority, remove the holiday, increase max bookings, assign the resource, or exclude the product from aggressive caching.

The Slot Stays Available After an Order

Symptom: one customer completes a booking, but another customer can still choose the same slot. Possible causes: the order received a status that does not reduce availability in your scenario, max bookings is higher than expected, the resource is not assigned, unlimited bookings is enabled, the blocking type is targeting the wrong range, quantity or persons are not being counted as capacity, or the test is happening on a cached page.

What to check: View Bookings, order status, resource assignment, persons count, max bookings per slot, overlapping settings, and behavior after order cancellation. If the problem appears only on the second product, check that both products use the same global resource rather than two separate resources with similar names.

The Price Shows 0 or Changes Unexpectedly

Symptom: the price on the product page, in the cart, or in the order differs from what you expected. Possible causes: no base product price is set, the booking price only appears after all booking details are selected, a special price overrides the standard price, price by range only applies to multiple nights, a resource charge or persons price is added at a different stage, a coupon or tax changes the total, or the variation price was not saved.

Check: create a minimal product without discounts or resources, confirm the base calculation, then add rules one at a time. If multiple nights is involved, test different durations: a short range, a boundary case, and a range outside the rule. For a variable product, publish the attributes and variations first, then configure price ranges.

Checkout Does Not Accept the Booking or the Button Behaves Strangely

Symptom: the product cannot be added to the cart, checkout refreshes but no order is created, or the payment button is unexpectedly replaced with a request confirmation action. Possible causes: required booking details were not selected, Requires Confirmation is enabled, the checkout block conflicts with an outdated scenario, the theme alters the product form, JavaScript minification breaks the calendar, or product add-ons or bundles add unmet conditions.

Fix: temporarily disable unnecessary JavaScript optimization on the product page and checkout, test the product with a basic theme on staging, make sure requires confirmation is enabled only where needed, and repeat the order without third-party product add-ons. If the issue persists, gather structured data: product version, booking type, product settings, steps to reproduce, order status, and messages from WooCommerce logs.

Google Calendar Does Not Receive Events

Symptom: the booking exists in WooCommerce, but no event appears in Google Calendar. Possible causes: OAuth setup is incomplete, the wrong redirect URI is used, the wrong calendar is selected, integration mode is disabled or manual, the order status does not trigger export, cron has not processed the import, the .ics feed is unavailable, or product-level sync is configured separately from global sync.

Check: open the Google Calendar Sync settings and verify the Client ID, Client Secret, connection status, selected calendar, and integration mode. Then create a new test booking instead of reusing an old order. For imports, verify the saved iCalendar/.ics Feed URL, the manual Import button, and the event-to-product mapping.

Emails and Reminders Arrive Without the Required Data

Symptom: the email is sent, but it does not include the date, resource, customer, phone number, or calendar link. Possible causes: the email template is overridden in the theme and is out of date, the placeholder is not supported in that email, booking details are hidden by settings, WPML String Translation did not sync the string, the reminder is sent to the wrong set of bookings, or the integration field is empty.

What to do: temporarily disable the custom email template override and check the default WooCommerce email, then restore the override and compare. If WPML is in use, verify the translated strings and the booking status in the default language. If emails are sent through an external SMTP service, confirm that the SMTP layer is not stripping HTML or attachments.

The best troubleshooting method is not to change ten settings in a row. Change one parameter, place one test order, record the result, and only then move on.

Questions That Usually Come Up Before Implementation

Can the Plugin Be Used Without On-Site Payment?

Yes, if the workflow is built around a confirmation request or manual handling, but it needs to be configured intentionally. The Requires Confirmation mode lets the administrator approve the booking before payment. WooCommerce still creates the order and the booking record, so you need to verify statuses, emails, and the follow-up payment flow after confirmation.

Which Is Better: Fixed Time Slots or Duration-Based Time?

Choose fixed time slots if the business defines exact intervals in advance. Choose duration-based time if the customer needs to select a start time and a duration within a working range. For rentals with both start and end date and time, look at Multiple Days & Time because it includes separate blocking type logic.

How Do You Prevent Double Booking for the Same Specialist?

Create the specialist as a global resource, assign that resource to every service where they work, and test overlapping slots with two separate test orders. If the specialist is mentioned only in the product title, the plugin cannot track that person's occupancy across other products.

Why Can the Customer Not See a Slot the Administrator Thinks Is Free?

The cause may be holidays, disabled weekdays, the advance booking period, resource availability, max bookings, time availability priority, persons capacity, page cache, or the status of an existing order. Start with the product settings and View Bookings, then move on to cache and theme checks.

Can All Available Bookings Be Shown on One Page?

Yes. That is exactly what Available Bookings Block in the block editor is for, or the [tyche-bookings] shortcode in Classic Editor and technical pages. You can filter by products, categories, booking type, or resources and choose either list or calendar view.

Do You Need to Connect Google Calendar Right Away?

No. First get a stable test booking working inside WooCommerce. Then add Google Calendar as the next layer: OAuth, redirect URI, selected calendar, placeholders, a test booking, and .ics import if needed. That makes it much easier to separate product-level issues from integration issues.

Can the Form and Email Templates Be Modified?

Yes, through the documented template override system in a child theme or through hooks, but not by editing the plugin files directly. Before changing anything, create the smallest possible override and test the product page, cart, checkout, My Account, and emails. Rollback should be easy: remove the overridden file or disable the custom code.

Is the Plugin Suitable for a Multilingual Store?

Tyche documents WPML compatibility and separate steps for String Translation, WooCommerce Multilingual, and syncing booking details. In practice, a multilingual site always needs extra testing: translated strings, duplicated products, variations, fixed blocks, emails, and account-area statuses all need to be checked.

When Booking & Appointment Plugin for WooCommerce Is the Right Choice

This plugin is worth using if you want to sell time and availability through WooCommerce instead of keeping booking in a separate system. It is especially strong for products with multiple booking types, resources, people/persons, special pricing, manual approval, reminders, calendar sync, Available Bookings Block, API, webhooks, and multi-vendor scenarios. But it should be implemented as business logic, not as "just another calendar."

Start with one test product, choose the correct booking type, configure availability, verify the resource or capacity, place a test order, review the booking in the admin panel, check the email, and confirm the occupied slot. Only after that should you roll the setup out to real products and start enabling integrations, reminders, templates, and external systems.

If, after testing, you see that the model fits your store, you can download Booking & Appointment Plugin for WooCommerce and test it on a site copy or on a separate product. That order of operations protects you from the biggest mistake: buying a flexible tool and then configuring it without a clear rules map, result verification, and a support plan.