How to design a booking form: time before details

A booking form asks a stranger for their details before it gives anything back. The visitor learns only at the end whether a time is open, so the effort is spent before they know it will be worth it. If the calendar then fails at submit, they have typed everything for a slot that is gone. You book a test appointment for yourself and already know which days are open, so you never meet the visitor who leaves on the second screen.

• The service is chosen first, and a calendar of free times sits on the same screen.
• The time a visitor picks is checked again when they press confirm.
• Only the name, the email and the one detail the service needs are required.
• The phone number is optional, or it is confirmed by email rather than by a text code.
• The confirmation shows the service, the date, the time with its zone, and how to cancel or move it.

Wrong: name, phone, address and the pet's name on the first screen, then the time picker on the second. Right: service, then time, then the details, with the chosen time shown in a summary before the details screen, so the customer knows what they are holding. The wrong order fails for a reason the owner does not see. A customer who types four fields and then meets no free times leaves having given you nothing.

Test the order on a first visit. The tell is a customer who stops on the details screen and mentions the time in their thought, or who never saw a time at all. If they wonder whether the slot is free before they have typed anything, the order is the cause, and no change to the fields will fix it.

A calendar is often loaded once, when the page opens, and a slot picked by one customer can be taken by another before the form is sent. Wrong: the calendar shows the 2:00 PM slot as open, and the submit returns a generic error after the details are typed, with the calendar still showing 2:00 PM. Right: the time is checked again at submit, and if it is gone, the form returns to the time picker with the other free times, and the details stay filled in.

The tell is an error that appears after the details step while the slot stays on screen. A customer who picks the same slot again and gets the same error has hit a stale calendar, not a wrong email or a bad phone number. The report gives the step and the customer's own words, so match them to this pattern before you change a field.

Every required field is a place the booking can end. A phone field that must be confirmed by a text code stops any visitor who cannot receive one, and a simulated visitor cannot receive a text message, so the run stops at the code. A long list of required questions before the time, such as a pet's weight or a company tax number, feels like a form for a different purpose. Right: the name, the email and the one detail the service needs. Everything else can wait for the confirmation page, marked optional, with one line on why it helps.

Onboarding flow testing

A new service, a second staff calendar or a new working week can bring back the old slot list. Rerun the earliest-time path after each change to the services, the staff or the hours, on a phone and a laptop. With paid credits, visitors can book behind a site password while the form is in draft.