GeoDirectory Appointments - WordPress Plugin

How to Set Up GeoDirectory Appointments for a Service Directory

GeoDirectory Appointments turns a GeoDirectory directory into a service booking system: the listing owner can manage services, schedules, and bookings, while the visitor chooses a service, time slot, contact details, and confirmation method. In this guide, we will focus not on marketing copy, but on a practical implementation workflow: what to check before installation, how to enable the required blocks, where commissions are configured, what the customer journey looks like, and how to verify that bookings actually work.

The product's defining feature is that it is built for a service marketplace inside a directory. It is not just a calendar for a single salon, and it is not a generic contact form. The plugin adds the ability to sell time-slot-based services through listings, account for platform commissions, connect GetPaid for payments, and use Wallet for payouts to owners. Because of that, setup requires more attention than a simple booking plugin: you need to align listing fields, page templates, owner blocks, customer blocks, cancellation rules, booking statuses, and email notifications.

It is also important to account for the product's current status. On the official page, the developer explicitly states that the add-on is in beta and should not be considered safe for production sites. The right approach, then, is to build a staging environment first, run through the full booking workflow, verify emails, wallet activity, cancellations, calendar behavior, and theme compatibility, and only then decide whether GeoDirectory Appointments is suitable for a live project.

What follows is structured as a working implementation map. First come the purpose and limitations, then preparation, installation, settings, a "consulting studio" example, result verification, troubleshooting, related solutions, and FAQ. Interface labels are left in English and highlighted with code because that makes them easier to match with the WordPress admin panel and GeoDirectory documentation.

What the Plugin Actually Adds to a GeoDirectory Directory

GeoDirectory already handles listings, categories, addresses, detail pages, templates, blocks, and user-submitted content. GeoDirectory Appointments adds a service-booking layer on top of that structure. In practical terms, that means a listing becomes more than just a profile page for a business, specialist, or location - it becomes a point of sale: the owner can define services, duration, pricing, availability, buffers between appointments, booking limits, and cancellation policies.

According to the official setup guide, the add-on uses GetPaid for payments and GetPaid Wallet for owner wallets. That is an important architectural detail. Bookings do not exist in isolation: once a booking is confirmed, the payment needs to go through the payment system, and the owner's portion needs to land in the wallet with the platform commission taken into account. If your site does not require payment at the time of booking, you can build a no-payment booking flow, but the marketplace logic is still designed around integration with GetPaid.

Who This Setup Is Best For

This plugin makes the most sense when the directory is already the core of the site. For example, a local platform might list salons, dentists, trainers, consultants, courses, small workshops, and neighborhood service providers. A visitor chooses a provider from the directory, reads the listing, compares reviews, and books a service right away. The listing owner does not manage the entire site - only their own part of it: services, schedule, calendar, and requests.

The real strength of GeoDirectory Appointments is the connection between the booking, the listing, and the owner. If you need dozens of providers to manage their own services inside a single directory, this product is much closer to the job than a traditional single-business calendar. That becomes especially clear in workflows involving commissions, multiple services within one listing, user dashboards, customer history, cancellations, rescheduling, and payouts.

When This Is Probably Not the Right Starting Point

If you have a simple site for a single specialist and only need to display a calendar and accept requests, GeoDirectory Appointments may be more than you need. You would have to maintain GeoDirectory, its pages, listings, custom fields, blocks, GetPaid, and Wallet even though the real task could be handled by a single booking form. For that kind of project, it is usually easier to look at Bookly, Amelia, or Simply Schedule Appointments.

The second case is a live business site where unstable behavior is not an acceptable risk. An official beta label means the product needs to be tested as a new layer of business logic - not just "the form opened," but the entire flow from service to payment, email, calendar, status, cancellation, and payout. That is normal for a marketplace project, but it is not something you should launch without a staging environment and a validation workflow.

What to Check Before Installing It on WordPress

Preparing for GeoDirectory Appointments does not start with the Install button. It starts with dependency checks. The add-on relies on GeoDirectory Core, GetPaid, and GetPaid Wallet. If the directory already has live listings, owners, custom fields, and a detail page, you first need to decide where the booking form will appear and which owners will have access to service management.

GeoDirectory recommends checking system health through GeoDirectory > Status in its documentation. For a directory that handles recurring bookings, this is especially useful: issues with the REST API, memory, HTTPS, cache, or GeoDirectory pages may show up not as a clear installation error, but as an empty calendar, broken AJAX, a failed form, or incorrect status updates.

Minimum Working Baseline

• GeoDirectory Core is installed and configured, and at least one listing type and one test listing have been created.
• The public directory pages open without 404 errors, and WordPress permalinks have been resaved after configuring GeoDirectory.
• HTTPS is enabled on the site because GeoDirectory relies on features that work noticeably worse without a secure connection.
• The WordPress REST API is not being blocked by security plugins, a firewall, or hosting settings.
• Your theme or page builder has room for GeoDirectory blocks on the listing detail page and in the user dashboard.
• If payments are required, GetPaid has already been tested with a sandbox payment or at least with a test invoice that does not involve real money.

Why It Is Better to Start on a Site Copy

A booking system changes more than just how the page looks - it changes how the listing behaves. You get new fields, blocks, statuses, emails, and financial relationships. On a site copy, you can safely enable Has Appointments, add services, test the booking form, create a test customer, and cancel an appointment without putting real owners at risk.

Practical pre-launch check: create one test listing, one test owner, and one test customer. If you cannot complete the owner workflow and the customer workflow separately, the setup is not ready for a live directory yet.

If the directory uses aggressive caching, it is worth planning exceptions in advance. Official GeoDirectory documentation says the product family was built with caching in mind, but interactive forms, user statuses, and dashboards still need to be tested separately. Pay special attention to pages where the user logs in, manages services, views the calendar, or pays for a booking.

Installing the Extension and Running the First Check

GeoDirectory provides two standard ways to install extensions: automatically through GeoDirectory > Extensions by connecting the site to AyeCode Connect, or manually by uploading the ZIP file through Plugins > Add New > Upload Plugin. This guide does not cover purchasing, licensing, or obtaining the paid version. Here, installation simply means safely activating an existing archive or available extension and immediately checking its dependencies.

After activation, the Booking Appointments documentation points to GetPaid and GetPaid Wallet as required plugins. If they are not installed or are inactive, the system should prompt you to install or activate them. Do not skip this step: without GetPaid, the payment side breaks down, and without Wallet, owners will not get the full earnings and withdrawals workflow.

Quick Post-Activation Checklist

1. Open Plugins and confirm that GeoDirectory Core, GeoDirectory Appointments, GetPaid, and GetPaid Wallet are active.
2. Go to Appointments > Settings and verify that the settings page opens without fatal errors.
3. Open the custom field settings for the required CPT, for example Places > Settings > Custom Fields, and find the fields added by the extension.
4. Open the test listing in the admin panel, enable Has Appointments, save it, and check the public listing page.
5. In the listing detail template editor, confirm that the GD > Listing Appointments Management and GD > Appointment Booking Form blocks are available.

If at this stage you do not see Appointments, or the fields or blocks have not appeared, do not move on to configuring services. First check that dependencies are active, the user role is correct, the current page template is compatible, and the error logs are clean. Bookings are built on top of these core elements, so a problem in the foundation almost always turns into "the form does not show slots" or "the owner cannot see the calendar" later on.

Configuring Commissions, Payments, and Cancellation Rules

The first real settings section after installation is Appointments > Settings. This is where you define how the platform will earn money and how bookings should behave in cases of payment, cancellation, or inactivity. The official product page lists several modes: you can collect full payment, a deposit, or no payment at the booking step; you can define a commission and a service fee; and you can create cancellation policies that owners choose for their services.

Platform Commission and Service Fee

For a marketplace, commission is not just a decorative setting. It affects how much the owner sees in their wallet, how you explain platform rules, and how you reconcile payments. Start with a simple test percentage or fixed fee, then complete one booking from start to finish and compare the booking amount, the amount in GetPaid, and the owner's credited balance.

If Pricing Manager is installed on the site, the setup guide says commissions can be defined at the price package level. That opens up a useful scenario: basic owners work under one commission structure, premium owners under another. But do not enable that level of granularity on day one. First validate the global commission, and only add package-based rules after the core payment flow is fully understood.

Cancellation Policies

A cancellation policy is both a text rule and an operational rule that the owner selects for a service. It needs to be clear to the customer before they confirm the booking. For a directory with multiple providers, it is helpful to prepare two or three standard options: for example, a flexible cancellation policy, a moderate one, and a stricter one for services with limited slot availability. Do not create ten nearly identical policies: owners will get confused, and support will have a harder time handling disputes.

Unpaid and Inactive Bookings

The product page mentions no-shows and timeouts: the system can cancel unpaid or inactive bookings after a defined period. This matters especially when a slot is blocked as soon as the customer selects it. If the payment window is too long, it can hold a time slot that another customer could have taken. If it is too short, you may get complaints from users who were delayed by bank confirmation or account registration.

Safe starting logic: for testing, set a clear timeout, create an unpaid booking, wait for the status to change, and verify that the slot becomes available again. If the slot is not released or the status is unclear to the owner, fix that process first before inviting real providers into the system.

Emails and Notification Tags

GeoDirectory Appointments adds its own emails under Appointments > Emails, and the general GeoDirectory documentation shows that emails can use replacement tags. The product changelog also mentions fixes related to email tags for booking times. That means emails should be tested with an actual booking, not by visual inspection alone: the customer should receive the correct time, service, amount, link, or instruction, and the owner should get a clear notification about the new booking.

Listing Fields and the Has Appointments Toggle

After the global settings are in place, you need to connect booking to a specific listing type. The setup guide describes the path Places > Settings > Custom Fields, where the add-on fields appear. Two key fields are Has Appointments and Appointment Cancellation Policy. The first enables booking for the listing, and the second allows the owner to choose a cancellation policy from the predefined options.

An important detail: the Has Appointments field must be available wherever the owner edits their listing. If the owner cannot see the toggle or cannot save its value, the booking form on the public page will never become functional. So do not test only the admin screen - test frontend editing too, if owners manage listings without access to the WordPress admin panel.

How to Enable Bookings Only for the Right Listings

Not every directory profile should become bookable. A restaurant may accept reservations, while an informational city service page should not. A salon may take service bookings, while a store with no schedule should not. The right approach is to enable Has Appointments only where there is an owner, clearly defined services, working hours, and someone responsible for the calendar.

• For a test CPT, enable the field in only one listing type at first.
• Create a separate category or test listing so the experiment does not get mixed into live content.
• Verify that the toggle does not break the listing submission form or conflict with required fields.
• After saving, open the detail page as a guest, as a customer, and as the owner.

How This Relates to Business Hours and Time Zone

For slot-based booking, the listing's time zone and business hours are critical. GeoDirectory documentation includes a separate article on Business Hours and Time Zone, and the Appointments changelog notes that the form logic uses the time zone from business hours with a fallback to the site time zone. The practical takeaway is simple: before you start looking for a calendar bug, check whether the listing schedule is set and whether it matches the site's time zone.

A common trap: the administrator tests a slot from one time zone, the owner has configured different business hours, and the site uses the global WordPress time zone. If availability appears "shifted," check the listing time first, then the site time, and only after that look for a plugin conflict.

Owner Blocks: Services, Calendar, and Requests

GeoDirectory Appointments comes to life through blocks. For owners, the documentation identifies two main blocks: GD > Listing Appointments Management and GD > Owner Appointments. The first is added to the listing detail page template and gives the owner management controls. The second shows all bookings across that owner's listings and can be placed in the user dashboard, a general dashboard, or on the detail page itself.

GD > Listing Appointments Management

This block shows the owner the controls for the current listing. According to the setup guide, it gives access to Manage Settings, adding and editing services, the calendar, the list of appointment requests, and booking details. The owner should clearly understand that this is not a public customer-facing form, but a management panel for their booking workflow.

Place the block so it does not interfere with the visitor experience. It is usually added to an area visible only to the listing owner or to a logged-in user with the appropriate permissions. If the block is accidentally visible to guests, it does more than clutter the interface - it creates confusion because visitors see internal controls instead of the booking path.

What to Check in the Owner Panel

• Whether the Manage Settings window opens without freezing or JavaScript errors.
• Whether a service can be added with duration, price, and availability.
• Whether the calendar works in different views, if those are enabled in the interface.
• Whether a booking created by a customer appears in the owner's list.
• Whether the booking details open correctly: customer, service, time, price, and status.

GD > Owner Appointments

This block is important when the owner manages multiple listings or needs a single overview across all services. It works well in a user dashboard. That way, the owner does not have to open each listing separately just to see what bookings came in today, which ones need attention, and which ones have already been canceled.

For a marketplace site, this is one of the most important UX elements. If the owner cannot see all requests in one place, support will quickly start getting questions like "where is my booking," "why did the customer pay but I cannot see the slot," and "how do I find an older booking." That is why the dashboard block should be tested just as carefully as the public customer form.

Customer Blocks: Booking Form and Booking History

For customers, the setup guide describes GD > Appointment Booking Form and GD > Customer Appointments. The first block handles the booking itself, and the second shows the customer's booking list. In the form, the customer chooses a service, date, and time, enters contact details and a comment, confirms the booking, and pays if required.

Inline Form or Popup

The documentation says the Appointment Booking Form can be displayed as an inline form or as a button that opens the form in a popup. Inline mode is easier to test: the form is immediately visible on the detail page, and it is easier to spot empty states, errors, and conflicts with the theme's CSS. Popup mode is useful when the listing page is already crowded with content, reviews, a gallery, and a map.

For the first test, choose inline mode. Once the workflow is working, you can switch the interface to popup and repeat the same scenario. If date selection, the payment button, or scrolling stops working in the popup, the issue is most likely a conflict with the modal, z-index, JavaScript cache, or theme styles.

Customer History and Rebooking

The Appointments changelog mentions customer booking history with tabs such as upcoming, past, awaiting payment, and canceled, as well as rebook for past bookings. For the user, this reduces the support burden: they can find their booking, understand its status, cancel it, or repeat it if that option is available in the interface.

When adding GD > Customer Appointments, check not just whether the list exists, but whether privacy is handled properly. Customers should see their own bookings, not someone else's. If the dashboard page is cached like a normal public page, personal data may display incorrectly or fail to update. That is why dashboards and checkout-like pages are usually better excluded from full page cache if their behavior is in doubt.

Practical Example: A Consultation Directory with Booking and Commission

Let us look at a concrete use case. Suppose you have a directory of specialists: therapists, career consultants, tutors, or coaches. Each specialist has a listing in GeoDirectory, can offer several services, and the platform keeps a commission on each booking. The goal is for the customer to open the specialist's profile, choose a consultation, book a slot, receive an email, and for the owner to see the booking and the credited amount in their wallet.

Goal

Build a working booking flow for one test specialist: enable booking on the listing, add the service "Initial consultation," display the form on the detail page, create a customer booking, verify the status, the email, the owner's calendar, and the wallet credit. This kind of test does not replace a full site audit, but it quickly shows whether the key connections are assembled correctly.

Preparation

• Create a test user with the listing owner role.
• Assign that user a test listing in the required CPT.
• Enable Has Appointments for the listing and select a cancellation policy.
• Make sure the owner and customer blocks are added to the correct templates or pages.
• Set up GetPaid in test mode if you are using payment or deposits.

Setup Steps

1. In Appointments > Settings, define a simple platform commission and one cancellation policy.
2. Enable Has Appointments in the listing, save it, and open the public page.
3. While logged in as the owner, open the GD > Listing Appointments Management block and add a service with a clear duration.
4. Set availability so there is at least one open slot within the next few days.
5. While logged in as the customer, select the service in GD > Appointment Booking Form, choose the date and time, fill in the contact details, and confirm the booking.
6. If payment is enabled, complete the test payment or verify the awaiting payment scenario.
7. Switch back to the owner account and open the calendar, the request list, and the booking details.
8. As the administrator, check Appointments > Bookings and the emails under Appointments > Emails.

Verifying the Result

A working result looks like this: the customer sees a confirmation and the booking in their dashboard, the owner sees it in the calendar and list, the administrator sees it in the general admin view, the slot is no longer offered as available for that same time, and the financial data matches the selected commission structure. If Wallet is being used, the owner should see the credited amount according to the logic defined in the GetPaid and Appointments settings.

One detail people often miss: test cancellation and rescheduling, not just booking creation. The Appointments changelog includes changes related to reschedule, cancel, no-show, group bookings, and reminder emails, but on your site those features still need to survive your theme, cache, roles, emails, and payment settings. One successful booking does not prove that the entire operational chain is ready.

How to Verify the Setup After Configuration

GeoDirectory Appointments should be tested by role. The administrator sees the global settings and all bookings. The owner sees their services, calendar, requests, and wallet. The customer sees the form, confirmation, and their history. A guest sees only the public side. If you blur those roles together in one browser session, it becomes very easy to mistake a cached state or admin access for normal site behavior.

Verification Matrix

Separate Payment Verification

If you are collecting payment or a deposit, do not stop at the message "payment succeeded." Check the invoice or transaction in GetPaid, the booking status, the owner credit, the platform commission, and cancellation behavior. GetPaid is designed to act as a payment system for other plugins, but that does not remove the need to verify the specific Appointments integration on your own site.

For sites that rely on email notifications, it is useful to temporarily install an email logging plugin recommended in GeoDirectory documentation as a troubleshooting tool. That lets you see whether the email was sent, what subject line was generated, and which tags were replaced with real data. This matters especially for appointment start and end times, the amount, status, and contact details.

Staff, Group Bookings, Reminders, and Online Meetings

Basic service booking is only the first layer of Appointments. The add-on changelog introduced features that move it closer to a real service marketplace: staff schedule, group bookings for classes and tours, Zoom integration, Google Calendar two-way sync per staff member, reminder emails, no-show status, and performance reports. These features should not all be enabled at once in the first round of testing. They are better treated as phase two, after you have already proven that one owner, one service, and one customer can complete the full workflow without failures.

When You Need a Staff Schedule

A staff schedule is needed when one listing represents a business with multiple specialists. For example, a massage studio may have three therapists, a training center may have several instructors, and a clinic may have doctors with different schedules. In that situation, a simple listing-level schedule is no longer enough: the customer needs to choose not just a service, but also either a specific staff member's available time or an open slot within the team.

Before enabling a staff-based workflow, map out the logic in simple terms: which services each staff member performs, where their working hours overlap, whether the customer can choose the specialist, what happens during time off, and who receives the notification. If you skip that step, the interface may show slots, but the owner will not understand who is actually supposed to serve the customer. For testing, create two staff members with different availability windows and one service, then confirm that a booked slot for one staff member does not block the other unless your business logic requires it.

Group Bookings and Classes

Group bookings are useful for classes, tours, workshops, group consultations, and any service where one time slot can be shared by multiple customers. This is a fundamentally different type of verification: you need to validate not just time availability, but capacity. One customer should not consume an entire class if multiple seats are available, and the last open spot should correctly move the slot into an unavailable state.

A practical group-booking test looks like this: create a service with limited capacity, book it once as the first customer, then again as the second and third customer until the limit is reached. After each booking, check how availability changes on the public form. If payments are enabled, separately test pending or awaiting payment states, because an unpaid seat may temporarily hold capacity and block other customers.

Online Meetings and Calendar Sync

Zoom integration and Google Calendar sync per staff member sound like a convenient finishing touch, but they depend on external services, access permissions, and solid calendar discipline. First verify that the appointment itself is created inside the site. Then connect the online meeting and calendar for one staff member. If you connect multiple staff profiles, different calendars, and notifications all at once, it will be difficult to tell where the chain broke if something goes wrong.

For online consultations, two outcomes matter most: the customer receives clear instructions, and the owner sees the meeting in their working calendar. Check the customer email, the owner email, the appointment details, and the calendar event. If the meeting link should appear only after confirmation or payment, create a separate test for each status. Do not send real customers emails with unconfirmed meeting links until you have seen the full email in a test environment.

Reminders, No-Show, and Reports

Reminder emails and no-show status become useful once the directory is handling regular bookings. Reminders reduce missed appointments, and no-show helps owners and administrators distinguish between canceled, unpaid, and actually missed appointments. But those statuses need to be clear to support staff: if an owner sees "no-show," they need to know who sets that status, whether it can be changed, and whether it affects payout.

Performance reports with revenue, activity, and leaderboard KPIs are valuable for platform administrators, but they only mean something if the financial model is reliable. Before you rely on reports, manually reconcile several test bookings: the customer amount, the commission, the service fee, the owner credit, the cancellation flow, and the refund flow. A report should confirm operational reality, not replace primary payment verification.

Recommended feature rollout order: first one service and one slot, then staff schedule, then group bookings, then reminders, online meetings, and reports. That order preserves cause-and-effect troubleshooting: if something breaks, you know which new feature was added most recently.

Compatibility Details for Themes, Blocks, and Cache

GeoDirectory Appointments works inside WordPress blocks and GeoDirectory templates. Because of that, the typical issue does not look like "the plugin is broken," but rather like a local placement conflict: the block was added to the wrong template, the theme overrode the styles, the popup opened behind the header, the cache served an outdated state, or the dashboard did not refresh after booking.

Block Editor and Listing Templates

Start by placing blocks in the simplest possible template, without complex tabs, accordions, or nested builder containers. Once the form works, move it into its final location. If you begin with a polished but complicated layout, it becomes much harder to determine what is actually broken: the booking block itself, the GeoDirectory template, the theme tab, or the builder scripts.

There is a separate Elementor context here: the Appointments changelog mentions a fix for a booking form conflict with Elementor and the addition of an Elementor booking form widget. That does not mean every Elementor layout is automatically safe. Test the form in the real template, especially if you use popup behavior, sticky sections, lazy loading, JavaScript optimization, or hidden tabs.

Cache and Personalized Pages

Official GeoDirectory documentation mentions compatibility with caching solutions, including page cache, server-side cache, and object cache. But booking workflows introduce personal data and dynamic statuses. That is why dashboard pages, wallet pages, the checkout flow, appointment history, and forms that require authentication should be tested in an incognito window, under different roles, and after clearing cache.

Practical rule: if a problem disappears after clearing the cache or when using a private window, do not immediately change Appointments settings. First check exclusions for dashboard pages, checkout, GetPaid endpoints, and dynamic GeoDirectory templates.

Safe Appearance Customization

Do not edit plugin files, theme files, or GeoDirectory Core directly. If you need to change spacing, form width, or button appearance, use the theme settings, the block editor, your own child style, or a safe custom CSS field. Before making any CSS change, open your browser's developer tools and make sure you are targeting the wrapper class of your actual template, not some unrelated global button class.

This guide intentionally does not include code snippets for Appointments: the official product documentation does not confirm stable public hooks specifically for this beta add-on. For a production site, it is better to rely on documented settings, blocks, and templates first. If behavior customization becomes necessary, do it only after reviewing the product code or getting confirmation from support.

Common Problems and Troubleshooting

Troubleshooting is best done from simple to complex: dependencies, listing fields, blocks, user role, service availability, cache, emails, and payments. Below are issues that are especially typical for the GeoDirectory Appointments, GeoDirectory, GetPaid, and WordPress blocks stack.

The Booking Form Does Not Appear on the Listing Page

Symptom: the public page opens, but the customer does not see the booking form or only sees an empty area. Possible causes include the GD > Appointment Booking Form block not being added to the template, Has Appointments not being enabled for the listing, no service having been created, the user viewing the wrong CPT, or the theme hiding the block inside a tab.

First check the listing itself: is the toggle enabled, has it been saved, is there a service, and is availability set? Then open the listing detail template and make sure the block actually belongs to that CPT. If the block is there, temporarily move it higher on the page and disable complex builder containers. If the form appears, the issue is in the layout, not in Appointments.

There Are No Available Slots in the Calendar

Symptom: the service exists and the form opens, but no dates are available. Common causes include no schedule being set, the service duration not fitting into the working window, the owner blocking certain days, the listing time zone differing from the site time zone, the slot already being occupied by a test booking, or the cache serving an old state.

Start the fix with a short test service and a wide availability window. Remove buffers, create one obvious slot, save, and open the form in a private window. If the slot appears, add restrictions back gradually: buffer time, working days, staff schedule, blocked dates, and cancellation rules.

The Owner Cannot See Their Bookings

Symptom: the customer created a booking, the administrator can see it, but the owner cannot. Possible causes include the listing being assigned to another user, the GD > Owner Appointments block not being added to the dashboard, the owner viewing the wrong listing, the user role lacking management access, or the cached dashboard showing an old page.

Check the listing author and the owner using a separate account. Then open the dashboard page without cache. If one owner has multiple listings, check both the block on the detail page and the general Owner Appointments block. When the booking is visible to the administrator but not to the owner, the issue is almost always the listing owner assignment, block placement, or personalized cache.

Emails Are Not Arriving or Are Missing Important Data

Symptom: the booking is created, but the customer or owner does not receive an email, or the email is missing the time, service, or amount. Possible causes include emails being disabled in Appointments > Emails, the server not sending mail, SMTP being configured incorrectly, replacement tags not being substituted, the email landing in spam, or the template having been modified without testing.

Install an email log on the test site, create a new booking, and check whether the email was generated. If the email is in the log, the problem is more likely deliverability. If there is no email, check the Appointments settings and the general GeoDirectory email settings. If the email exists but the data fields are empty, restore the default template and reapply changes one at a time.

Payment Went Through, but the Owner's Wallet Was Not Updated

Symptom: the customer paid, the administrator sees the payment, but the owner does not see the credited amount, or the amount is incorrect. The cause may be the booking status, commission settings, Wallet, GetPaid, disabled withdrawals, or the fact that the test payment never reached the state at which Appointments credits the owner.

First compare three places: the record in Appointments > Bookings, the payment or invoice in GetPaid, and the wallet transaction. Then verify that GetPaid Wallet is active and that the required wallet settings are enabled. Do not change the commission before reconciling statuses, otherwise you will make troubleshooting harder and lose track of which operation caused the mismatch.

The Form Becomes Unstable After Enabling Popup Mode

Symptom: the inline form was working, but the popup does not open, appears behind the header, does not scroll, or does not allow date selection. Most often this is a JavaScript, z-index, script optimization, Elementor/theme, or modal conflict. Switch back to inline mode and confirm that the base flow still works. Then disable JavaScript optimization for the listing page or exclude Appointments scripts from deferred loading if your caching plugin supports that setting.

What you should roll back is not the entire GeoDirectory Appointments setup, but the specific contested setting: popup mode, script combining, moving the block into a complex container, a hidden tab, or dashboard caching. That approach preserves the working foundation and reveals the actual conflict faster.

When GeoDirectory Appointments Is a Good Fit

This plugin is worth considering if you already have, or plan to build, a directory where different owners manage their own services. It is especially relevant for platforms where listings, local search, provider pages, commissions, wallets, booking history, and scalable vendor growth all matter. In that kind of setup, a standalone booking plugin is often too isolated: it accepts bookings, but it does not understand directory logic.

GeoDirectory Appointments is less compelling if booking is the site's only job. For a solo specialist, a small studio, or a simple consultation form, it usually makes more sense to start with a more mature appointment plugin with fewer dependencies. The beta status should not be ignored either: the product may be promising, but before a live launch it requires a staging environment, validation bookings, email checks, payment checks, cancellation checks, calendar checks, role checks, and cache checks.

If, after testing, you can see that the GeoDirectory, GetPaid, Wallet, and Appointments stack matches your exact directory model, you can download the installation package and continue testing on a site copy. For a live project, a reasonable rollout sequence looks like this: first one test CPT, one owner, one service, and one payment scenario; then multiple owners; then cancellation policies, staff schedule, reminders, group bookings, and reports.

Final Safe Rollout Model

GeoDirectory Appointments should be rolled out as an operational module of the directory, not as a shiny "Book now" button. First verify GeoDirectory Core, HTTPS, the REST API, pages, and cache. Then activate the dependencies, configure commissions and cancellation policies, enable Has Appointments on a test listing, add the owner and customer blocks, create a service, complete a booking, and verify emails, statuses, calendar behavior, payments, and wallet activity.

The most reliable strategy is to move from one test listing to several real providers. Do not enable every feature mentioned in the changelog all at once: Zoom, Google Calendar sync, reminders, group bookings, no-show, and reports only become useful after the basic customer and owner flow is stable. Otherwise, you may end up with many features but no clear way to tell which one is breaking the result.

If your project really is a service directory where owners need to manage services, slots, and requests, GeoDirectory Appointments can be a logical extension of GeoDirectory. If the task is simpler, a standalone booking plugin is usually the better choice. In both cases, the decision should be made only after a real test booking, because that is what shows whether the product fits not some abstract website, but your actual operating model.