CodeCanyon Team Booking - WordPress Plugin

CodeCanyon Team Booking Setup Guide for Service Bookings

This guide to CodeCanyon Team Booking will help you connect your team’s schedule to a booking form, prepare a safe WordPress environment, set availability rules, and test the visitor’s path from choosing a time to receiving confirmation. It walks through a practical setup for fixed-time services, events with limited capacity, and requests that do not need a specific time slot.

There is some history behind this product that matters when you set it up. The CodeCanyon listing describes the Team Booking branch, while the developer is building a new platform called TheBooking. First, identify which build you have installed, back up your site, and avoid applying instructions for the new interface to the older one without checking them. This guide covers confirmed Team Booking features and general WordPress best practices.

The core idea is simple: the calendar on your page should reflect real working hours, account for periods that are already booked, show visitors only clear booking options, and leave the team with a record they can verify in the booking list. Decide in advance where availability comes from, who can change it, and when a request becomes a confirmed booking. That will make the system much more predictable.

How Booking Works: Three Components and One Source of Truth

Before installing the plugin, it helps to separate the system into three components: the service, the provider, and availability. The service answers what the visitor is booking: a consultation, workout, technical visit, group class, or request with no time selection. The provider is the person who can deliver the service. Availability defines when that provider is actually available. When these roles are mixed together, the calendar can show unnecessary slots and staff may receive requests for work they do not perform.

Team Booking is designed for bookings through WordPress and supports several service types. For Appointment and Event, the time and available slots matter; an event can also have a capacity limit. An Unscheduled service creates a request without a specific time, with a separate rule determining how a provider is assigned. Choose a type based on what the customer needs to do, not on the name of the business: book a provider’s time, reserve a place in a group session, or simply send an inquiry.

The second essential component is the source of availability. In Team Booking’s basic setup, availability for timed services can come from a provider’s Google Calendar after authorization. Newer generations of the product also have their own scheduler. Do not assume that an older installation includes every newer mode. If your process relies on Google Calendar, decide in advance which events represent open time, which mark personal commitments, and which calendar should receive confirmed bookings. Putting everything in one personal calendar may work technically, but it can quickly become difficult for the team to review.

A practical setup for a small studio might give each provider a separate work calendar for availability, put personal appointments in another calendar or explicitly exclude them, and send confirmed bookings to a separate destination calendar. This is an organizational best practice, not a feature that is required in every version of the plugin. It helps prevent staff from editing a confirmed booking along with future open slots and makes conflicts easier to spot.

What Visitors See and What the Admin Area Tracks

The public-facing site should offer a short sequence: choose a service and, if needed, a provider; see available dates; select a time slot; fill out the form; and receive a clear message about the booking’s status. Team Booking documentation describes a calendar with service and staff filters, a time zone selector, month navigation, and a list of slots that appears after the visitor selects a date. When there are several services or providers, filters help narrow the options. With only one service, an extra filter can create unnecessary uncertainty, so consider hiding it with a shortcode option after testing the page.

The booking has a longer lifecycle in the admin area. The team needs to see the request, its status, the form details, the assigned provider, and the next action. If a service requires manual confirmation, a new booking may need approval from an administrator or staff member. That can be useful when the requested time needs to be reviewed first, but someone must be responsible for handling it. Assign a person to review the queue every business day; otherwise, the customer may receive a request receipt without ever getting a confirmed appointment.

Do not use the public calendar as your only report. It shows what the visitor selected, but it cannot explain why a booking was canceled, why payment failed, or why a notification was not delivered. Use the Team Booking booking overview and a test booking with a separate email address for operational checks. This lets you compare what the visitor saw, what data was saved, what the provider received, and whether availability changed in the selected scheduling source.

Who This Booking Model Suits-and Who May Need Something Else

CodeCanyon Team Booking is a good fit when the schedule already lives in Google Calendar and the WordPress site needs its own booking page without requiring staff to copy open times manually. This is a common setup for consultants, service teams, independent professionals, training groups, and companies with several providers. One of its strengths is the connection between calendar scheduling and the booking form: a time slot appears because it is managed through a familiar calendar workflow, rather than simply because it was created in WordPress.

The plugin can also work well when a site needs different kinds of bookings. For example, a one-on-one consultation can use a specific time slot, a public workshop can offer a limited number of places, and a preliminary estimate can be submitted as a request without choosing a time. Keep these use cases separate instead of forcing them into one general calendar. Create distinct services, give them clear customer-facing names, and test each one on the public page.

This may not be the right solution if the business needs full multi-day property rentals, complex resource logistics, multi-level dispatching, or ongoing synchronization with several external systems that the developer has not confirmed for the installed version. Be cautious if the team is not prepared to maintain Google OAuth access, site email delivery, and booking status checks. The plugin automates the booking flow, but it does not replace access rules, email deliverability, or responsibility for the schedule.

A practical rule of thumb: sketch one customer journey and one staff workflow before you begin. If it is unclear where open time comes from, who confirms a booking, or what happens after a cancellation, hold off on designing the interface.

Map the Booking Flow Before You Configure Anything

It helps to agree on the flow of information before settling on tab names. A provider or administrator schedules availability. The plugin matches that availability to a service and its display rules. Visitors see only the options available in their selected time zone. After they submit the form, a booking is created with a status determined by the confirmation setting. Calendar data, notifications, and the booking list then change accordingly. Any unclear point in this chain should become a separate check on a test site.

This approach helps prevent a common mistake: designing an attractive page first and then trying to work out why two people can see the same slot. Design, colors, and labels matter, but they come after time, capacity, confirmation, and cancellation rules. Once those basics are in place, you can add a location map, provider information, form fields, or even payment where they help meet a real need.

Prepare WordPress and the Schedule Before Activating the Plugin

Do not configure bookings on a live site by trial and error. Before installing the plugin, back up the files and database, confirm that you have WordPress administrator access, and make sure you can access the mailbox that will send notifications. If you plan to use Google Calendar, choose a Google Cloud project owner and someone who can update its settings if the domain or team changes. Do not store OAuth credentials in an article, screenshot, public form field, or ordinary message to providers.

The Team Booking listing specifies minimum requirements for this branch, including WordPress and PHP versions. For a live site, however, what matters most is whether the archive you have is compatible with your version of WordPress, PHP, and your theme. Do not stop at confirming that activation produces no fatal error. Open a page with regular content, the page editor, the Plugins screen, the hosting error log, and the contact form. If warnings appear after installation, pause configuration and restore a compatible environment on a site copy first.

Pre-Installation Checklist

Preparing the site takes less time than sorting out duplicate bookings after launch. These checks help you distinguish infrastructure issues from problems with your booking rules.

• Test site. Install the plugin somewhere you can create services and test bookings without affecting real customers.
• WordPress time zone. Check the site’s general settings and compare the configured time zone with the team’s primary working time zone.
• Permalinks. Note the current structure and make sure the public booking page opens without redirects or errors.
• Email delivery. Send a test message using the site’s existing mail configuration, rather than relying only on the plugin’s form.
• WordPress roles. Decide who will be an administrator and who will only be a provider. Do not give all staff full administrator access just so they can use the calendar.
• Cancellation policy. Before enabling the calendar, agree on how far in advance customers can cancel and who handles exceptions manually.
• Test email addresses. Prepare separate addresses for the customer, administrator, and provider so you can verify notification recipients.

Time zones need special attention. Team Booking documentation describes displaying dates and times in the WordPress time zone and allowing visitors to choose their own time zone in the public calendar. The selected time zone is saved with the booking, and the notification time may be adjusted to match. This is useful for online consultations, but can cause confusion for in-person services if the team reads messages in local time. If that applies, clearly state the meeting location and, where relevant, the organization’s local time in the service description and email.

Set Up Google Calendar Without Mixing Its Roles

Connecting Google Calendar involves more than clicking a button. The newer TheBooking documentation describes creating a separate Google Cloud project, setting up a web application OAuth client, enabling the Calendar API, and matching the authorized redirect URI exactly to the address shown by the plugin. The screen names may differ in an older installation, but the basic idea is the same: the plugin gets limited permission to read the required calendars and create or update events through the configured connection.

Create a separate Google Cloud project for this site instead of using a project that belongs to another organization. Use HTTPS before starting authorization. Copy the redirect URI and authorized origin shown in the plugin interface exactly. A single incorrect character can cause authorization to fail, which may look like a plugin problem even though the cause is in the OAuth settings. Do not publish the client ID, and especially the client secret, in public HTML, a repository, or an unprotected message.

After connecting the account, do not start configuring services right away. First, make sure the correct account can see the expected calendars. Then, for one test provider, decide on three things: which calendar supplies availability, which calendar shows personal commitments, and where confirmed bookings will go. The current TheBooking documentation recommends keeping the source and destination calendars separate, so confirmed bookings do not clutter the view of future availability. The same arrangement can also reduce the risk of accidentally making a confirmed slot available again in an older Team Booking setup.

If you have several providers, do not connect one shared personal account to every service just to save time. It is safer for each staff member to use their own connection, with the authorization status checked in the staff list. Team Booking documentation uses these statuses to show whether a provider is ready to work with calendar availability. Do not ignore a temporary authorization status: revoke it and reconnect, since a partially completed permission flow can lead to unpredictable behavior.

Required check: Before publishing, create one test open period and one busy event in the availability source. The site should show only the expected available option, and it should not offer the busy period to visitors.

Install the Plugin and Run an Initial Technical Check

Install the plugin through the standard WordPress flow: in the admin area, open Plugins, select Add New, upload the provided ZIP archive, and click Activate. Do not manually extract the archive over an existing folder on a production server unless you have a documented update procedure. You could leave outdated files in place or lose the option to roll back. After activation, record the archive version and the date of your internal check in the team’s working notes, not on the public page.

Seeing Team Booking in the menu does not mean the system is ready. Open it as an administrator, create a single test service, and leave payment, notifications, and the map disabled for the first pass. The goal is to confirm that the plugin screen saves data and WordPress does not return an error. Then create a temporary page and add the calendar using the built-in shortcode builder or enter [tb-calendar] manually. Publish it as a restricted draft and view it in a separate browser without logging in to WordPress.

If the calendar does not appear, do not change ten settings at once. Check these items in order: Is the page published? Does an access rule prevent guests from viewing it? Are there any open periods? Is the service available to the selected provider? Is there a JavaScript error? Is the cache serving old markup? This order saves time because a blank calendar is usually caused by missing availability or filters, rather than the shortcode itself.

Older versions of Team Booking may have built-in blocks and a shortcode generator button for the block editor. Do not assume a button’s label is permanent documentation: check the final shortcode and the public page after inserting it. The [tb-calendar] shortcode displays a general calendar of available services, and its options can limit the display to specific services or providers. Use those limits to create purposeful pages, not to hide structural problems-for example, one page for a particular consultation and another for a group of specialists.

Use the First Booking as an Acceptance Test

Complete a test booking as a guest. Choose a date and slot, fill in only the required fields, and save all emails. After submitting the form, check five things: Did the customer see a clear message? Did the booking appear in the overview? Was the notification sent to the correct address? Did the slot’s status change on the site? Did the connected calendar update as expected for your setup? Seeing a new event in Google Calendar alone is not enough: the visitor may not receive an email, or the slot may remain open for another booking.

Once the basic flow works, delete the test booking or cancel it the way a real customer would. Check that the slot is released or remains occupied according to your rules and that the test customer’s personal data is not left in email templates or demo services. Then move on to the detailed service setup, not before.

Design Services, Slots, and Team Rules

Team Booking is easier to configure when each service is defined as a complete agreement with the visitor. It needs a clear public name, a clear purpose, one provider or a group of providers, a duration, access rules, a confirmation policy, a booking form, and a cancellation policy. If any of these are unclear, the plugin may create a booking successfully, but the customer may not understand what they booked and the provider may not know what to do next.

Start with your most common service. Do not create a dozen nearly identical services just because the team uses many internal names. Configure one consultation, run it through the full booking flow, and only then copy the tested setup for other booking types. Split services when they genuinely differ in availability, duration, capacity, form, provider, confirmation rules, or public page.

Choose a Service Type Based on What the Customer Needs to Do

Appointment is appropriate when one customer books a specific period of one provider’s time. Examples include an assessment, remote consultation, specialist service, or technical visit. Duration, the buffer between slots, provider availability, and clear start and end times matter here. In Team Booking, the duration can be fixed or inherited from the linked availability event. Do not mix these modes without a reason: a fixed duration creates consistent slots, while inheriting the event duration is useful when the schedule defines the length of each specific window.

Event works well for a class, meeting, tour, or group activity where several people can book places during the same period. Set the total capacity and decide separately whether one customer can book more than one place. Team Booking documentation describes a total limit and a per-customer limit for events. These are not substitutes for personal data rules: if you display participants’ names or other details on the public page, consider whether that is necessary and avoid exposing more than you need to.

An unscheduled request is useful for an estimate, support inquiry, preliminary request, or service where a date will be agreed on later. Do not expect the calendar to distribute the workload automatically in this case. The documentation describes assignment rules such as distributing requests evenly, assigning them to a specific provider, or choosing at random. Before the first launch, choose the rule that reflects how the team actually works. Even distribution is useful for similar requests; direct assignment suits requests that require a specific expert; random assignment is appropriate only when providers have genuinely equivalent skills.

Start with the Main Service Settings

In the service’s global settings, give it a short customer-facing name that staff will also recognize. Its description should explain the outcome, duration, and any preparation, rather than serve as an internal note. Team Booking documentation says the description appears in the booking form and supports HTML. Use this sparingly: one short paragraph and a preparation list are more useful than a long sales pitch inside a pop-up form.

The service color can do more than add decoration. The documentation describes using it in filters and to mark available slots. Set a simple rule: the same type of service always uses the same color, and color is never the only way to convey meaning. Visitors should still understand the service name without relying on color. Avoid using red as the standard color if the interface might make it look like an error or a busy period.

Set event capacity conservatively. The technical maximum is not necessarily a comfortable number of participants. If an event depends on equipment, a room, or an instructor, let the real resource determine capacity. A class with ten chairs should not have a limit of twenty just because the plugin allows it. After saving, make two test bookings with different email addresses and then a second booking with the same address. This checks both total capacity and the per-customer limit.

Duration, Buffer, and Booking Window

Duration defines how long the service takes for the customer; the buffer is time the team needs before the next slot. A buffer is especially useful for in-person services. It can cover room setup, travel, in-person payment, or a short debrief. Team Booking documentation describes a buffer between consecutive slots when the duration is fixed. Configure it around the actual schedule, not as a decorative option. If a service takes 45 minutes and the team needs 15 minutes to prepare, availability should account for that gap.

Booking windows help prevent two opposite problems. Without a minimum lead time, a customer could book one minute before a service starts, when the provider may not be checking notifications. Without a planning horizon, the calendar may make promises months ahead that the team is not ready to keep. Team Booking’s personal availability settings include a rule that hides a slot when it is too close to its start or end. Agree on the right values for each service, then test them with slots close to the current time.

Give Providers Access to the Right Services

In Team Booking’s Core settings, you can choose which WordPress roles are allowed to be providers. Administrators remain eligible as well. This does not mean you should grant access to every role on the site. Separate people who manage global settings and forms from those who only manage their own availability. That boundary reduces the risk of a provider accidentally changing a service’s price, cancellation policy, email template, or permissions.

After adding a provider, set the list of services they are allowed to offer. The documentation says new services may be available to all providers by default, so check this list whenever you create one. It can cause problems if a specialist suddenly appears in a customer-facing calendar filter for a service they do not provide. That is not a design bug; it means the service assignments were not specified.

A provider’s personal settings apply only to that user. Changing participation or a calendar connection does not change a colleague’s configuration. Explain the difference to the team in a short instruction: global settings define the service for everyone; personal settings define an individual provider’s participation and availability connection. Without that distinction, staff may expect their actions to update the entire schedule automatically.

In short: A service is ready when you can answer five questions: What is being booked? Who provides it? When is it available? How many places are there? Who makes the final decision?

Confirmation, Cancellation, and Slot Status

Manual confirmation makes sense when a request needs to be reviewed first: a specialist has to assess the request, an appointment needs clarification, or a site visit depends on the customer’s location. But a pending status should be a business rule, not a setting you turn on just to be safe. Team Booking documentation warns that double bookings can occur if a request awaiting confirmation does not hold its slot. If it does hold the slot until someone decides, other customers may be unable to book a suitable time while the team delays its response.

For scarce time slots, it is usually safer to let a pending request hold the slot until a decision is made and to have a prompt review process. If requests are often declined, you could leave the time available, but staff must be ready to handle competing requests manually. In either case, test two requests for the same period in succession. Do not rely on the setting’s label alone: check what two separate guest browsers show and which statuses appear in the overview.

Customers and staff should both be able to see the cancellation policy. Team Booking can let customers cancel through a public booking list or an email link, with a cutoff before the service begins. Choose the cutoff based on how much notice you need to offer the released time to someone else. After a cancellation, check the full flow: Did the booking change in the overview? Was the appointment released or event capacity restored? Did the provider’s calendar update? Was the correct message sent? Did the old link stop working after the cutoff?

Do not enable a cancellation button just because the option exists. For a private corporate service, it may be more important for a coordinator to handle cancellations. For a large public event, self-service cancellation may reduce the administrator’s workload. The setting should match your service policy, not replace it.

Use the Booking Form to Collect Only What You Need

The form should collect only what is necessary to provide the service or contact the customer. For an initial consultation, a name, email address, and selected time are often enough. Add a phone number if it is needed for reminders, an in-person meeting, or an urgent clarification. Do not collect government ID details, extensive medical information, or open-ended responses without a clear purpose and legal basis.

For conditional fields introduced in later Team Booking updates, start with a simple check: Which field appears when the user selects a particular option? What is saved with the booking? Does it appear in the right email? Conditional fields are useful when they genuinely shorten the form, not when they are used to build a full questionnaire. A long form can reduce completed bookings and make issues harder to diagnose, since visitors may leave before the booking is created.

Form fields and email templates are parts of one system. If you add a question but do not include it in the provider’s email or the booking record, staff will miss the context. If you add a field to the customer’s email without testing it, the customer may receive an empty value. Team Booking uses dynamic placeholders such as [first_name], [start_datetime], [service_name], and [coworker_name]. Use only the placeholders each recipient needs and test them with a real booking.

Connect the Calendar: From an Open Event to a Confirmed Booking

Working with calendar availability is the most powerful and demanding part of CodeCanyon Team Booking. Visitors see more than a grid of times: they see the outcome of rules about which events count as available, which periods are excluded as busy, how long a slot lasts, and what changes after a booking. Do not make claims about internal architecture that the developer does not document. Understand the observable flow and test it with your own data.

Team Booking documentation connects open periods for timed services to Google Calendar events after the provider is authorized. For each personal setting, you can define the event title that should count as an open slot and the title that will be applied after a booking for an Appointment. That makes a calendar event’s title part of the working rules. If staff enter it with different spacing, abbreviations, or languages, availability may not behave as the administrator expects.

A Minimal Setup with One Provider

For the first connection, choose one provider and one service. Sign in to Google under that provider’s account, complete authorization, return to the staff list, and make sure the connection is ready for calendar use. Then, in the service’s personal settings, define the open-event rule and create one period in the schedule source that clearly matches it. Do not use recurring events, exceptions, or complex colors in the first test. You need a repeatable outcome before you build out a real quarterly schedule.

Open the test calendar page in a new window without logging in to WordPress. If the slot does not appear, check whether the service is assigned to that provider, whether the correct Google account is connected, whether the open event’s title matches, whether the period is in the future, whether the minimum booking lead time hides it, and whether a provider filter excludes it. Do not change OAuth credentials right away. In most cases, the connection is fine and the availability rule simply does not match the event that was created.

Once the slot appears, make a test booking and check how the schedule source changes. For a one-on-one appointment, look for the new status or booking title, customer details, and the event color if one is set. Do not put more personal information in the event title than the provider needs to see in the calendar. The documentation warns that event descriptions may be visible to customers added as guests, so do not automatically put confidential notes there.

Why It Helps to Separate the Source Calendar from the Booking Calendar

The current TheBooking documentation distinguishes between source calendars for availability, personal calendars used to detect conflicts, and destination calendars where events are created after confirmation. The same idea can help when configuring the older branch carefully: one place defines when customers can book, and another records the resulting commitments. If open events and confirmed bookings share a calendar without clear labels, a provider could edit an event manually and accidentally make a booked time available again.

This separation is especially useful for a team whose providers have many personal appointments. The availability source can contain only designated work hours. A personal calendar can block conflicts if the supported configuration takes it into account. The destination calendar can show confirmed services and keep customer details separate from work notes. This does not remove the need to check what the installed version supports, but it provides a useful organizational boundary.

If you use one shared calendar, establish clear rules: which prefix means availability, which means a confirmed booking, who can edit events, and how cancellations are recorded. Test those rules with a regular provider account as well as an administrator account. The interface may restrict global actions, but someone who owns an event can still edit it in Google Calendar.

Event-Based Duration and Fixed-Length Slots

Choosing between a fixed duration and a duration inherited from a Google Calendar event changes how the schedule is managed. A fixed-duration setup works well when every consultation takes the same amount of time, plus a buffer. The administrator sets one consistent rule, while providers create longer availability blocks that the plugin divides into predictable slots. Inheriting the duration is more convenient for services of varying lengths, when a provider creates precisely defined windows in the calendar.

Neither mode is inherently more professional. What matters is that the team does not manage availability in two different ways at once. If the administrator expects fixed slots but a provider creates calendar events of arbitrary lengths expecting them to become equivalent slots, customers may see unexpected options. Document the chosen rule for staff and keep examples of acceptable events in a separate internal guide.

A Buffer Shows When the Team Is Ready for the Next Customer

A buffer between consecutive slots is often treated as an artificial restriction. In practice, it accounts for preparation and wrap-up time. Team Booking documentation says this setting applies between slots when the duration is fixed. Test it by creating an availability block that would fit three appointments with no buffer, then add the actual gap between appointments and refresh the public page. The number of options should decrease in a predictable way. If it does not, do not publish the calendar yet; check how your version interprets duration and availability blocks.

Make sure the team knows about the buffer instead of showing a continuous string of appointments in the provider’s personal schedule. Staff should understand why the site’s calendar shows fewer options than the length of their shift might suggest. The internal calendar and the public page should describe the same schedule, even if they present it differently.

Time Zones and Remote Consultations

Team Booking lets visitors choose a time zone in the calendar. The documentation explains that the selected zone is saved with the booking and used to adjust the dates and times in the confirmation email. This is useful for online services when the team and its customers are in different locations. However, the setting does not replace clear instructions. Explain on the service page whether the meeting uses the customer’s time zone or the organization’s and how the customer will receive a connection link.

Test at least two time zones. In one browser, leave the site’s time zone selected; in another, choose a different one. Compare the available slots, submit the form in the second window, and check the administrator’s booking record, the customer email, and the provider’s event. All three should refer to the same moment in time. Different displayed times are fine if they accurately reflect different time zones; different actual time slots are not.

Disabling the time zone selector with notimezone="yes" makes sense for a local in-person service only when visitors are certain to be in the organization’s time zone and the extra choice is confusing. For webinars, consultations, and international customers, hiding the selector is more likely to cause missed appointments. Base the decision on the risk of time-related errors, not on how the page looks.

Where Automation Ends and the Team’s Responsibility Begins

Google Calendar is not an independent authority on bookings. Its access rules, OAuth status, API changes, and user edits are outside WordPress. The product listing explicitly notes its dependence on Google’s infrastructure and terms. Your operating procedures should therefore include two regular checks: confirm that providers’ connections are still active, and make one test booking after significant changes to the domain, theme, email service, or calendar settings.

Prepare a fallback procedure without technical secrets: who cancels a problematic booking, how a slot is manually opened or blocked, who responds to the customer, and where the reason is recorded. Do not promise customers that automation will never fail. A short, tested procedure gives the team a clear response if something goes wrong.

Check the outcome: After a test booking, compare four places: the public calendar, the booking overview, the customer email, and the provider’s event. They may look different, but they should describe the same service, provider, and point in time.

Build a Public Calendar, Shortcode, and Form with Fewer Steps

Once availability and service rules are working, you can build the customer-facing booking flow. The goal is not to make the calendar look like a complex management system, but to help visitors find a suitable option quickly and understand what happens next. The booking page should show the service name, who it is for, the duration or another important condition, cancellation rules, and the calendar itself. Move other information to a related service page instead of turning the booking form into a long reference document.

The basic shortcode, [tb-calendar], displays the main calendar. Team Booking documentation confirms that it can show available slots for different services and that its attributes can limit the display to specific service or provider IDs. Service IDs, not customer-facing names, go in the shortcode parameters. Do not edit them blindly on a published page. Use the shortcode builder in the editor or keep a short list of tested examples in your internal documentation.

When to Use a Shared Calendar or a Separate Page

A shared calendar is useful when visitors choose among several closely related services, such as an initial consultation, a follow-up appointment, and a short introductory call. The service filter gives them one place to start. The services need distinct names and clear descriptions, or visitors may not know which one to choose. If a service is more involved or has its own landing page, embed a calendar limited to that service there. Visitors have fewer decisions to make, and it is easier to check that the page gives them the right context.

Show a provider-specific calendar when customers are expected to choose a specialist. Team Booking documentation describes limiting the calendar to specific staff members with the coworker attribute. Do not use that option to work around an assignment problem. If customers should not choose their provider, do not create individual pages just to fill out the site. Let the service’s assignment rule handle distribution and keep the public flow short.

Filters are usually unnecessary for a calendar with one service and one provider. Team Booking allows you to hide a filter with the nofilter="yes" attribute. Before enabling it, check the page at both mobile and desktop widths. A filter can take up space and distract from choosing a date. Hide only what visitors do not need to select. If a page includes several similar options, always make clear which service the visitor is booking.

Read-Only Calendar or Booking Calendar

Sometimes the calendar is meant to show a seminar schedule, open hours, or upcoming events rather than accept bookings. Team Booking supports the read_only="yes" mode for informational calendars. This is useful when registration follows another approved process or when you want to show a provider’s availability without opening the booking form. Do not present a read-only calendar as a booking form: clearly explain where visitors should go next.

The logged_only="yes" attribute hides the calendar from users who are not logged in. Use it only when access should actually be limited to site members. The documentation notes that guests viewing a service limited to logged-in users may see a read-only calendar and be prompted to sign in or register. Test this flow in a clean browser: the link should lead to the right page, and after signing in, the user should return to the calendar if that is how the site is configured. Otherwise, the restricted service may look broken.

Booking Form: What to Explain Before the Customer Clicks

Customers decide whether to book before they enter their name. Briefly explain four things next to the calendar: the service duration, the meeting format, any preparation required, and the rules for rescheduling or cancellation. If the service is paid, do not use this page to explain how to purchase the plugin or enter activation codes. Show only the service’s booking process: when the commitment takes effect, how the customer will know the booking succeeded, and whom to contact about an exception.

Do not add a form field just for reporting. Every field should have a recipient and a purpose. For example, a “Preferred contact method” field makes sense if the provider will see and use the answer in the booking record. Remove a question if nobody will read the response. Fewer ambiguous fields make it easier for customers to finish booking and for the team to minimize the personal data it collects.

Test the form in three states. First, submit it with required fields empty and make sure the prompts are easy to read. Then enter a short, valid response and check that the booking succeeds. Finally, enter a long name, an international phone number if the form asks for one, and text with special characters to confirm that emails and the admin area display the data correctly. This is a routine check that real customer details will not be cut off or garbled.

Conditional Fields Should Not Hide Critical Information

Conditional form fields are listed in later Team Booking updates. Use them for genuinely different service branches: for example, show an address field only for on-site visits, or show a brief follow-up when the customer selects a consultation topic. Do not hide a required acknowledgment of an important rule behind a condition. Cancellation policies, essential data handling details, and meeting format information should be available to everyone before they submit the form.

Test each branch separately. Choose the first option, complete the form, save the booking, and check the email. Then choose the second option. No required conditional field should be hidden while still being mandatory, and the provider’s message should contain only relevant answers. If the team cannot test every branch after changing the form, keep it simpler.

Booking Emails Are Part of the Service

Team Booking lets you configure messages for the administrator, provider, and customer using dynamic placeholders. The documentation lists date and time, time zone, number of places, booking ID, service, provider, cancellation link, and other values. Start with a recipient matrix, not a polished template. Customers need confirmation, the time, meeting format, cancellation instructions, and contact information. Providers need the service, time, form details, and next steps. Administrators need enough information to review the status and resolve conflicts.

If manual confirmation is enabled, the email should distinguish between “request received” and “booking confirmed.” Do not tell the customer the booking is final while a staff member can still decline it. For a delayed decision, explain when they can expect a response and whether the time is tentative or held under your chosen rule.

Test placeholders with a real booking. [start_datetime] is useful for the date and time, [timezone] helps explain the time zone, and [service_name] and [coworker_name] provide context. Do not fill the email with every available marker. Unnecessary internal IDs and empty fields make it harder to read. If you use a cancellation link with [cancellation_link]...[/cancellation_link], test it as a guest and again after the cancellation cutoff has passed.

Check the outcome: One test booking should produce three different but consistent messages: one for the customer, one for the provider, and one for the administrator. If all recipients get the same email, it probably does not tell someone what they need to do.

Upcoming Events and Other Ways In

For events you want to show outside the main booking page, Team Booking provides the [tb-upcoming] shortcode. The documentation describes options for the number of items, a button to load more events, list limits, and event descriptions. Use it to complement the calendar, not as a separate source of truth. The upcoming events list should lead to the same service and follow the same availability rules.

For example, a course page could show a few upcoming classes, while the service page displays the full calendar. Choose a short list that fits the page design, and make sure past events do not give the impression that they are still available. If you enable a load-more button, set a reasonable limit. An endless list rarely helps someone choose a specific time.

Widgets can fit in a site’s sidebar, but Team Booking documentation notes that their CSS differs from the shortcode’s. Do not apply a widget setting to the main booking page until you have checked responsiveness and accessibility. For a key booking page, it is usually safer to put the main calendar in the content area, where the form and rules will not be squeezed into a sidebar.

Practical Example: Booking Consultations with Three Specialists

Consider a small team that offers remote consultations. The site has three specialists, but only two take introductory meetings. Each meeting has the same duration and needs a break between appointments. Customers can choose a specialist only on that specialist’s consultation page. On the shared page, visitors choose the service, and the system shows the availability of providers who offer it and have connected their work schedule.

The goal is not to present one universally correct setup, but to work through the chain of input - product rule - outcome - check - failure symptom - fix. By the end, you will have a test page where customers see only future openings for the right specialists, submit a short form, and receive a clear email, while the team can find the booking in the overview and its chosen calendar workflow.

Step 1. Define the Service and Who Owns It

Create a service with a clear name, such as “Introductory Consultation.” In the customer-facing description, state the format, duration, and what to prepare. Do not use an internal code or provider’s last name; set those details elsewhere. Choose the Appointment type because the visitor is booking a specific time with one person. In the global settings, set a fixed duration and a buffer if every meeting takes the same amount of time. Create a separate service for a specialist who works differently only if the duration or rules actually differ.

Assign only the two relevant providers to this service. Give the third specialist a different set of services. Check the personal settings for both assigned providers: they must be allowed to offer the service, and their calendar authorization must be active. Document the internal assignment rule separately. In this example, customers choose a provider only on an individual page, so the shared calendar can show availability for both. If you want automatic assignment, do not add an unnecessary “Who would you like to choose?” question to the shared form.

Step 2. Set Up Availability and Exceptions

Create one test open period in each provider’s work calendar. Agree on the event title or other marker that your Team Booking configuration uses to recognize availability. Also create a personal busy event next to that period. The goal is to confirm both that open times appear and that busy periods are not offered by mistake.

Do not add recurring events for several months at this stage. Recurring events are convenient, but first make sure you understand how the installed version handles the next available period. After that check succeeds, create regular work hours and test an exception separately: a vacation, closed day, or internal meeting. A provider’s schedule should update wherever the team actually manages it, without requiring manual duplication on the site.

Step 3. Build the Page and Limit What It Shows

Create a “Book a Consultation” page in the WordPress editor. Before the calendar, add a short note describing who the service is for, its duration, how the team will get in touch, and the rescheduling policy. Then insert [tb-calendar] through the Team Booking helper or enter it manually. On this shared page, keep the service filter only if visitors are choosing among several clearly named services. If there is just one consultation, limit the shortcode to that service and hide the unnecessary filter.

On the first specialist’s page, limit the calendar by provider and service. Do the same for the second specialist. When copying the page, do not forget to change only the visible heading. After publishing, check the shortcode itself and confirm that the provider parameter is different. This simple check helps prevent two polished-looking pages from pointing to the same calendar.

If the page is only for club members, restrict it to logged-in users and test access with a regular role. For an open consultation, do not require registration just to keep track of bookings. An account may make sense if customers need a list of their bookings or a limit on the number of requests, but then you will need a clear registration and support flow.

Step 4. Configure the Form and Booking Status

Add a name, email address, and one question that will help the specialist prepare for the consultation. For example: “Briefly describe what you need help with.” Do not turn the field into a questionnaire. Add a note explaining that the specialist will see the response. Then choose a confirmation mode. For this use case, automatic confirmation may work if the requested time does not need to be reviewed first. If the consultation depends on the complexity of the request, enable manual confirmation and decide in advance whether a pending request holds the slot.

With automatic confirmation, the outcome should be visible right away: the visitor receives an email, the calendar shows the confirmed booking, and the overview lists it. For manual review, display a message such as “We’ll confirm your request after reviewing it” and notify the staff member responsible. Do not use the same email for both modes: “Your booking is confirmed” would be inaccurate before a decision is made.

Test One Slot in Three Browser Sessions

Open the page as a guest in one browser, select a slot, and leave the form unfinished. In a second window, open the same day and check that the slot remains in the expected state while the first visitor has not submitted the form. After submitting the form, refresh the second window. The slot should now behave according to your chosen mode: it disappears, becomes busy, or remains available until a manual decision. In a third session, open the Team Booking admin area and find the booking.

This test shows the difference between selecting a time on the page and creating a booking. A slot is not necessarily taken just because the first visitor opened the form. If holding a slot is critical to the business, look into the pending-booking behavior supported by your version, but do not promise customers a hold that the interface does not confirm.

Step 5. Check Emails and Cancellation

After submitting the test booking, check all recipient addresses. The customer email should include the service, date, time, provider if selected, and clear instructions. The provider email should include the answer to the additional question. The administrator notification should make the booking easy to find. Check the time zone in each email. If the displayed time differs, the reason should be clear rather than looking like a mistake.

Then cancel the test booking using the method available to that person. If you use an email link, open it while signed out of the administrator account. After canceling, check the available slots, the booking overview, and the provider’s calendar again. For an event, confirm that capacity is restored; for an appointment, confirm that the time is released. If one of these does not change, do not compensate by manually editing two places. First document what you expected to change and where the flow broke.

Check the Setup Before Publishing the Page

Acceptance should not depend on one successful click. Run a small set of six checks: a standard booking, a booking in another time zone, a cancellation before the cutoff, an attempted cancellation after the cutoff, a booking for the last event place, and an attempt to exceed the limit. Not every check will apply to every service, but record the outcomes for all the features you use in the team’s checklist.

After the acceptance checks pass, move the setup to the live page. Give a small group of colleagues access for a short internal test. Only then add the link to the menu, advertising, or an email campaign. This gives the team a chance to catch unclear wording, a wrong time zone, or a missing contact before real customers start booking.

Improve the Appearance Safely Without Editing the Plugin

If the calendar blends into the theme, do not edit Team Booking files. First use the appearance settings available in your version and check the result after updates. If those are not enough, add a small amount of CSS to a child theme or to the site’s custom CSS area. The example below is a cautious custom adjustment to make the calendar container easier to see. It does not rely on undocumented PHP hooks or change booking behavior.

/* Add to the theme's custom CSS after checking the selector on a test page */
.tbk-calendar {
  max-width: 980px;
  margin: 0 auto;
}

.tbk-calendar button:focus-visible,
.tbk-calendar a:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 3px;
}

Before applying it, open your browser’s developer tools and confirm that the installed version actually uses the tbk-calendar class. If the class is different, do not guess based on someone else’s example. After adding the CSS, test the calendar with a keyboard, on a narrow screen, and with caching enabled in your theme. Rolling back is simple: remove the short snippet from the custom CSS. If the appearance does not improve or the form width changes unpredictably, restore the previous look and use the plugin’s settings instead.

When CodeCanyon Team Booking Is a Good Fit

CodeCanyon Team Booking is a good fit when your WordPress site needs more than a “Book now” button: it needs a manageable connection between services, staff, availability, and booking status. It is especially useful for a team that is ready to define time, permissions, and notification rules carefully and then maintain them through a process it can verify.

Before launch, do not try to perfect every color, field, and page. Settle the more important questions first: Does the customer see the correct time? Can they book an unavailable slot? Do they receive the right email? Can the provider see the booking? Does cancellation work properly? After that, you can improve the design and add other use cases through small, testable changes.

If your acceptance checks pass, you can download CodeCanyon Team Booking, install the archive on a copy of the site, and repeat the same checks with your theme, email delivery, and team calendars. This approach does not promise that nothing will ever go wrong; it gives you a clear way to catch issues before they affect a customer.