CodeCanyon Amelia - WordPress Plugin

Guide to Setting Up and Using CodeCanyon Amelia for Client Bookings in WordPress

CodeCanyon Amelia is best thought of not as a simple calendar widget, but as a full booking system inside WordPress. In this guide, we will walk through how to prepare your site, build a workable structure for services and staff, place the booking form on a page, configure notifications, payments, and self-service panels, and verify that a client can actually complete the full flow from selecting a service to receiving a confirmed booking.

This guide does not repeat the product's short description. Instead, it gives you a practical roadmap: what to create in the admin panel, which settings to enable with caution, where time availability most often breaks, why notifications may fail to send, how to connect Amelia to an external calendar, and when the plugin is better replaced with a more specialized solution.

This guide is written for a service business owner, WordPress administrator, or implementation specialist setting up bookings for a salon, clinic, consulting business, classes, repair service, time-based rentals, online meetings, or events. If the plugin is already installed, you can jump straight to the sections on service structure, the booking form, and result validation. If you are still planning the installation, start with preparation - it will save time during troubleshooting later.

What Problem Amelia Solves and Where It Works Best

Amelia solves the point where a basic contact form is no longer enough. Instead of simply submitting an inquiry, the client selects a service, a staff member or available time slot, enters their details, receives confirmation, and the administrator sees the booking in both the calendar and the bookings list. Within this process, the plugin connects several entities: services, categories, staff, working hours, service locations, statuses, notifications, payments, external calendars, and the format of the public booking form.

Amelia's strongest use case is any business that needs to manage real time availability. For example, a cosmetologist sees clients on different days, a trainer runs both individual and group sessions, a clinic distributes appointments among specialists, or a school sells consultations and webinars. In those situations, it is not enough to show an attractive calendar - you also need to prevent clients from choosing occupied slots, store booking data, send reminders, and give staff access to their own schedules.

The plugin is especially useful when a site has multiple staff members or multiple service types. Amelia also works for a solo specialist, but some of its features may be more than you need at first: the employee panel, roles, advanced availability rules, integrations, packages, booking cart, and events. That is not a drawback, but it is something to account for. The simpler the business process, the more carefully you should disable unnecessary elements so the form does not become harder for the client to use.

Who the Plugin Usually Fits

• Service businesses where booking depends on the staff member, service duration, business hours, and breaks.
• Salons, studios, clinics, teachers, consultants, and trainers who need booking without manual back-and-forth messages.
• Websites where it is important to accept payment or at least record the payment method as part of the booking flow.
• Teams that need an employee panel or customer panel without granting full access to the WordPress admin area.
• Projects that benefit from notifications, reminders, external calendars, online meetings, and custom form fields.

When You Should Consider Another Solution

Amelia may be excessive if all you need is a simple contact form without time selection. It is also not always the best fit for complex day-based rentals, hotel-style booking scenarios, heavy WooCommerce product logic, or workflows where the client suggests several time options and a manager manually selects one. Amelia is built around available time slots and confirmable bookings. If your process looks more like negotiation, bidding, a long intake form, or a highly custom order, the booking form is better supported by a CRM, form builder, or a more specialized solution.

The key check before choosing it: describe one typical booking as a chain: "service - staff member - duration - time - client details - confirmation - notification." If that chain feels natural, Amelia will most likely fit. If half the steps require exceptions and manual coordination, it is better to simplify the process first or choose another tool.

What to Check Before Installing It on a Live Site

Before installation, it is important to understand not just technical compatibility, but the future booking model itself. Most problems appear not because of the installation process, but because the administrator starts creating services without a clear map of staff, schedules, and confirmation rules. The result is a client seeing an empty calendar, a staff member receiving unnecessary notifications, and the administrator not understanding why available time is not showing.

Technical Preparation

Make sure the site is up to date, a backup is available, and critical caching, security, payment, and page builder plugins are not blocking dynamic forms. For the booking page, it is best to prepare an exclusion from aggressive caching in advance if your caching plugin can exclude specific URLs or disable script optimization for selected pages. The booking form needs to behave like an interactive application, so overly aggressive minification, delayed loading of all scripts, or HTML caching can interfere with it.

Also check WordPress email delivery separately. Amelia can configure notification templates, but a nicely designed email does not guarantee delivery by itself. If the site has been sending mail through the default WordPress function for a long time and some messages land in spam, set up a proper mail transport before you start testing bookings.

Operational Preparation

Make a list of services and decide who provides them. In Amelia, bookable services are tied to staff members, so service appointments require at least one staff member. Even if the business is run by one person, that person's profile is still needed as the source of schedule and availability. Events work differently: an event can exist without being assigned to a staff member, so a webinar, workshop, or group event can be planned separately.

Before installation, it helps to lock down decisions like these:

• Which services will be available on the website and which will remain for internal admin booking only.
• The duration of each service and whether buffer time is needed before or after the appointment.
• Whether you need multiple staff members, multiple locations, days off, special days, and client capacity limits.
• Whether a booking should be confirmed immediately or first go into a pending state.
• Which notifications are required: to the client, the staff member, the administrator, a pre-visit reminder, or a follow-up message after the service.
• Whether payment needs to be accepted on the site or payment on arrival is enough.

This preparation may seem tedious, but it is exactly what determines the quality of the final setup. If you do not decide in advance who provides a service and when they are available, the booking form will not be able to display valid time slots.

Installation and the First Check After Activation

Installing CodeCanyon Amelia works like installing a standard WordPress plugin: upload the ZIP archive through the Plugins section, activate the plugin, and make sure an Amelia area appears in the left-hand menu. Do not describe the purchase process or license acquisition in instructions meant for a site editor - that is a separate administrative topic. For implementation, it matters more to verify that the plugin activated correctly, the menu opens, and the main admin pages load without errors.

After activation, do not rush to place the form on a public page right away. First, open Amelia's main sections and make sure the interface shows pages for staff, services, bookings, calendar, settings, notifications, and customization. If any page fails to load, check the browser console, temporarily disable script optimization in the admin area, and confirm that the user role has administrator permissions.

Minimum Check for a Fresh Installation

1. Open the staff section and create a test profile if the plugin shows an empty state.
2. Create a service category, then one test service with a clear duration and either a price or payment-on-site option.
3. Assign the service to a staff member, because without that connection a service appointment will not be available to the client.
4. Check the staff member's working hours and make sure at least one upcoming day contains available time.
5. Create a draft WordPress page and add the booking form using a block, page builder widget, or shortcode.
6. Open the page as a visitor and check whether service, date, and time selection appear.

If the form is empty at this stage, do not move on to payments or integrations. First fix the basic "staff member - service - working hours" connection. Everything else is built on top of it.

Staff, Services, and Schedule as the Core of Amelia

The most important part of setup is not the button color or the email wording, but the availability model. In Amelia, the service defines what the client is booking, the staff member defines who performs it, and the schedule determines when the booking is possible. If one of these parts is missing, the form may look fine while still showing no available time.

The Staff Member as the Source of Availability

In Amelia, a staff member is not necessarily a separate WordPress user. It is the profile of the person providing the service: name, contact details, services, working hours, breaks, days off, special days, locations, and calendar integrations. For a small business, you can create one staff member and hide staff selection in the public form. According to Amelia's documentation, when there is only one staff member, the provider selection step may not be shown to the client, which makes the form simpler.

If you have multiple staff members, do not copy the same schedule to everyone without checking it. Each person may have different services, locations, breaks, and restrictions. This is especially important for salons: a nail technician, cosmetologist, and administrator may work in the same room, but provide different services and follow different time windows. For online consultations, it is important to connect the staff member to the correct external calendar and video meeting service.

The Service as What the Client Buys or Books

A service should be clear to the client and manageable for the administrator. Do not create one generic service called "Consultation" if the duration, price, staff member, and preparation differ. It is better to create several services with precise names and durations. If the client needs to choose an extra option, use extras or custom fields when they fit the use case.

Within each service, check three things: duration, assigned staff members, and capacity rules. If the maximum capacity is greater than one, the booking becomes a group booking. At that point, you need to decide whether one client should occupy the entire slot or whether multiple clients can join it up to the maximum limit. That is useful for classes and training sessions, but usually not for one-on-one consultations.

Schedule, Special Days, and Locations

In Amelia, schedule setup works best from general to specific. First define regular working hours, then add breaks, then days off and special days. If a staff member works in multiple places, check the locations carefully: the service must be available where the staff member actually works. Location mistakes often show up as "no available time," when the real issue is that the selected staff member is not connected to the required location.

Quick takeaway: if Amelia is not showing time slots, start troubleshooting with the entities, not the form design. Availability only appears where the service, staff member, schedule, and booking rules intersect.

Form Design, Text, and Mobile Validation

Amelia has a separate Customize section where you can configure the appearance and text for different forms: step-by-step booking, catalog, event calendar, event list, Customer Panel, and Employee Panel. This is not just cosmetic. Form design affects whether the client understands what they are choosing, where they are in the process, what the next step is, and what counts as a completed booking.

Start with the Main Form

If the site uses several form types, start by configuring the step-by-step booking form. It usually sets the overall visual language: the main button color, background, active states, text contrast, input fields, and warnings. Then carry that logic over to the catalog, events, and panels. Do not try to make every form look completely different. A visitor should recognize the same booking service whether they open a service booking page or the customer panel on a different page.

Check contrast carefully. A beautiful brand color may be hard to read on a button if the text is too light or the background tone is too similar. For a business, this is not a small detail: if the client cannot clearly see the active button or tell which slot is selected, they may leave before confirming the booking.

Labels and System Messages

Amelia lets you change labels and text inside forms. Use that to remove internal terminology, but do not hide important states. If a booking is pending, the client should understand what that means. If payment is required later through a link, the notification should explain that the booking was created but payment is still needed. If the client can cancel or reschedule a visit through the panel, the button text should be understandable without additional admin instructions.

Do not translate exact system concepts loosely if doing so changes the meaning. For example, the "Pending" status in the admin panel can be explained to the client as "awaiting confirmation," but inside the status settings it matters which exact system status is being used. In an article and in admin documentation, exact UI labels like that are best left in code, while user-facing text should be written in clear, natural language.

Mobile Form as a Required Test

Most clients book from a phone, even if the administrator configures the site on a large monitor. That is why after every major design change, you should test the form on a mobile screen: service selection, calendar, phone input, required custom fields, payment method, confirmation button, and the successful booking screen. Pay special attention to long service names and staff names - they can break cards, wrap across multiple lines, or cover important elements.

If the form feels overloaded, simplify the flow before shrinking the font. Filter the shortcode to one category, hide staff selection where it is unnecessary, remove optional fields, shorten service names, and move explanations to the page next to the form. Tiny text does not solve the problem - it only makes the booking less accessible.

The Booking Form on a Page: Blocks, Shortcodes, and Filtering

Once the basic data is in place, the form needs to be placed on a WordPress page. Amelia supports insertion through Gutenberg, Elementor, Divi, and shortcodes. To the user, the difference is invisible: they see the booking steps, choose a service and time, enter their details, and confirm the booking. For the administrator, the insertion method matters because it determines where the form lives and how easily it can be filtered.

When to Use the Full Booking Wizard

The main use case is the step-by-step form. It works well for a "Book Now" page where the client should complete the whole flow: choose a service, date, time, details, payment, or confirmation. For that form, you can use the [ameliastepbooking] shortcode or the corresponding editor block. Amelia's documentation also describes parameters that restrict the form to a specific category, service, staff member, or location.

Filtering is useful when the site has dedicated service pages. For example, on an "Initial Consultation" page, it is better to show only one service instead of the entire catalog. That keeps the visitor focused and gives the administrator a more predictable booking path.

[ameliastepbooking service=5]
[ameliastepbooking category=3]
[ameliastepbooking employee=2 location=1]

Use examples like these as a model, not as ready-made values. Service, category, staff, and location IDs must come from your own installation. After inserting the form, test the page as a visitor, because an administrator may see more data than a regular user.

Catalog, Events, and Panels

If the client needs to browse a set of services first, the catalog is more appropriate. If the use case is event-based, use event forms rather than trying to imitate an event with a regular service. For returning clients and staff, Amelia offers separate panels that are displayed on standard WordPress pages. That allows a client to review bookings, reschedule an upcoming visit, or open a package, while a staff member can manage their schedule without full access to the admin area.

What to Check After Inserting the Form

Do not just check that the form loads - test the entire client journey. Open the page as a guest, select a service, date, and time, fill out the fields, confirm the booking, and see whether it appears in the bookings section. If notifications are enabled, check the emails. If payment is enabled, use the provider's test mode first when available, and do not mix test verification with real client payments.

Practical rule: one page - one clear booking scenario. If you show all categories, all staff, and all event options on a service page, it becomes harder for the client to complete the booking.

Post-Installation Settings: What to Enable Right Away and What to Leave for Later

Amelia's settings area is extensive, so it is best to work in layers. Start by enabling only what is necessary for booking to work at all: general settings, schedule, notifications, form behavior, and basic payment. Then connect external calendars, online meetings, SMS, WhatsApp, roles, panels, custom fields, packages, the cart, and advanced rules. This order makes troubleshooting much easier: if everything is enabled on day one, it becomes hard to tell which integration broke the flow.

General Settings and Booking Statuses

Check the interface language, time format, WordPress time zone, and status rules. If bookings need to be approved by an administrator, use a pending status and configure notifications so the client understands the booking is not final yet. If the business uses automatic booking confirmation, a confirmed status can be applied right away - but only after you have verified schedule logic, external calendars, and capacity restrictions.

Do not mix two different processes in the same form. For example, if some services require manual approval while others should be confirmed automatically after payment, configure the services and notifications so the client sees the correct status and does not receive conflicting emails.

Notifications: Templates, Placeholders, and Delivery

Amelia supports notifications for clients and staff across different events: new booking, pending booking, cancellation, rescheduling, reminders, post-visit messages, and other scenarios. Templates can be filled with placeholders so the email automatically inserts the service, date, time, staff member, location, and additional details.

Start with the minimum set: a confirmation to the client, a notification to the staff member, and an admin message if needed. Then add reminders and follow-up emails. For SMS and WhatsApp, do not copy long email templates - short messages are easier to read and less dependent on channel limitations. For WhatsApp, keep in mind that templates must be prepared and approved on the platform side first, and Amelia then uses the imported templates inside its editor.

Payments and WooCommerce

In the payment settings, check the currency, price format, default payment method, and available providers. Amelia supports on-site payment and several online providers, as well as WooCommerce integration. If you use WooCommerce, it is important to understand that the booking then starts depending on order status, checkout settings, taxes, and the store's available payment methods. That is convenient when the site is already built around WooCommerce, but it also makes troubleshooting more complex.

First verify bookings without complex payment logic, then enable online payment, and only after that move on to WooCommerce-based scenarios. If payment succeeds but the booking keeps the wrong status, look at the connection between Amelia statuses and WooCommerce order statuses, not just the payment provider settings.

External Calendars and Online Meetings

Integration with Google Calendar, Outlook, Zoom, Google Meet, and similar services is useful, but it introduces external sources of failure. In calendars, Busy events are especially important because they can block available slots in Amelia. If a staff member connects multiple calendars, verify which calendar creates events and which ones are only checked for occupancy. Amelia's documentation separately describes the ability to check multiple calendars for a staff member, so do not limit yourself to one shared account if the team works individually.

Safe sequence: first make booking work without any external calendar, then connect one staff member's calendar, create a test booking, and verify that an event is created there. After that, add a Busy event to the calendar and confirm that the matching slot disappears from the public form.

Events, Packages, Cart, and Group Bookings

Amelia is often installed for standard service bookings, but in more complex projects, related scenarios appear quickly: workshops, courses, packages of sessions, several bookings in one purchase, waiting lists, and shared group slots. These features should not be enabled "just in case." They are useful when the business process actually differs from a simple appointment with a staff member.

When a Service Becomes an Event

A regular service answers the question, "When can the client book time with a provider?" An event answers a different question: "When does the event take place, and how many participants can attend?" That is why a webinar, course, workshop, group lecture, or open house is easier to handle as an event. With an event, you can manage dates, capacity, registration, tickets, and recurrence, and a staff member is not always required.

Do not create an event as a service just because it is faster. It may work in the short term, but it causes issues later: reports, notifications, rescheduling, capacity, and front-end display start behaving differently from what participants expect. If the event has a specific date, a participant list, and a seat limit, use event logic.

Service Packages

Packages are useful when the client buys or books a set of sessions: a consultation series, a training plan, a treatment package, or several classes. In that model, it is important to explain how many meetings are included, how the client selects dates, and what happens to unused sessions. In the admin panel, do not just check the package price - also verify which services are included, who provides them, and how the client sees remaining bookings in the panel.

A package should not replace a regular service if the client is booking only once. Its purpose is to manage a series. If you use packages, make sure to test the Customer Panel: the client should understand how many sessions are left, which dates are already selected, and whether a single meeting can be rescheduled.

Multiple Bookings in the Cart

The cart in Amelia allows a client to add multiple appointment bookings to one flow and confirm them together. This is useful for a salon where a visitor chooses several procedures, or for a studio where the client books several consultations in a row. But the cart has limitations: according to the documentation, it applies to appointment scenarios and does not work for events, recurring appointments, or packages. So do not plan the cart as a universal mechanism for the entire catalog.

If you enable the cart, test custom fields separately. When different services require different fields, the client may see them together on the details step. That is normal, but the form needs to stay clear: labels should explain which question belongs to which service. In notifications, use the dedicated placeholders for cart booking details, otherwise the client and staff member may receive an incomplete list.

Group Bookings and Capacity

A group booking happens when a service allows more than one participant in the same slot. For classes and sessions, that is convenient: several clients can occupy the same time until the limit is reached. But for individual services, this setting can accidentally open the door to double-booking. Check the minimum and maximum capacity, how the booking behaves below the minimum capacity, and whether the slot closes after the first booking or stays open to additional clients.

Practical guide: if the client is buying access to a specific event, look at events. If the client is buying a series of sessions, look at packages. If the client is adding several different visits in one pass, look at the cart. If several clients share one service slot, configure group capacity.

Custom Fields, Customer Panel, and Employee Panel

After the basic setup, the next question is often how to collect extra client data and how to give participants in the process self-service access to bookings. In Amelia, this is handled through custom fields, the Customer Panel, and the Employee Panel. These features are especially important for clinics, schools, studios, and teams where the administrator should not have to manually forward every detail.

Custom Fields Without Overloading the Form

Custom fields let you add extra questions to a booking: a client comment, experience level, project link, consent checkbox, option selection, file upload, or address. Amelia's documentation distinguishes between fields tied to a specific booking and fields that belong to the customer profile. That matters because information needed for one visit should not always become a permanent part of the client's profile.

Do not turn the booking form into a long questionnaire. The more required fields you add, the greater the chance the client will not complete the booking. Make only those fields required that are essential for the staff member to deliver the service. For everything else, it is better to use optional fields or a follow-up email after confirmation.

Be Careful with Files and Addresses

If you enable file uploads, check the allowed formats and the storage folder. According to Amelia's documentation, attachments may be saved in the plugin's uploads directory, and the path can be changed. For medical, legal, or otherwise sensitive data, that is not enough by itself - you also need to evaluate your storage policy, staff access, and backup handling. The address field may depend on the Google Maps API, so without a correct key it may behave like a regular text input.

Customer Panel

The Customer Panel is useful when the client should be able to view future and past bookings, reschedule appointments, open packages, see payments, or update personal details on their own. The panel is displayed on a standard WordPress page through a block or shortcode, and its URL is then specified in the role and customer permissions settings. In notifications, it is important to use the correct panel-link placeholder, otherwise the client will not land on the right screen.

The customer panel reduces manual workload, but it needs careful rules. Decide how long before the appointment a client is allowed to reschedule or cancel, and which actions remain available to the client versus only to the administrator. If the business uses prepayments or service packages, test the panel with real scenarios: a standard booking, a paid booking, a package, a reschedule, and a cancellation.

Employee Panel

The Employee Panel allows staff members to work with schedules, events, services, and bookings without access to the entire WordPress admin area. Amelia's documentation emphasizes that the employee signs in with a password, and access depends on role and permission settings. This is convenient for a team, but it is risky to enable everything indiscriminately. If a staff member only needs to see their own bookings, do not grant them control over all clients and all services.

When configuring the Employee Panel, check three layers: whether the panel page is published, whether its URL is specified in role settings, and whether the employee has a password and the required permissions. If staff members are allowed to manage clients, explain the rules for handling personal data in advance. If they are allowed to change schedules, make sure they cannot accidentally open unavailable slots or remove an important day off.

Practical Example: Booking a Consultation with Payment and Notifications

Let us walk through a working scenario that fits a consulting website, clinic, studio, or online service business. The goal is to create an "Initial Consultation" service, place the form on a dedicated page, accept a booking, send notifications to the client and the staff member, and then verify the result both in the admin panel and on the public page.

Goal and Preparation

You want a page where the visitor selects only one service, sees the available hours of one or more staff members, enters contact details, and receives a clear confirmation. Before you begin, you should already have the following in place: the plugin installed, a staff profile, working hours, a WordPress page for the form, properly configured email delivery, and at least a basic notification template.

Setup Steps

1. Create a service category, for example "Consultations," so it does not get mixed with events or group sessions.
2. Create the "Initial Consultation" service, set its duration, price or on-site payment option, description, and calendar color.
3. Assign the service to a staff member. If there is only one staff member, make sure their profile is active and visible on the site if needed.
4. Open the staff member's working hours and confirm that the service duration fits into the available intervals.
5. Enable the email notification to the client for a created booking and the notification to the staff member for a new booking.
6. Create a page called "Book a Consultation" and insert the form using the Amelia block or a shortcode filtered to that specific service.
7. Open the page in a private browser window, choose a time, and create a test booking using an email address you can check.

Verifying the Result

After the test booking, open Amelia in the admin panel and check the bookings list. The booking should contain the correct service, staff member, date, time, status, and client details. Then open the Amelia calendar and confirm that the slot is occupied. If the staff member's external calendar is connected, verify that the event appeared there as well. If notifications are enabled, check both the client email and the staff email. The email should contain specific data, not generic wording: the service, time, client name, location, or online meeting link if one is configured.

A Detail People Often Forget

Do not test only the happy path - test edge cases too. Try selecting a time near a break, the last slot of the day, a service with a different duration, a booking from an existing client, and a cancellation. If payment is involved, test what happens with an incomplete payment and when returning to the confirmation page. These are the scenarios that show whether the setup is truly ready for real visitors.

Verifying the Result on the Site and in the Admin Panel

A good Amelia setup is only complete after the full cycle has been tested. A visible form on a page does not prove that the business process actually works. You need to confirm that bookings are created, notifications are sent, occupied time is respected, staff can see the appointment, and the client receives a clear next step.

Pre-Launch Validation Checklist

• The form loads for a guest, not only for a WordPress administrator.
• The client sees only the services, staff members, and locations relevant to that page.
• Available slots match working hours, breaks, days off, and external calendars.
• After booking, the appointment appears in Amelia → Bookings and in the calendar view.
• A duplicate booking for the same slot is blocked or limited by capacity rules.
• Notifications reach both the client and the staff member with the correct placeholders.
• If payment is involved, the booking status and payment status do not contradict each other.
• The booking page still works after clearing cache and in a mobile browser.

If the site uses a page builder, test not only the page in the editor but the published result as well. Some builders load widgets differently in editing mode versus on the public page. If the form opens in a popup, test reopening, closing, submitting, and mobile behavior separately.

How to Tell the Setup Is Actually Ready

Ask someone who was not involved in the setup to go through the booking flow like a regular client. They should understand without guidance which service they are choosing, why those specific hours are available, which details are required, and what happens after confirmation. If that person asks too many questions, improve not just the page copy but the form structure itself: you may need to filter the service, rename a field, remove an unnecessary step, or add clarification to the notification.

The best test: after booking, the client should not be left wondering, "Was my appointment accepted, or am I still waiting?" The status, the email, the confirmation screen, and the calendar entry should all say the same thing.

Common Amelia Issues and How to Troubleshoot Them Without Chaos

Most Amelia errors are caused not by a single toggle, but by the interaction of multiple settings. That is why troubleshooting is best approached by symptom. First identify exactly what is broken: the form does not load, no available slots appear, the booking is not created, the email was not sent, the external calendar is not syncing, or payment is not changing the status.

The Form Does Not Load or Works Only for the Administrator

Symptom: the administrator sees the form, but a visitor gets an empty block, endless loading, or an error. Possible causes include cache, script optimization, a theme conflict, permission issues, blocked REST requests, or an incorrect widget insertion method.

Start by opening the page while logged out and checking the browser console. Then temporarily disable script optimization only for the booking page, clear the cache, and test again. If the form is placed inside a popup, try displaying it on a normal test page. If everything works on a regular page, the problem is in the popup logic or delayed loading.

No Available Slots Even Though the Service Exists

Symptom: the form shows the service, but the calendar is empty or the dates are unavailable. Check whether the service is assigned to a staff member, whether working hours are set, whether a day off overrides them, whether the service duration fits the available interval, whether Busy events in the external calendar are blocking the time, and whether a location filter is applied for a place where the staff member does not work.

Fix one factor at a time. Do not change the service, staff member, calendar, and form all at once. For example, temporarily disable the location filter, check the slot, then restore the filter. That way you will find the actual cause without creating a new problem.

Notifications Are Not Arriving or Are Missing the Required Data

Symptom: the booking was created, but the client or staff member did not receive the email, SMS, or WhatsApp message. First check whether the required template is enabled and whether it matches the booking status. Then verify WordPress mail transport, staff email addresses, phone numbers with country codes for SMS, SMS balance, WhatsApp integration status, and the placeholders inside the template.

If the email arrives but contains empty fields, the problem is often an incorrect placeholder or the fact that the field does not belong to that booking type. For custom fields, make sure the field is actually linked to the correct service or event and that the placeholder is inserted into the matching template.

Payment Went Through, but the Booking Status Looks Wrong

Symptom: the client paid, but the booking stayed pending, was not marked as paid, or the WooCommerce order did not sync with the booking. Check the payment method settings, test mode, post-payment return behavior, the provider's webhook or notifications, and the status mapping rules between Amelia and WooCommerce. If payment by link is used, make sure the required placeholder is included in the notification.

The best rollback candidates are the settings changed most recently: enabling WooCommerce, changing the default status, adding a new payment method, or editing notification templates. Do not manually move real bookings between statuses unless you understand the cause, or your reports and statuses may drift apart.

Google Calendar or the Online Meeting Is Not Being Created

Symptom: the booking exists in Amelia, but the external event did not appear or the meeting link is missing. Check whether the integration is connected globally, whether a calendar is assigned to the specific staff member, whether the staff member overrode settings in their own panel, whether the credentials are valid, and which statuses are supposed to create events. Amelia's changelog regularly includes integration-related fixes, so the installed version matters especially here.

When It Is Better to Contact Support

If the error can be reproduced on a clean test page, with optimization disabled, with one service and one staff member, and there is a specific message in the console or log, collect the data and contact the developer's support team. A useful support request includes reproduction steps, screenshots of the service, staff member, and schedule settings, a link to the test page, the integration status, and the exact symptom. Saying "the plugin does not work" helps very little, while a step-by-step scenario speeds up the response.

Performance, Security, and Clean Ongoing Maintenance

Booking is a critical user flow. If the form is slow, emails do not arrive, or client data is too widely accessible, the business loses not only leads but also trust. That is why, after setup, it is worth creating a separate operational checklist.

Cache and Speed

You do not need to turn the booking page into a completely non-cached website, but the form itself must stay dynamic. Exclude the page from overly aggressive HTML optimization, check how Amelia's scripts are loaded, and do not combine all interactive scripts without testing. After every cache-related change, run a test booking as a guest.

Staff Access and Client Data

The Employee Panel and role controls are useful, but they should not be enabled on a "let everyone see everything" basis. A staff member usually only needs their own bookings, their own schedule, and limited access to clients. If you allow client management, define internal rules clearly: who can view personal data, who can change bookings, who can cancel appointments, and who is responsible for mistakes.

Updates and Backups

Amelia has a changelog with new features, improvements, and fixes, including integration and security fixes. Before updating on a live site, create a backup, especially if you actively use WooCommerce, external calendars, custom fields, panels, and payments. After the update, repeat a short test: form, booking, email, payment, calendar.

Do not edit plugin files directly. If you need to change the appearance, start with the built-in Customize section. If that is not enough, use CSS at the theme level or through a safe custom CSS plugin, but only after checking the real classes in your version and without interfering with the form logic. For unstable classes, it is better not to include a generic snippet in a guide - it will go out of date quickly and create more problems than value.

When CodeCanyon Amelia Is the Right Choice

CodeCanyon Amelia is a strong fit when your WordPress site needs more than a basic inquiry form and instead requires managed bookings: services, staff, schedules, forms, notifications, payments, panels, and a result you can verify. The plugin is especially effective when it is important to prevent double-booking, give the client a clear booking path, and reduce manual back-and-forth communication.

Before launch, do not chase the maximum number of features. First configure the basic chain, run a test booking, check notifications, and verify time availability. Then add external calendars, WooCommerce, panels, and custom fields. That approach makes the system more predictable and reduces the risk of a real client landing in a half-finished flow.

If Amelia matches your service model after testing, you can download CodeCanyon Amelia and test the plugin on a separate site copy or a prepared staging environment. The main thing is to verify not just the look of the form, but the full cycle: booking, status, notification, calendar, payment, and staff actions.