Amelia is a WordPress booking plugin for appointment and event workflows. Evaluate 4 connected outcomes before relying on it: the service is described correctly, availability reflects real constraints, booking status is clear and messages reach the intended people. A calendar displayed on a page proves only that part of the interface appears.
Start by describing what the customer is booking. A consultation with a person differs from a group event or a service requiring a particular location. The edition and configuration must fit that workflow. Do not assume that every feature mentioned in the product’s wider documentation is included in the installation being proposed.
What should be configured before the booking form?
Amelia’s service guide describes setting up bookable services. Its appointment guide describes booking creation and status management. The WordPress directory listing supplies product and edition context. Use the documentation for the actual version and verify the required feature in that edition rather than relying on a screenshot from another setup.
| Requirement | Decision to make | Evidence to inspect |
|---|---|---|
| Service | What the appointment covers | Accurate name and description |
| Duration | How much bookable time it uses | The intended interval on the public form |
| Staff | Who can provide the service | Relevant people and their schedules |
| Location | Where the appointment happens | Consistent customer and staff information |
| Status | Whether a booking needs approval | Clear pending or confirmed wording |
| Communication | Who receives which message | Actual delivered test messages |
| Changes | How cancellation or rescheduling works | A coherent supported change process |
This original matrix defines requirements to demonstrate. It is not an assertion that every resource model or integration is available automatically. Where equipment, rooms or group capacity matter, identify the exact feature and test the proposed arrangement.
Write service descriptions from approved business information. A default example must not become a promise about preparation, availability or the work provided. If a condition is uncertain, resolve it with the responsible business owner before it appears in a public booking flow.
How should availability be tested?
Set a normal working pattern and then introduce a known exception. An absence, existing commitment or location change should have the intended effect on public availability. Inspect the customer-facing form after the change; a backend setting alone does not establish what a customer can select.
Test combinations of services offered by the same person. Different durations or conditions can reveal an overlap that a single sample appointment would miss. State the expected result before the test so that an unexpected opening is not casually reinterpreted as acceptable.
Understand administrative overrides. Amelia documents more than one route for creating and managing appointments. A staff-side user may be able to create an exception that a customer cannot. Ask which settings permit this, who holds that authority and how the exception remains understandable to colleagues.
Distinguish a permitted exception from an accidental duplicate. Both may look like overlapping calendar entries, but the business meaning differs. Record the reason and responsible person where an exception is authorised, and establish who investigates an unexplained conflict.
What should happen after a customer books?
The final message should identify the selected service, time and location or meeting method. It must also describe the actual status. If approval is still required, the confirmation should not imply that the appointment is final. Check the wording a customer receives, not only the name of the internal notification template.
Inspect both the customer and staff records. A successful browser animation does not prove that the intended employee was notified. Use clearly labelled test details and verify receipt through the actual configured routes. Keep the evidence tied to the tested account and settings.
If payment is part of the workflow, distinguish it from booking status. A request, a confirmed appointment and a completed payment may be separate events. A plugin supporting a payment integration does not prove that the provider can onboard the proposed Zambian merchant. Verify that eligibility independently before selecting the payment path.
Use this original Amelia scenario ledger:
| Scenario | Action | Result to verify |
|---|---|---|
| Ordinary booking | Select a normal available service | Correct person, service and time |
| Schedule conflict | Use a known blocked interval | Public form follows the intended rule |
| Staff absence | Change a relevant availability exception | Booking choices update coherently |
| Approval | Submit a request needing a decision | Pending status remains clear |
| Confirmation | Complete the configured confirmation path | Customer and staff understand the same result |
| Cancellation | Follow the supported customer route | Status and messages reflect the change |
| Rescheduling | Move an appointment through the intended process | Old and new time are handled correctly |
| Override | Make an authorised staff-side exception in a safe test | Reason and ownership remain identifiable |
| Payment | Use an approved provider test where included | Payment and booking outcomes are not confused |
The ledger does not claim that these tests have been performed on a live installation. It is an original acceptance artefact to use with the proposed edition and configuration. A product update or connector change may justify repeating the affected scenarios.
What should the WordPress handover include?
Name the person who maintains services and availability. Separately identify who updates WordPress and the plugin, who handles booking disputes and who can recover account access. These responsibilities can belong to different people, but the handover should make each one explicit.
Record the important configuration and use the site’s authorised backup and change process. Booking behaviour can depend on the theme, other plugins, notification settings and external services. Test a representative journey in an appropriate environment before changing a live customer flow.
Review the fields collected from customers. Ask only for information necessary to the appointment, and decide who can access it. The existence of a booking form does not establish that its collection, retention or disclosure arrangements meet local obligations.
Inspect public wording when business rules change. Working hours may be corrected while an old message still promises a different location or preparation requirement. Keep service descriptions, forms and notifications aligned rather than treating them as unrelated pieces of content.
Configure a service through the current documented route
In an appropriate test installation, first create the employee who will provide the service and at least one service category. Open Amelia → Services → + Service. Complete Details with the service name, category and assigned employee; enable Show on website only when it should be bookable. Then set the actual duration and capacity through the relevant service settings and place the chosen booking form on the test page. Check the installed edition before relying on reminders or integrations: the directory explicitly excludes several such features from Lite.
Create an ordinary test booking and inspect Amelia → Bookings → Appointments. Compare service, employee, time and status with the public result. Group booking has an important exception: a minimum capacity greater than one keeps the overall booking Pending until the minimum is reached, even if Approved is the default. Buffers and time-bearing extras can also make occupied time longer than the visible base service duration. Include those cases before treating a displayed opening as genuinely available.
See WordPress for the related platform work. To explain an Amelia requirement, get started with the installed edition, services, staff constraints and booking states that must work.
By Spout Team. AI-assisted drafting by Codex using the linked primary sources.