Designing booking flows customers actually finish

A booking flow is the most valuable twenty seconds on a service business's website. It is also where most of them quietly lose people. Building booking interfaces for barbers, salons, garages and groomers in the demo library surfaced the same handful of patterns again and again.

#Start with the decision the customer has already made

By the time someone taps Book, they have usually decided what they want. They have not decided when. Many flows start by asking for a name, email and phone number before showing a single time slot. That is backwards: it asks for commitment before giving value.

A better order is:

1. Service — preselected if the visitor tapped Book on a specific service card.
2. Time — show real availability as early as possible.
3. Details — only what the business genuinely needs to deliver the service.
4. Confirmation — a clear summary, not a generic "thanks".

In the barbershop demo, every service card carries its own booking link so the first step is already done when the flow opens.

#Ask for less

Every extra field costs completions. For most appointment businesses, the minimum is a name and one way to reach the customer. Anything else should earn its place:

• A garage needs the registration because it determines parts and timing.
• A groomer needs the dog's size and breed because it changes duration and price.
• A cleaner needs bedrooms and bathrooms because they are the price.

Notice the pattern: each extra question directly changes what the business will do. If a field does not change the job, it does not belong in the flow.

#Put price and duration next to the button

"How much?" and "how long?" are the two questions that stop people mid-booking. Answer both on the service card and again in the summary. The cleaning demo shows a live, itemised price that updates as bedrooms, bathrooms and extras change; nobody has to guess what they are committing to.

#Design for one thumb

Most local-service searches happen on phones. Practical consequences:

• Tap targets of at least 44×44 px with generous spacing.
• Native date and time inputs where they work well, large custom pickers where they do not.
• A sticky action bar at the bottom of the screen with Call and WhatsApp alongside Book, because some customers will always prefer to talk.

Every demo in the library ships with a sticky mobile bar for exactly this reason.

#Confirm like a receipt

The confirmation screen should read like a receipt: service, date, time, price, address, and what happens next. If changes or cancellations are possible, say how. Ambiguity at this stage generates phone calls — the very thing online booking was meant to reduce.

#Fail gracefully

Slots get taken. Networks drop. A good flow keeps what the customer typed, explains what went wrong in plain language and offers the nearest alternative. "Something went wrong" with an empty form is the fastest way to lose a booking.

#What the demos simulate, and what they don't

The booking interfaces in the demo library are simulations: they validate input and show confirmation states, but nothing is sent or stored. A production version would connect to a real calendar, send confirmations and handle rescheduling. Keeping that boundary explicit is part of designing honestly — a prototype should never pretend to be a live system.

#A short checklist

• Service preselected from the card that was tapped
• Availability shown before personal details
• Only fields that change the job
• Price and duration visible at every step
• Sticky mobile actions, including a human option
• A receipt-style confirmation
• Errors that preserve input and suggest alternatives