Insights · Buying a website

A booking button is the beginning.
The diary has to work.

Dale Boyles, Cofounder · Published 15 October 2026

A booking website should let a customer understand the service, choose a genuinely available time and know whether the booking is confirmed. The business also needs a reliable way to manage changes, take any agreed payment and recover when something fails. Decide those rules before choosing the calendar’s appearance.

Choose how much the website needs to do

Moving a booking form onto a website does not by itself improve the underlying diary. If staff also take appointments by phone or in person, those bookings need to affect the same availability. Otherwise, a polished page can still offer a slot that has already gone.

Write the diary rules in ordinary language

Before a build, list each service’s duration, preparation or recovery time, staff requirements, rooms or equipment, and the notice needed before an appointment. Include working hours, breaks, holidays and the last acceptable start time. If times can cross regions, make the time zone explicit.

Fictional example: a 45-minute appointment needs a further 15 minutes before the next customer. In a 60-minute free window, the bookable service takes 45 minutes but occupies the full hour. Two staff members do not double capacity if both require the same room. These are diary rules, not just choices in a visual design.

Make the booking state unmistakable

The customer should see the service, date, time and any price or payment requirement before committing. After submission, the page should say whether the request is pending, a slot is temporarily held or the appointment is confirmed. Use the same language in the business’s calendar and any customer message.

Plan what happens if the selected slot disappears before confirmation or the connection drops. A helpful recovery message preserves the information it safely can and tells the customer what to do next. It should not encourage repeated payment or leave the business with several ambiguous requests.

Payment and cancellation need their own decisions

Decide whether payment is unnecessary, a deposit is required or the full amount is due. Confirm which provider handles it, which account receives it and how payment status relates to appointment status. A payment receipt and a booking confirmation are different pieces of evidence.

Put cancellation, rescheduling, refund and no-show terms where the customer can read them before booking. Ask how the system handles a change initiated by staff as well as one initiated by the customer. This guide does not set those policies or suggest that every booking package includes every payment arrangement; they belong in the agreed scope.

Notifications are part of the service

A confirmation screen helps the customer immediately. The business also needs to know that the booking reached the diary, and the customer needs the agreed record of their appointment. Decide who receives each message, what a delivery failure looks like and who follows up.

Where reminders are wanted, specify the channel, timing, content and any provider charges. Distinguish operational booking messages from optional marketing. Do not collect extra information merely because the form builder makes it easy.

Test the awkward journeys before launch

• On a phone: choose a service, date and time without horizontal scrolling or a keyboard covering the essential control.
• With a keyboard: reach every control, see the focused item and recover from validation errors.
• With assistive technology: understand field labels, available dates, errors and the final confirmation state.
• At the edge of availability: try the last slot, a fully booked day, a changed service duration and an appointment near closing.
• When two people choose the same slot: confirm the agreed conflict handling and the message shown to the person who cannot book.
• When something fails: test an interrupted request, missing confirmation and any payment failure without causing duplicate charges or bookings.
• After a change: check that cancellations and reschedules update the diary and the relevant messages.

Use an agreed test environment and test records where available. Any live test that sends a message, books real capacity or takes payment needs the business’s approval. A successful visual demonstration is not evidence that all these operational paths have been tested.

Who owns it after handover?

Record who owns the domain, booking account, payment account and customer records; who can change the rules; and what happens when the service provider changes. Ask about exports, recurring charges, support boundaries and the process for reporting a broken booking journey.

Keep a simple handover checklist: update hours, block time, add or change a service, handle a cancellation, find a failed request and contact support. If the person running the business cannot perform those tasks, the handover is incomplete.

Use demonstrations to judge the journey

Our salon booking example and barber booking example show different ways to present services and a diary. They are fictional demonstration businesses, not client case studies, live appointments or evidence of commercial results.

Use them to discuss the experience you want. Then compare the current website packages and agree which booking rules, integrations and handover work your brief needs. The website-cost guide helps separate the initial build from continuing obligations.

Sources and scope

This is a practical requirements and testing checklist, prepared on 15 October 2026. The diary example is hypothetical. It does not certify a particular booking provider or promise that an unspecified integration is included.

For the ongoing responsibilities, use our website care and ownership guide.