Requirements and responsibilities
Approve the service menu, price wording, duration, staff biographies, image rights, location, opening hours and who changes each item. Distinguish a request from a confirmed booking and give visitors a phone fallback for unavailable slots.
WordPress roles and capabilities · Easy!Appointments official initial configuration
Use an approved native WordPress site for public pages and a separately owned scheduler for appointments. Easy!Appointments is a documented worked example; verify its current license, stack, app administrator and notification setup before promising it.
xCloud agent capability boundaries · Easy!Appointments hosting, setup and deployment requirements · Easy!Appointments official initial configuration
Keep treatment or health details out of a generic WordPress contact form unless the business has separately approved fields, recipients and retention. This guide makes no regulatory or medical compliance claim.
WordPress hardening handbook · Contact Form 7 getting started guide
Illustrative situation
Illustrative scenario: a salon offers hair services and a spa offers timed treatments at one address. Staff need clear service duration, provider assignment and closure dates; a customer must find prices and contact details before following the booking link. Any health intake stays in the business’s separately approved process.
Choose the approach
Use a plain booking link first. A calendar embed, deposit integration or shared sign-in should be a separate choice only after the selected app and payment provider document and pass those behaviors.
Easy!Appointments official initial configuration · Easy!Appointments official application settings
Keep public service pages and appointment records in different systems with different update and recovery owners. WordPress hosting backups do not by themselves prove a scheduler appointment can be restored.
Site backups in xCloud · Back up and restore Docker apps · Easy!Appointments hosting, setup and deployment requirements
Dashboard and application procedure
Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.
Step 1 of 6
Approve services, providers and public promises
- Where
- Business service worksheet and staff roster
- Permissions
- Salon/spa manager approves service, price and staffing rules.
- Inputs
- Service names, duration including cleanup time, provider qualifications, price wording, address and urgent contact fallback.
- Action
- List the services each provider actually performs, including time for cleanup within the approved duration or a manually blocked period. Approve price and cancellation wording for the public page, plus a telephone path when a visitor cannot find a slot. Keep sensitive treatment intake out of this marketing worksheet.
- Expected result
- The public menu can be matched to staff availability without assuming every provider offers every treatment.
- Verify
- Ask a shift lead to map one hair service and one spa treatment to provider, duration, buffer and confirmation rule.
- If it fails
- If no staff member owns a service or price, leave that offer unpublished until the operations roster is corrected.
Sources: Easy!Appointments official initial configuration · WordPress roles and capabilities
Step 2 of 6
Publish service, team and location pages
- Where
- WordPress Pages, navigation and public mobile browser
- Permissions
- Named WordPress editor publishes only manager-approved copy.
- Inputs
- Approved service menu, provider bios and photos, image rights, address, hours and accessible contact action.
- Action
- Publish separate service and team pages, current hours and location details in WordPress. Make pricing context, booking entry point and call fallback obvious on mobile; use named editor roles so temporary staff cannot change plugin or payment settings.
- Expected result
- A new visitor can compare services, find the correct location and contact staff without opening the scheduler.
- Verify
- From an anonymous phone-sized browser, locate one treatment, its price context, an available contact path and the branch address.
- If it fails
- If a page shows an old provider or holiday hours, correct the approved content before driving campaign traffic to it.
Sources: WordPress roles and capabilities · WordPress plugin administration
Step 3 of 6
Configure the selected scheduler separately
- Where
- Easy!Appointments administrator in the worked example
- Permissions
- Named scheduler administrator, not the WordPress hosting operator.
- Inputs
- Selected Easy!Appointments instance, current vendor docs, provider roster, business time zone and closure dates.
- Action
- In the separately approved Easy!Appointments instance, configure services, providers, working hours, closures and time zone from the roster. Include cleanup in service duration or block the time manually unless a documented separate buffer control exists. Set notification destination in the app and test it separately.
- Expected result
- Displayed slots reflect the selected provider and the agreed duration and closure rules in the chosen application.
- Verify
- Inspect one overlapping provider window, a holiday closure and a treatment with cleanup time in both customer and staff views.
- If it fails
- If provider availability or cleanup time differs from the approved roster, keep a staffed request route visible and hold instant booking.
Sources: Easy!Appointments official initial configuration · Easy!Appointments official application settings · Easy!Appointments official appointment notifications
Step 4 of 6
Link WordPress to the booking destination
- Where
- WordPress navigation and selected scheduler public page
- Permissions
- WordPress editor controls link; scheduler administrator controls the destination.
- Inputs
- Exact scheduler URL, service entry point, mobile browser and signed-out customer test account.
- Action
- Add a plain booking link from each relevant WordPress service page to the selected scheduler. Test from mobile and desktop that it reaches the correct service and address; do not imply an embed, shared login or transferred customer record until that integration is documented and tested.
- Expected result
- The visitor reaches the intended booking destination with a clear way back to salon contact information.
- Verify
- Open the link in a fresh signed-out session; compare destination host, selected service and contact fallback with the public page.
- If it fails
- If a link opens another branch or a login wall, remove the broken action and route visitors to the staffed contact path.
Sources: Easy!Appointments official initial configuration · WordPress roles and capabilities
Step 5 of 6
Test occupied slots and notifications
- Where
- Easy!Appointments customer and staff views
- Permissions
- Scheduler administrator and shift lead use synthetic customer identities.
- Inputs
- Two providers, overlapping time windows, service duration, cancellation policy and safe test email addresses.
- Action
- Book a marked appointment for one provider, try the occupied slot again, then cancel and reschedule it. Compare customer confirmation and staff calendar with the business time zone, approved duration including cleanup, and any daylight-saving boundary relevant to the location.
- Expected result
- Only allowed slots can be confirmed, and the staff record agrees with the customer’s time and provider.
- Verify
- Match appointment ID, provider and local time between customer message and administrator view; check cancellation frees capacity according to policy.
- If it fails
- If the occupied slot double-books or a message disagrees with the calendar, stop public booking and use staffed confirmation until fixed.
Sources: Easy!Appointments official initial configuration · Easy!Appointments official application settings · Easy!Appointments official appointment notifications
Step 6 of 6
Assign updates and separate recovery owners
- Where
- WordPress, scheduler and staff operations ledger
- Permissions
- Site owner, scheduler administrator and shift lead accept distinct duties.
- Inputs
- WordPress backup point, scheduler backup method, latest bookings, content review date and outage phone contact.
- Action
- Assign who updates service copy and holiday hours, who reviews appointment exceptions and who checks each application’s backup. Before any scheduler restore compare its point with newer appointments and customer messages; rehearse a staff phone route for a website or scheduler outage.
- Expected result
- A new shift lead can answer a booking dispute and find the right owner for each failed system.
- Verify
- Ask the lead to identify a future appointment, its scheduler record, the last backup time and the staffed outage route.
- If it fails
- If the scheduler backup predates live bookings, export or reconcile them before restoring; a WordPress restore is not the fix.
Sources: Site backups in xCloud · Back up and restore Docker apps · Easy!Appointments hosting, setup and deployment requirements
Maintenance
Review service prices, staff biographies, holiday hours and booking links whenever the roster changes. Repeat a marked booking/cancellation test after scheduler or WordPress updates and inspect notification delivery.
Easy!Appointments official initial configuration · Easy!Appointments official appointment notifications · Manage WordPress updates with Updates Manager
Check actual completion of WordPress and scheduler backups separately; confirm the shift lead has current customer and staff contact routes during an outage.
Recovery decisions
If the scheduler fails, provide staffed booking and cancellation by phone while preserving current appointment records. Restore only from the scheduler’s own verified point after reconciling newer bookings; an older WordPress database cannot rebuild them.
Easy!Appointments hosting, setup and deployment requirements · Back up and restore Docker apps
If a WordPress page is restored, compare service, staff and holiday information with current operations before reopening public links. A copied scheduler needs outbound notification quarantine before any rehearsal.
Site backups in xCloud · Easy!Appointments official appointment notifications
AI handoff
Connect xCloud MCP for the named team and discover the granted tools, schemas and scopes. Use resource reads to confirm site identity and returned dashboard URLs. The packaged REST fallback is GET-only; staging, backup schedules, restores and cache settings require the dashboard, while WooCommerce, booking and WordPress content settings belong to their named application owners.
Supported scope
- Confirm requirements and inspect resources mcp · read
Discover the connected profile and operation schema first; only teams granted to the connection are visible.
Checkpoint: Confirm exact team, server and site identity. Use dashboard_url returned by the resource; do not invent a dashboard link.
Operation identifiers and scopes to discover
teams.index, servers.show, sites.show
Scopes: read:servers, read:sites
xCloud MCP documentation and connection profiles · xCloud agent capability boundaries
- Business owner review and acceptance app · manual
Human planning, acceptance and record reconciliation cannot be inferred from xCloud resource reads. The business owner chooses the application's source of truth.
Checkpoint: Record approved criteria, observed application evidence, unresolved questions and named follow-up.
WordPress roles and capabilities · xCloud agent capability boundaries
- Configure WordPress content, users and selected plugins app · manual
Requires a named WordPress administrator or suitable editor. Plugin behavior, commercial license, payment, email and external integration are verified in the chosen vendor documentation and application; xCloud hosting or MCP reads do not configure them.
Checkpoint: Open the actual WordPress or selected plugin interface, record the version and role, and have the business owner accept a real user journey.
WordPress roles and capabilities · WordPress plugin administration
- Configure the booking application and run acceptance tests app · manual
xCloud hosting operations do not configure business rules, staff calendars, reminders, payments or WordPress plugins.
Checkpoint: An authorized application administrator performs configuration and confirms each customer and staff journey.
Easy!Appointments hosting, setup and deployment requirements · Easy!Appointments official initial configuration · Easy!Appointments official application settings · Easy!Appointments official appointment notifications · xCloud MCP documentation and connection profiles
Copyable agent brief
Manual checkpoints
- A WordPress editor publishes approved services, staff details, hours and the plain booking link.
- The selected Easy!Appointments administrator configures providers, availability, time zone and notifications and runs the marked booking test.
- The shift lead maintains a staffed fallback and reconciles newer appointments before any scheduler restore.
Feature coverage
- industry-service-discovery (covered): Covers service menu, pricing context, staff and location rather than only booking. Approve services, providers and public promises Publish service, team and location pages
- booking-handoff (covered): Separates WordPress link from selected scheduler configuration. Configure the selected scheduler separately Link WordPress to the booking destination
- booking-acceptance (covered): Tests provider overlap, duration, time zone, cancellation and notification. Test occupied slots and notifications
- industry-operations (covered): Names content, booking and independent recovery owners. Assign updates and separate recovery owners
Sources
- WordPress roles and capabilities
- Easy!Appointments official initial configuration
- xCloud agent capability boundaries
- Easy!Appointments hosting, setup and deployment requirements
- WordPress hardening handbook
- Contact Form 7 getting started guide
- Easy!Appointments official application settings
- Site backups in xCloud
- Back up and restore Docker apps
- Easy!Appointments official appointment notifications
- Manage WordPress updates with Updates Manager
- WordPress plugin administration
- xCloud MCP documentation and connection profiles