Gravitywiz Gravity Perks Bookings - WordPress Plugin

Guide to Setting Up Gravitywiz Gravity Perks Bookings for WordPress Bookings

Gravitywiz Gravity Perks Bookings is designed for people who already build workflows around Gravity Forms and want to turn a standard form into a full booking system, where the service, resource, date, time, capacity, notifications, dashboard, and calendar sync all work as one chain. This guide is not a promotional overview of the plugin. It focuses on the practical implementation logic: what to prepare, which settings to check first, how to build the booking form, how to test the result, and how to track down errors.

Throughout this article, the abbreviation GP Bookings is used because that is how the product is referred to in Gravity Wiz documentation. This is a plugin from the Gravity Perks family, so it does not replace Gravity Forms. Instead, it adds a booking layer on top of it: dedicated fields, schedules, statuses, booking management, and calendar connections.

This guide is written for site administrators, developers, and business owners who need more than just "install the plugin" and want a predictable booking workflow. By the end, it should be clear when Gravitywiz Gravity Perks Bookings is a good fit, where its limitations are, how not to confuse capacity with visitor count, how to validate availability, and why calendar synchronization does not always move as quickly as users expect.

What Problem GP Bookings Solves Inside Gravity Forms

The main value of the plugin is that it does not force you to move form submissions into a separate system. You continue using Gravity Forms as usual: adding name, phone, email, consent fields, pre-booking questions, payment fields, or conditional logic. GP Bookings adds four booking-specific components to that form: service, resource, occupancy, and time. When a visitor submits the form, the result is no longer just a row in entries, but a booking you can view and manage from a separate dashboard.

This is especially useful for sites where the form has already become the central point for collecting data. A beauty studio may want to ask the client for the service type, stylist, preferred time, and additional notes. A room rental business may need to track the room, duration, and guest count. A consultant may want to accept call requests, show only open time slots, and send reminders. In each of these cases, a standard form without availability logic quickly leads to manual back-and-forth, double bookings, and calendar mistakes.

GP Bookings closes that gap with a "form -> booking -> calendar -> management" model. The service defines what is being booked. The resource defines who or what delivers that service: a staff member, room, table, piece of equipment, vehicle, or venue. Availability defines when the service or resource can be booked. Capacity and occupancy help distinguish the number of simultaneous bookings from the number of units within a single booking. Pricing can be adjusted with rules if the workflow requires paid bookings.

Key principle: design the booking model first, then build the form. If you start with form fields and only try to bolt on scheduling later, it is easy to end up with a polished form that cannot properly limit open time slots.

When the Plugin Works Best

Gravitywiz Gravity Perks Bookings is a strong fit for service-based sites where the schedule is tied directly to a user submission. That includes appointments, consultations, classes, room rentals, tours, table reservations, staff-based services, group sessions, and similar workflows. In projects like these, what matters is not just the date and time, but who provides the service, how many people can be accommodated, which fields must be collected before booking, and which notifications should be sent after form submission.

Another strong use case is when different services require different forms. In standalone calendar plugins, it can be difficult to add highly specific questions without a separate form builder. In Gravity Forms, this is native behavior: you can add conditional fields, hidden parameters, different notifications, and integrations. In that setup, GP Bookings provides the scheduling layer, while Gravity Forms remains the data collection and business logic layer.

When Another Type of Solution May Be Better

The plugin may be excessive for a simple event calendar where visitors only view a schedule and do not book anything. It is also not the best first choice if you do not already use Gravity Forms and need a more self-contained booking system with a ready-made public calendar page, built-in staff handling, and minimal form setup. In that case, it makes sense to compare dedicated appointment booking solutions, which are covered in a separate section later in this guide.

One important limitation from the documentation: the Service field supports selecting only one service, and automatic resource assignment is available only when there is a linked Service field in Preselected Service mode. That does not make the product weak, but it does affect form architecture. If a visitor needs to select multiple services in a single submission, you should decide early whether the process can be split across multiple forms or whether a different approach makes more sense.

What to Check Before Installation and First Launch

Before installing, do not start with the Activate button. First, make sure the site is ready for booking logic. GP Bookings works as part of the Gravity Wiz and Gravity Forms ecosystem, so the base dependency is straightforward: Gravity Forms must already be installed, and perks are typically managed through Spellbook, Gravity Wiz's free manager plugin. If the project is already live, it is smarter to start on a copy of the site or in a staging environment, because you will be creating services, resources, test forms, notifications, and management pages.

The second check is your service structure. Write down exactly what will be booked. If this is a consultation workflow, the service might be "Initial Consultation." If it is a salon, the services might be "Haircut," "Coloring," and "Styling." If it is a room rental setup, the service might be "Room Rental," while the resources are the individual rooms. Do not mix these levels: the service answers "what the customer gets," while the resource answers "who or what provides it."

Quick Preparation Map

The third check involves calendars. If subscribing through ICS is enough, you can start with the built-in GP Bookings feed links. But if you need a direct bridge to Google Calendar, where new bookings are pushed into the calendar, changes sync back, and manual events block availability on the site, you will need Gravity Connect Google Calendar. That is a separate integration, and it is best planned as a separate implementation phase rather than a last-minute checkbox.

What Not to Do at the Start

Do not create every service, every resource, and every complex pricing rule right away. Start by building one complete path: service, resource, availability, Booking field in the form, test submission, dashboard entry, notification, and booking management. After that, replicate the model across the rest of your services. This order reduces the risk of multiplying one configuration mistake across dozens of services.

Do not set capacity to Unlimited just because you do not have an exact number yet. Most real services need limited capacity, or users may be able to book the same slot without restriction. For a group class, what you usually need is a defined slot capacity plus separate occupancy or participant count inside the booking itself.

Initial Installation and the GP Bookings Wizard

After installing and activating GP Bookings, a dedicated GP Bookings menu item appears in the WordPress sidebar. On first launch, the documentation describes a setup wizard that offers templates for faster onboarding. Choose a template based not on the attractive label, but on the model behind it: consultation, salon, rental, class, multi-day booking. Think of the template as a learning setup that helps you see how services, resources, availability, and form fields connect.

If your use case is simple, the wizard saves time. If the model is more custom, you can skip the wizard and create the first service manually. In either case, do not rush to delete the demo data until you understand how it is structured. GP Bookings includes an action for clearing sample data, with a preview of what will be deleted. That is more useful than manually hunting down related items.

What to Check Right After Activation

1. Open GP Bookings in the admin panel and make sure the menu loads without errors.
2. Create or choose a test template that closely matches your use case.
3. Open the created service and review the General, Management, Resources, Availability, and Calendar Sync tabs.
4. Open the related Gravity Forms form and confirm that the Booking field added the required components.
5. Submit a test booking from a regular browser, not from the admin panel, so you can follow the actual user path.

If the form does not submit at this stage, do not move on to more complex calendars or pricing rules. First confirm that Gravity Forms is saving the entry, that the Booking field is selected, that the service has available time slots, and that the selected resource is not blocked. The first successful test booking is the checkpoint after which it makes sense to expand the model.

Roles and Permissions

The documentation highlights separate capabilities for working with services, resources, the dashboard, and GP Bookings settings. This matters on sites where the administrator wants to give a manager access to the schedule without opening all WordPress settings. Do not assign the Administrator role just for calendar access. Check which capabilities each staff member actually needs: some only need the booking dashboard, while others may need to edit services and resources.

If you use a role management plugin, change permissions on a test user first. Open the admin panel as that manager and verify that they can see only the sections they need. Permission issues often show up indirectly: the user can see a menu item, but cannot open details, change a status, or jump to the entry.

Services and Resources: The Model People Get Wrong Most Often

In GP Bookings, the service is what the customer books. The resource is the person, object, or location through which the service is delivered. On a simple site, a service may exist without resources. For example, the site owner may handle every consultation and not offer staff selection. But as soon as you introduce stylists, rooms, equipment, vehicles, or venues, resources become a central part of the logic.

One of the plugin's strengths is that resources can be attached to multiple services. That reflects real-world workflows: one specialist may handle both initial consultations and follow-up sessions; one room may be used for several procedures; one trainer may run both private and group sessions. Each resource can also have its own availability, buffer, capacity, pricing, and calendar sync settings.

How to Choose the Right Availability Level

Availability can be defined at the service level, the resource level, or both. If a service is available only on Mondays, Wednesdays, and Fridays, and the resource does not matter, configure the windows on the service. If the service can be delivered during any business hours, but each staff member has an individual schedule, configure the resource. If both the service and the staff member or room have constraints, use both levels so only overlapping windows remain bookable.

A practical example: a massage studio sells a "Sports Massage" service. The rooms are available every day, but the massage therapist works only part of the week. If you configure availability only on the service, the visitor will see times when the therapist is not working. If you configure it only on the resource, you may lose the service-level restriction. The best model is for the service to define the service's business hours, the resource to define the therapist's personal schedule, and unavailability windows to cover vacation, lunch breaks, or room maintenance.

Capacity, Occupancy, and Quantity: Three Different Concepts

Capacity controls how many separate bookings can exist within one block. Occupancy controls the number of units inside a single booking: guests, participants, pets, seats. The Quantity field is tied to the number of bookings within a slot and can be limited by capacity. These concepts are not interchangeable.

For a one-on-one consultation, capacity is usually 1. For a group class, capacity might be 12, while occupancy reflects the number of participants in a specific submission. For a room rental, capacity may still be 1, but occupancy can show the number of guests if pricing or rules depend on that. For equipment, capacity depends on the number of units available, but sometimes it is cleaner to create each unit as a separate resource if you need to track them in the Resource Calendar.

One-Sentence Model Check

Phrase the workflow like this: "The customer books [service] with [resource] at [time], for [occupancy or quantity], under [pricing and availability rules]." If the sentence sounds natural, the model is probably correct. If you find yourself saying "service for service" or "resource on resource," the levels are mixed up.

Configuring the Service: Duration, Buffers, Lead Time, and Booking Management

The service's General tab defines booking behavior. Start with Block Size. This is the duration of the base block: minutes, hours, or a full day. Consultations usually use fixed time blocks. Rentals or lodging may need Full Day, and the documentation includes the Treat as nights rather than days option for overnight logic. If users need to choose different durations, flexible duration can be enabled based on block size.

Buffers before and after a booking protect the schedule from unrealistic back-to-back timing. A salon needs prep time between clients, a doctor may need time to complete notes, a rental workflow may need cleaning time, and a consultant may need breathing room between calls. GP Bookings lets you set the buffer in minutes, hours, or days. The documentation notes that the buffer unit follows the block size unit by default, and if you manually change the unit, the value is converted. That is convenient, but it still needs verification: after changing the time format, open Availability Preview and confirm that the orange buffer zone appears where you expect it.

Lead time defines the minimum notice required before a booking can be made. If you set it to 2 hours, the customer will not be able to book a slot that begins sooner than that. This reduces chaos when someone books five minutes before the service and the team has no time to prepare. But an overly large lead time can reduce conversions in niches where customers often book spontaneously. The best value should be based on real prep time, not habit.

Managing Reschedules and Cancellations

On the Management tab, you can allow or prevent users from rescheduling and canceling bookings through the Booking Management Page. Global settings live under GP Bookings -> Settings, but individual services can override them. For expensive consultations, you may want to block cancellations too close to the meeting. For free intro calls, you might allow rescheduling but change the status back to Pending after the move so a manager can confirm the new slot again.

The management page works through the [gpb_manage] shortcode. On its own, it does not display anyone else's bookings: it requires a unique management key in the URL. That is why your emails must include the {gpb_manage_booking_url} merge tag. If a user opens the page without a key or with an invalid key, they see the Invalid management key error. That is not a bug. It is protection against viewing someone else's booking.

Statuses and Payment Events

In GP Bookings settings, you can choose whether new bookings start as Pending or Confirmed. If the workflow is tied to payment behavior through Gravity Forms, you can automatically confirm or cancel a booking based on payment status, such as Paid or Voided. Do not turn on automatic confirmation without a full test cycle. Verify that the entry, payment status, and booking status change in the right sequence, or the customer may receive a confirmation before the process is actually ready.

Availability, Calendar Sync, and Slot Validation

Availability in GP Bookings works like an inventory of bookable blocks for services and resources. Availability windows define when a booking can be made. Unavailability windows define when it cannot: lunch breaks, vacations, maintenance, holidays, or personal conflicts. After adding windows, Availability Preview shows a color-based map: green for available, blue for occupied blocks, red for blocked, orange for buffer, and gray for time outside availability.

This visual check is mandatory. Date, time, week start, and time zone settings all come from WordPress. If the administrator is viewing the schedule in one time zone and the customer is in another, enabling display in the user's time zone can help, but it needs to be clearly communicated in the interface. GP Bookings can show an indicator when the visitor's time zone differs from the booking time zone, and it can display slots in the user's own time zone. That matters especially for international consultations.

ICS Feed or Gravity Connect Google Calendar

The built-in ICS feed links let you export bookings to external calendars and import outside events as unavailability. That is a broad and compatible option, but it does not provide instant two-way behavior. The GP Bookings documentation states this directly: ICS feeds are one-way and read-only, and external calendars refresh subscriptions on their own schedules. With Google Calendar via iCal, delays can be noticeable; Apple Calendar allows subscription refresh intervals to be adjusted; Outlook.com follows its own default timing.

Gravity Connect Google Calendar solves a different problem: a direct connection to Google Calendar. In Send Bookings & Block Availability mode, new bookings are added to the calendar, and events from Google Calendar block availability on the site. For teams that rely on personal calendars, this is usually more convenient than manual ICS subscriptions. But it is a separate component, and its presence should never be assumed implicitly. If only GP Bookings is installed, plan on ICS as the baseline level.

How to Test Sync Without Guesswork

1. Create a test booking from the public form and confirm that it appears in the GP Bookings Dashboard.
2. Check the external calendar: with ICS, account for refresh delay; with a Google Calendar integration, expect faster behavior in the GP Bookings -> Google Calendar direction.
3. Create an external calendar event during an open time slot and verify that the slot becomes unavailable on the form after sync runs.
4. Reschedule the booking in the GP Bookings panel and make sure the entry, dashboard, and calendar all reflect the same result.
5. Cancel the booking and verify that the slot becomes available again for a new user.

If the result does not match, do not change every setting at once. First identify the direction of the problem: the form is not creating a booking, the booking is not reaching the dashboard, the dashboard is not updating the calendar, the calendar is not blocking availability, or the user is seeing stale time slots because the page is cached.

Form Fields: How to Build a Clear Booking Flow

In Gravity Forms, GP Bookings adds a Booking field that acts as the entry point for booking components. Through it, you add the Service field, Resource field, Occupancy field, and Booking Time field. When those fields are present and connected correctly, form submission becomes a booking. Everything else in Gravity Forms remains a standard part of the form: name, email, phone, comments, package selection, consent, hidden values, payment fields, and conditional logic.

Do not overload the first screen of the form. The user should immediately understand what they are choosing: the service, the specialist, or the time. In a simple scenario, you can use a preselected service and show only the time. For a service catalog, you can allow manual service selection through a dropdown or radio buttons. For landing pages dedicated to a specific service, dynamic population is useful: the service can be prefilled through a URL parameter or through Gravity Forms block settings.

Service Field: Preselected Service or Manual Selection

Preselected Service mode works well when the form is dedicated to a single service. It shortens the path for the user and is required for some automatic resource assignment scenarios. Manual Selection mode is needed when one form serves multiple services. In that mode, you can choose the input type, limit the list of available services, and configure the sort order.

If you are sending visitors from a dedicated service page, do not force them to choose again what they have already chosen. Use dynamic population or a separate form with a preselected service. At the same time, remember the Gravity Forms limitation: dynamic population through PHP does not behave as expected on cached pages if caching prevents PHP from inserting current values. On a booking page, that is a practical risk, not a theoretical detail.

Resource Field: Specialist Selection, Room Selection, or Automatic Assignment

The Resource field shows resources that are available for the selected service. The modes differ in purpose. Manual Selection gives the user a choice. Fixed Resource hard-assigns a specific resource. Automatic Assignment distributes the resource using a strategy such as Round Robin, Capacity Spread, or Capacity Pack. The documentation recommends hiding the field when automatic assignment is used, because the user does not need to see the technical distribution logic.

For a team of specialists, Round Robin helps distribute bookings more evenly. For shared-capacity resources, Capacity Spread tries to maximize availability and reduce overlap. Capacity Pack, by contrast, fills one resource before moving to the next, which is useful when you want to keep other resources free. The right strategy depends on the operational goal, not on which label sounds nicer.

Booking Time Field: Display Mode and Intervals

The Booking Time field shows available dates and slots. Calendar mode is the standard calendar interface. Simple mode displays the next available slots as radio buttons and lets you limit how many options appear. For short consultations, simple mode can be faster because the user sees the nearest openings without calendar navigation. For rentals, multi-day bookings, and long-range date selection, the calendar is usually the better choice.

Time Slot Mode affects how slots overlap. Aligned with block size creates non-overlapping slots based on the service duration. If the block size is 30 minutes, the slots advance in 30-minute increments. Flexible intervals lets you show slots on a different step. That makes it possible to offer overlapping starts, such as a two-hour service that starts every hour. But this mode is not available for a service whose block size is Full day. If visitors complain that they cannot see the start time they want, check Time Slot Mode before assuming the issue is availability.

Practical Example: Consultation Booking with Specialist Selection

Let us walk through a scenario that easily maps to a salon, office, studio, or consulting business. The goal is simple: the visitor selects the service "Diagnostic Consultation," sees available slots, the system assigns one of the specialists, the client receives an email with details and a reschedule link, and the manager sees the booking in the dashboard.

Goal and Preparation

Start by preparing the list of specialists and working windows. In this example, there are two specialists: Anna and Michael. Both provide the same service, but they work on different days. We need one service, one resource type called "Consultants," and two resources. If the site already has specialist profile pages, you can later connect those pages to the form through prefilled service values or a hidden field, but the first test should be done without extra dependencies.

Setup Steps

1. In GP Bookings -> Services, create the service "Diagnostic Consultation." Set the block size, for example 60 minutes, and enable a post-meeting buffer if the manager needs time for notes.
2. Create the resource type "Consultants" and add Anna and Michael as resources. Give each one their own availability. If the specialists use personal Google Calendars, connect calendar synchronization at the resource level.
3. On the service's Resources tab, attach the "Consultants" resource type. If users should choose the specialist, keep manual selection. If balanced workload matters more, use automatic assignment and hide the resource field in the form.
4. In Availability, add the service's working windows. If availability is defined entirely by specialist schedules, do not duplicate complex windows on the service unless there is a clear reason.
5. Create a Gravity Forms form. Add Name, Email, Phone, a question about the purpose of the consultation, and the Booking field. Through the Booking field, add the Service field, Resource field, Occupancy field only if needed, and the Booking Time field.
6. In the form settings, create the client notification. Insert {gpb_booking} for a short summary and {gpb_manage_booking_url} for booking management.
7. Create the Booking Management Page, add the [gpb_manage] shortcode, and select that page in GP Bookings settings.

Validating the Result

Open the form page as a regular visitor. Select the service, specialist, and time. After submission, check the entry in Gravity Forms, then open the GP Bookings Dashboard. The booking should appear in the overview, calendar, or list. Open the booking details: they should include the date, time, status, entry link, management URL, and action history. If pricing is configured, check the pricing breakdown, because it shows which rules produced the final amount.

Check the email sent to the client. The management link should open the page with the [gpb_manage] shortcode and the unique key in the URL. Try rescheduling the booking. If the status is supposed to change to Pending after a reschedule, make sure that actually happens. Then verify whether the time changed in the dashboard and in the external calendar if synchronization is enabled.

A Detail People Often Miss

If you edit a booking through the entry details, the documentation warns that changing the Booking Time can bypass occupancy, capacity, and availability block limits. That can be useful for administrators when they need to fix a situation manually, but it is risky as a standard operating habit. After any manual reschedule, always check the calendar and resource conflicts. For day-to-day manager workflows, the GP Bookings Dashboard is the safer place to work because availability is more visible there.

Pricing, Notifications, and Merge Tags Without Unnecessary Complexity

Pricing in GP Bookings is rule-based. Each rule has conditions and actions. The condition decides when the rule applies: date range, time, day of week, quantity, occupancy, duration, or price threshold. The action decides what happens to the price: set it, add to it, subtract from it, or multiply it. You can also use multipliers by booking block, quantity, or occupants.

Start with a base price that has no conditions. The documentation explicitly notes that a rule without conditions works well as a base price. Then add one condition at a time: a weekend surcharge, an evening rate, a discount for multiple seats, or an extra charge for longer duration. After each rule, review the Rule Summary and the test booking price. Complex pricing must be auditable, or the administrator will not understand why the customer saw that amount.

Resource Pricing: Supplement or Override

A resource can have its own price. Supplement mode adds the resource price to the service price. That works well for a premium specialist, upgraded room, or equipment add-on. Override mode replaces the service price entirely. It is useful when different resources effectively represent different rate plans. Do not use override if you only want to add a small surcharge, or you may accidentally wipe out the base service pricing logic.

Notifications That Actually Matter

GP Bookings adds notification events such as Booking Created, Booking Confirmed, Booking Cancelled, Booking Upcoming, and Booking Updated. Do not enable every email at once. Users should receive a clear sequence, not a flood of similar messages.

• To the client after creation: service, resource, date, time, address or meeting format, and the booking management link.
• To the manager after creation: client details, inquiry purpose, selected resource, status, and the entry link.
• To the client before the meeting: a short reminder via Booking Upcoming, if it makes sense for the service.
• After cancellation or rescheduling: confirmation of the change, so the client does not rely on the old email.

Use merge tags for the email content. {gpb_booking} shows the service, resource, date, time, and duration. {gpb_service}, {gpb_resource}, and {gpb_datetime} let you assemble the email manually. {gpb_manage_booking_url} is required for the management link. For cleaner copy, {gpb_booking} also supports the :template modifier, where you can define the order of variables such as %SERVICE%, %RESOURCE%, %DATE%, %TIME%, %DATETIME%, and %DURATION%.

Dashboard and the Manager's Daily Workflow

The GP Bookings Dashboard is the main working screen after launch. It includes overview, calendar, resource calendar, agenda, and list views. All views can be filtered by service, resource, and booking status, while the list view can also be filtered by date range. This helps separate administrator work from manager work: administrators rarely change services, while managers need to monitor upcoming bookings, reschedules, and cancellations every day.

The Overview displays a summary: today's bookings, this week's bookings, pending and confirmed bookings, and the nearest upcoming appointments. Calendar view shows bookings in daily, weekly, or monthly format. Resource Calendar is useful for quickly checking the occupancy of specific staff members, rooms, or equipment. List view helps you quickly find bookings by status and date range.

Rescheduling a Booking Through the Calendar

The documentation describes drag and drop rescheduling in calendar-based views. While dragging, the calendar highlights available, unavailable, and out-of-availability windows. This is a good way to correct a booking quickly if the client calls and asks for a different time. But after the move, the manager should still verify the status and notifications: an automatically preserved status is not always appropriate for the business process.

Action History and Entry Connection

Booking details include the status, the View Entry button, the management URL, history, and entry details. That helps keep the original form data connected. If the client left a comment, listed preferences, or paid for the service, the manager can open the entry and see the full context. Do not treat the dashboard as a replacement for entries: it is the schedule management layer, while the entry remains the source of user-submitted data.

Safe Improvements: Calendar Styling and Small Technical Tweaks

Not every change requires code. In most cases, it is better to rely on the GP Bookings interface, Gravity Forms, and theme settings. But the GP Bookings documentation includes confirmed CSS selectors for Booking Time field states: available, unavailable, outside availability, and booked. That is a safe area for small visual enhancements because it affects how the field looks, not how availability is calculated.

The example below can be added to the theme's Additional CSS or a child theme. It makes available days more visible while keeping booked and unavailable states more subdued. Before adding it, check the form page in a test environment and avoid changing colors in a way that confuses availability.

.gpb-booking-time-picker .gpb-day--available:not(.rdp-selected) .rdp-day_button {
  border-color: #2f855a;
  background: #f0fff4;
  color: #22543d;
}

.gpb-booking-time-picker .gpb-day--booked:not(.rdp-selected) .rdp-day_button,
.gpb-booking-time-picker .gpb-day--unavailable:not(.rdp-selected) .rdp-day_button {
  opacity: 0.55;
}

.gpb-booking-time-picker .gpb-day--outside-availability:not(.rdp-selected) .rdp-day_button {
  color: #718096;
}

The validation is simple: open the form page, find an available date, a booked slot, and a day outside availability. If the colors help the user, keep them. If the theme already communicates those states well, do not add CSS just for the sake of adding CSS. Rollback is simple: remove the CSS block and clear the cache.

Deeper PHP changes through hooks should be made only for a specific need. GP Bookings includes documented hooks for availability, capacity, calendar events, statuses, pricing, and synchronization. The official snippet library includes ready-made examples such as removing lead time restrictions for administrators, adding a late booking grace period, setting dynamic capacity by time and day, and customizing calendar event title format. But snippets like these are best installed through the recommended mechanism and tested on a copy of the site. Do not paste random code from discussion threads if it is not based on current product hooks.

Troubleshooting Common GP Bookings Issues

Booking problems almost always come down to one of five areas: the service and resource model, availability windows, form field connections, calendar synchronization, or booking management. Track the cause based on symptoms instead of clicking through every setting at random.

The User Cannot See Any Open Time Slots

Symptom: the form loads, the service is selected, but the calendar is empty or the needed dates are grayed out. Check whether the service or resource has availability windows, whether they are being overridden by unavailability windows, whether lead time is too large, and whether the blocks are already occupied by existing bookings. If resources are being used, make sure the selected resource is actually available for the selected service.

Start the fix with Availability Preview. If there are no green windows there, the problem is in availability configuration, not the form. If the preview looks correct, check the Booking Time field, Service field, and Resource field. If the form page is cached, clear the cache and temporarily exclude the booking page from aggressive optimization.

Slots Do Not Overlap Even Though They Should Start More Frequently

Symptom: a two-hour service shows only 8:00, 10:00, and 12:00, but the business wants 8:00, 9:00, and 10:00. The cause is often Aligned with block size mode. Overlapping start times are created through Flexible intervals and the selected interval. But this mode does not apply to services with a Full day block size.

After changing the mode, test it on one date and confirm that the new interval does not create too many options. If the user sees dozens of slots, limit what the interface shows or revisit the duration model.

Invalid management key Error on the Management Page

Symptom: the page with [gpb_manage] opens, but it does not display the booking. It requires a URL with a unique key to work. The client email must include the {gpb_manage_booking_url} merge tag, not just a plain link to the management page. Check the notification, create a new test booking, and open the link from the email.

If the link was copied manually without the query parameter, the error is expected. If the link is complete but still does not work, check whether a caching or security plugin is modifying the query string.

The Booking Remains Active After the Entry Is Moved to Trash

Symptom: the entry is in the trash, but the slot is not freed. The documentation explains this as a safeguard: moving an entry to Trash does not permanently remove the booking, so a slot is not reopened accidentally while the submission still technically exists. To free the time slot, the entry must be permanently deleted from Trash.

If the business process requires different behavior, Gravity Wiz provides an experimental snippet for syncing bookings on entry trash and restore. Use it only after testing, because when an entry is restored, the original availability may no longer exist.

The Calendar Updates with a Delay

Symptom: an event appears in Google Calendar or Outlook with a delay, or outside busy time does not block the site slot immediately. If ICS is being used, this is a normal limitation of the feed model: different applications refresh subscriptions at different intervals. For Google Calendar, a direct integration through Gravity Connect provides a faster GP Bookings -> Google Calendar path, but events from the external calendar still do not sync as if they were a local browser-side action.

The fix depends on the goal. If you need a reliable Google-based workflow, connect Gravity Connect Google Calendar and choose the appropriate sync mode. If you need broad calendar export without a separate integration, use ICS and clearly explain the possible delay to the team.

The Date or Time Looks Wrong

Symptom: the user sees the wrong date format, the week starts on the wrong day, or emails use an unexpected format. GP Bookings uses WordPress settings for time zone, date format, time format, and week start. Check Settings -> General, then review the merge tag template in your notifications.

For international users, check the Booking Time field settings: end times, time zone indicator, and whether times are displayed in the user's time zone. Do not change everything at once. First reproduce the issue in a test browser set to a different time zone.

Compatibility with Forms, Cache, Email, and Team Workflows

GP Bookings sits at the intersection of forms, scheduling, email, and calendars. That means you need to test more than just the plugin itself. The form page must load Gravity Forms scripts correctly. Dynamically populated fields must not break because of caching. Notifications must be sent through a reliable mail setup. Managers need access to the dashboard, but not necessarily to all system settings.

Be especially careful with optimization plugins that defer or combine JavaScript. The Booking Time field is interactive, and if Gravity Forms or GP Bookings scripts load in the wrong order, users may see an empty interface or outdated data. If problems appear, temporarily disable optimization on the booking page and compare the result.

Checklist Before Publishing the Form

• Submit a test booking as a guest, not as an administrator.
• Check the form in a private window and on another device, but do not simulate a mobile workflow unless that matters for the project.
• Confirm that the entry and booking are linked, and that the booking is visible in the dashboard.
• Check the client email, the admin email, and the management link.
• Test rescheduling, cancellation, post-reschedule status, and slot release.
• Check the external calendar if you use ICS or Gravity Connect Google Calendar.

If the site is multilingual, perk interface translation can be handled using the standard WordPress translation workflow. Gravity Wiz identifies Loco Translate as one possible tool for translating Perks. But translations should not alter exact technical values, merge tags, or shortcode strings. Translate user-facing labels, not system tokens.

When Gravitywiz Gravity Perks Bookings Is the Right Choice

Gravitywiz Gravity Perks Bookings is worth using if you already have, or plan to build, a strong Gravity Forms workflow and booking needs to be part of that form. The plugin is especially effective in scenarios where custom fields, flexible logic, statuses, notifications, entry connections, resources, availability, and a manageable dashboard all matter. It is particularly useful for projects where booking is not just a standalone widget, but part of a larger business process.

Before publishing, walk through one short final path: the service and resource are modeled correctly, availability looks right in the preview, the form creates a booking, the dashboard shows the record, the email includes {gpb_manage_booking_url}, rescheduling and cancellation work, and the external calendar has been tested according to the sync method you chose. If all of that is in place, you can download Gravitywiz Gravity Perks Bookings and test the plugin in your own workflow.

Do not try to configure every edge case on day one. Start with one clear service, one resource, and one form. Then add dynamic pricing, Google Calendar, automatic assignment, extra notifications, and snippets. That order gives you more than an installed plugin. It gives you a stable booking system your manager can actually use every day.