Booking form design: service, date, time, details, confirmed
A good booking form follows the order people actually decide in: what they want, when they can come, which time is free, then who they are. Show only times that can really be booked, ask for the few details you need to keep the appointment, and end with a confirmation that repeats exactly what was booked.
The order of a booking flow
- Service. What they're booking, with its duration and price beside each option. Duration matters because it decides which times fit.
- Date. The coming days, with unavailable days clearly marked rather than hidden, so people understand the pattern.
- Time. Only the slots still free on that day, as large tappable options rather than a dropdown.
- Details. Name, then a way to reach them: email, phone, or both if you really use both.
- Review and send. A short summary of service, day and time next to the button, so nothing is a surprise.
Asking for personal details first, before people know whether a suitable slot exists, is the most common mistake in appointment form design. It makes visitors invest effort before they see value, and they leave when the only times are wrong.
Showing availability
Availability is the heart of reservation form UX. A few rules:
- Show real slots, not a free-text time field. “Preferred time” invites requests you can't meet and back-and-forth emails.
- Make slots big enough to tap. Around 44px tall works for thumbs, and WCAG 2.2 sets a 24 by 24 pixel minimum for targets.
- Group times by part of day (morning, afternoon, evening) when there are many, so a phone screen doesn't become a wall of buttons.
- Show the time zone if visitors might be elsewhere, such as for video calls.
- Say how far ahead people can book and whether same-day bookings are possible, near the calendar, not in the small print.
- Use real form controls. Slots built as radio buttons get keyboard and screen reader support for free; a grid of clickable divs doesn't.
Which details to ask for
| Field | Ask when | Note |
|---|---|---|
| Name | Always | One field is enough; don't split first and last name unless you need to |
| Almost always | For the confirmation and any change of plan | |
| Phone | You call or text about appointments | Say why you're asking, for example “so we can text if we're running late” |
| Notes | The service needs context | Optional, short, with an example of what's useful |
| Address | You travel to the customer | Otherwise leave it out |
| Date of birth, account creation | Almost never at booking | These add friction and data you then have to protect |
Label every field visibly, above the input. Use the right input types and autocomplete values (name, email, tel) so phones offer the visitor's details and the correct keyboard; WCAG calls this identifying input purpose. More on fields in web form design best practices.
Confirming clearly
The confirmation is part of the design. It should repeat the service, the day, the time and the place, say what happens next (an email, a reminder, nothing further) and explain how to change or cancel. A vague “Thanks, we'll be in touch” leaves people unsure whether they actually have a booking. If a slot was taken while they were filling in the form, say so plainly, keep what they typed and show the nearest free times.
Booking page design on phones
Most bookings happen on phones. Keep the flow in one column, put the service list and day picker high on the page, avoid date pickers that open tiny month grids, and make sure the summary and button aren't hidden behind the keyboard when someone is typing their email. Test the whole flow with one thumb.
Booking forms in Anticode
Anticode's booking calendar follows the order above. The built-in booking form asks for the service, the day, the time, then name, phone and email. The calendar always shows the coming days; dates in the past or more than 120 days ahead are refused, and two visitors can't book the same slot, so each service has one booking per day and time. It offers six fixed times a day, from 09:00 to 17:30, over the coming days with Mondays skipped; owners can't set their own hours, slot lengths or closed days. Time slots are real radio buttons, at least 44px tall, with a visible keyboard focus. Bookings are saved, sealed at rest, and can be emailed to the owner or sent on through a form connector such as Slack or Google Sheets. Anticode doesn't email the visitor: the owner confirms each booking themselves, so edit the generated thank-you and FAQ wording, which mentions a confirmation email.
See the booking calendar feature page for setting it up, or the guide to adding a booking calendar to a website.
Questions people ask
What order should a booking form be in?
Service, date, time, then contact details, finishing with a summary next to the button. People should see availability before they type anything personal.
Should a booking form ask for a phone number?
Only if you'll use it, and say why. Many services manage with an email address alone.
How should time slots be shown?
As large, tappable options listing only free times, grouped by part of the day if there are many, built as real radio buttons.