Skip to content

Website advice

Make it clear whether an appointment is actually booked

Picking a time on a website feels like making a plan. The customer may arrange transport or move work around it. If your office still needs to approve that time, the website needs to say so before the customer treats it as booked.

THE SHORT ANSWER

Check the complete booking route, including the message at the end. A request, an available slot and a confirmed appointment are different things. Use wording that matches the actual result.

Follow the route without relying on what you know

Start on the public service page. Read the invitation beside the button, then follow it to the booking destination. Notice the business location and service selected. A correct button can still open the wrong calendar or leave the customer to choose from unfamiliar options.

Do not make a real booking just to see what happens. Ask the person managing appointments for a supported test method or coordinate an authorized test that will not occupy a customer slot. Keep a note of which page and device you used.

For an example, imagine a repair business that asks for a preferred inspection time but confirms it by phone. That can be a perfectly workable process. The problem begins when the button says Book now and the final screen suggests the appointment is settled even though nobody has checked the request.

Name the result the system can actually deliver

Ask the person handling the diary when an appointment becomes confirmed. Is the selected slot reserved immediately? Does a staff member approve it? Does the customer need to complete another step? Write that sequence in ordinary language before changing any website copy.

Then compare the button and nearby explanation with that sequence. Request an appointment is a reasonable label for a request. Choose a time may describe an intermediate step. The right words depend on the actual service, not which phrase sounds more persuasive.

Read the final screen as carefully as the first button. W3C recommends clear feedback about successful actions and errors. Your practical job is to make that feedback accurate about the action completed. Receiving a request does not establish that the requested time has been accepted.

Avoid inventing an approval deadline to make the message feel reassuring. Any promise about when someone will hear back needs to come from the team responsible for answering.

Compare the website with the message that arrives

Look at the confirmation email or other message produced by the supported test. Check the location, service, time and any relevant time zone. A customer should not have to reconcile a requested time on the page with a confirmed time in an automatic email.

Ask what happens when a requested slot is unavailable. The answer could be a call to agree another time, a new selection process or another established method. Make the next step understandable without suggesting that the customer should keep submitting the same request.

Check the cancellation or change route too. It should lead to the process the business actually uses. Do not add a policy copied from another company. Operational conditions need the business owner's approval before they appear as customer instructions.

Keep a booking decision note

A useful handoff note can identify the service, the point when a slot is reserved, the message the customer sees and the person responsible for exceptions. Keep that note with the approved copy. If the calendar provider changes, use it to check that the replacement still follows the agreed process instead of assuming the new default messages mean the same thing.

Decide who notices a failed handoff

Have the office find the authorized test in its normal system. Check that the information needed to handle it arrived and that somebody is responsible for the next step. A confirmation page can look correct while the office is checking a different calendar.

If the test goes wrong, record the exact point where the two views disagree. The page address, test time and observed wording are more useful than a note saying booking is broken. Keep private customer records and login details out of any general project brief.

After a repair, repeat the same test using the agreed method. Check the public route after launch as well as the preview. A working preview is a place to investigate the process; it is not a substitute for checking the final destination on the real website.

Keep the approved wording with whoever maintains the booking setup. The next time a service changes from immediate confirmation to staff approval, that person should know which page and automatic message need attention.

Further reading

LET’S TALK ABOUT YOUR BUSINESS

Wondering what we’d change about your website?

No technical brief needed. Tell us about the business, and we will confirm the scope and price. No payment with the brief.

Start my website brief