Make appointment requests clearly different from confirmed bookings

Find where confirmation is being implied

Follow the public appointment route without an editor account. Ask whether a visitor could reasonably believe the selected time is final. Compare the button, calendar heading, confirmation page and email. If staff still need to check suitability or resources, the initial state is a request. Hidden internal approval rules do not correct a customer-facing statement that says the visit is confirmed.

Identify the booking state your platform stores

Wix documents a manual-approval appointment mode and distinguishes requesting a booking from approval. Check the actual service settings you use. A business can need approval for some services but accept others automatically, so inspect each relevant service rather than treating every calendar entry the same. Your copy should describe the stored state, not a generic booking template.

Source checks: Wix Bookings: Requiring Approval for Appointment Bookings · W3C WAI: User Notification

Walk through request, approval and decline

Use a fictional test contact with a clear test label and coordinate with staff. Complete one request and inspect what the customer receives before anyone approves it. Then test acceptance and decline or rescheduling using supported platform controls. Remove test appointments from operational capacity afterward without erasing the evidence needed to document the process.

• List services that require staff approval and identify their public booking routes.
• Change request-stage labels and messages to state that the selected time is awaiting approval.
• Submit a marked test and verify the dashboard shows a pending request.
• Approve one agreed test and inspect the final date, time, location and customer notification.
• Test the supported decline or reschedule path and confirm that customers receive a clear outcome.

Prevent contradictory messages across channels

Do not manually send 'confirmed' emails while leaving the platform record pending. Customers may receive later reminders from the wrong state. Avoid claiming a time is held if settings allow multiple requests for it. If approval depends on photos, access or location, explain that need before submission so customers do not mistake the request for a guaranteed appointment.

Measure pending requests and incorrect expectations

Track pending requests awaiting review and the time until an accepted, declined or revised outcome. Record customer reports of arriving before approval as a distinct problem. A successful test verifies state and messages; it does not demonstrate booking availability for every date or prove that manual approval is the best commercial choice.

Assign an approval owner

Assign someone to monitor pending requests and a backup during absence. Keep service-specific approval requirements in the website maintenance record. If the business changes from manual to automatic acceptance, test the entire customer sequence again. The owner should approve the final wording and make sure staff use the same state names in direct replies.

Worked example: an illustrative customer journey

For example, a mobile detailer requires staff to check travel availability, but the page says 'Book your confirmed time'. TEST-BOOK-1301 is saved as pending. The owner changes the request-stage language and explains that travel suitability is reviewed before approval.

After the test is approved, the customer-facing message contains the accepted time and location. A separate declined test receives a clear outcome. These tests establish the distinction between states; they do not promise that every requested time will be approved.

Questions about this task