Mobile booking: thumbs, not mice

Picture the guest who is about to book your restaurant. They are not at a desk with a mouse and a large screen. For many venues, most online bookings now start on a phone: on a bus, on a sofa, walking down the street, in a queue, with a thumb, often with a slow connection and half their attention on something else. They have decided they might like to come, and they will give your booking page a minute, perhaps less.

Mobile booking is designing for that guest. It is less about how the booking page looks than about how quickly and easily it lets a distracted person, using one hand, choose a date, a time and a party size and get a confirmation. Every extra second of loading, every tap that misses its target, every form field that asks for something unnecessary loses a share of the guests who were ready to book.

This guide walks through the mobile booking flow from the first tap to the confirmation: speed, the order of choices, tap targets, form fields, what to show when the preferred time is gone, and how to test it the way guests use it. Every figure in it is an example.

A booking flow designed on a laptop tends to assume things a phone does not offer: a large screen where several choices can be seen at once, a precise pointer, a fast and stable connection and a guest who has sat down to do this. On a phone, every one of those assumptions fails.

The screen shows one or two things at a time, so the order of steps matters more. The thumb is imprecise, so small links and close-together buttons cause mistakes. The connection may be slow, so heavy pages lose guests before they load. And the guest is often in the middle of something else, so any step that asks them to stop and think is a step where they may stop altogether.

The first thing a guest experiences is waiting for the page to load, and it is where many mobile bookings are lost. A booking page that takes several seconds to show anything useful, on an ordinary mobile connection, is a booking page many guests never see.

Google's guidance on Core Web Vitals sets out how page speed and responsiveness are measured, and the principles apply directly to booking pages:

Test booking page speed on a real phone, on mobile data rather than the venue's wifi. If you cannot see the booking options within a few seconds, guests cannot either.

A mobile booking flow works best when it asks for one thing at a time, in the order guests think about it.

Party size and date come first because they decide which times are available. Showing times before the guest has chosen a party size invites a guest to pick a time that turns out to be unavailable for their group, which is frustrating on any screen and worse on a phone.

On a phone, everything a guest needs to tap should be large enough to hit reliably with a thumb, with enough space between targets that a slightly wrong tap does not choose the wrong thing. Accessibility guidelines such as the Web Content Accessibility Guidelines include guidance on target size and spacing, and following it helps every guest, not only those with an impairment.

In practice:

Avoid tiny calendars where each date is a few millimetres wide. They are fine with a mouse and miserable with a thumb.

The booking form is where many mobile bookings die. Every field takes typing, and typing on a phone is slow and error-prone. Ask only for what you genuinely need to hold the table and confirm it:

Everything else is a candidate for deletion: titles, full postal addresses, how they heard about you, birthdays, company names. Some of these are useful, but they can be collected later, at the venue or from returning guests, rather than standing between a new guest and a confirmed booking.

Use the right keyboards. An email field that opens the email keyboard and a phone field that opens the number pad save guests time and errors. Let the phone fill in details it already knows where it can.

The one optional field most worth keeping is a notes field for allergies, dietary needs, accessibility requirements and occasions. Guests who need to tell you something important will use it, and the kitchen and the floor team need to know before the guest arrives.

Keep it optional and short, with a prompt such as "Allergies, access needs or a celebration? Let us know." Make sure what guests write reaches the people who need it, on the booking and on the table. A notes field that nobody reads is worse than none, because guests believe they have told you.

On a busy night, the time a guest wants is often taken. What the booking page shows next decides whether they book another time or leave.

Show the nearest available times clearly, before and after the one they wanted, rather than an empty screen or a message that says only "no availability". Offer other days if the whole evening is full. If you run a waitlist, offer that too, with a clear explanation of how it works. A guest who wanted eight o'clock will often take seven-fifteen if it is shown to them, and often leave if it is not.

Many guests reach the booking flow through a booking widget embedded in the venue's own website. On a phone, the widget has to work inside a page it does not control, which brings its own problems: a widget squeezed into a narrow column, a page that loads slowly around it, or a widget that opens in a small window the guest has to scroll inside.

Check the widget on your website on a phone, not just on a laptop. If it is awkward, a simple link to the full booking page often works better on mobile than an embedded widget. Our guide to the booking widget and the four taps that lose a guest covers the widget in more detail.

The booking is not finished until the guest knows it is. The confirmation screen should say clearly that the table is booked, for how many, on which date and at what time, with the venue's name and address. A confirmation email should follow at once, with the same details and a way to change or cancel.

On a phone, make it easy to add the booking to a calendar and to find the venue on a map. A guest who can do both from the confirmation is less likely to forget, and less likely to become a no-show.

Some bookings do not fit a simple flow: a party of twelve, a birthday with a cake, a guest using a wheelchair, a request for a particular table. On a phone, these are where guests often give up, because the booking page either refuses the party size or offers no way to explain.

Set a clear maximum party size for online booking, and above it, show a short message with what to do instead: call, email or send an enquiry. Make sure the notes field is visible enough that guests with access needs or occasions see it. A guest with a complicated request who is shown a clear next step books; one who hits an unexplained limit leaves.

Mobile booking does not end with the confirmation. Most guests will check their booking, change it or cancel it on the same phone they booked on, often from the confirmation email. That flow needs the same care as the booking itself.

A reminder a day or so before the booking, with the details and a one-tap way to change or cancel, reduces no-shows and frees tables early when plans change. The manage page it opens should be as quick and simple as the booking page: find the booking, change the time or party size, or cancel, without signing in to anything. A guest who can cancel in ten seconds is a guest who will tell you, rather than simply not arriving.

Some venues ask for card details at booking, to take a deposit or hold a card against no-shows. On a phone, this is one of the steps where most guests hesitate, because typing a card number one-handed is slow and because guests are wary of giving card details to a page they have only just found.

If you ask for payment details, make the reason clear before the card form appears, keep the form as short as the payment provider allows, and support the phone's built-in payment options where you can, so guests do not have to type at all. Ask for it only where it is needed, such as large groups, special events or your busiest nights, rather than for every booking, so the ordinary booking stays quick.

Booking conversion is the share of guests who start a booking and finish it. It is the best single measure of whether a mobile booking flow works. If you can see how many people open the booking page and how many bookings are made, the ratio tells you a lot.

As an invented example: of 1,000 visits to a booking page in a month, 300 bookings are completed, a conversion of 30 per cent. If most of the drop happens between choosing a time and completing the form, the form is probably the problem. If it happens before a time is chosen, availability or speed probably is. Our guide to booking conversion from page view to confirmed explains how to find where guests leave.

The best test is the simplest: book your own restaurant, on a phone, one-handed, on mobile data, starting from where guests start, such as your Instagram bio or your Google profile. Time it. Note every moment of hesitation, every mis-tap and every field that felt unnecessary.

Then ask a few people who do not know the booking page to do the same while you watch. Do not help them. The places where they slow down or get stuck are the places to fix. Our guides to bookings from Instagram and to booking from Google cover the routes guests most often take to the booking page.

Guests with impaired vision, limited dexterity or other needs book on phones too, often with screen readers or larger text settings. A booking flow that works with large text, has clear labels on every button and field, and does not rely on colour alone to show what is available or selected works better for everyone.

Check that the booking page still works with the phone's text size turned up, and that each button says what it does. These are small details that open the booking page to guests who would otherwise give up or phone instead.

On a small screen, words take up space, so every word should help. Use short, plain labels: "How many?", "When?", "Pick a time", "Your details", "Book". Avoid jargon such as "covers" or "reservation slot". Error messages should say what to do, not just what went wrong: "Please enter an email so we can confirm your table" rather than "Invalid input".

Match the tone to the venue, but keep it clear. A playful booking page is fine, as long as it never leaves a guest unsure what to tap next.

An invented bistro's booking page asks for party size, date and time in a single screen with a small calendar, then for title, first name, surname, email, phone, postcode, how the guest heard about the bistro and a notes field. On a phone, the calendar is hard to use, and the form needs a lot of scrolling and typing.

The bistro changes the flow: party size as large buttons, a strip of dates for the next week, times as large buttons, and a form with only name, email, phone and notes. It also shows the nearest available times when the chosen one is full. Over the next month, the bistro's own count of booking page visits against completed bookings shows noticeably more of the visits ending in a booking, with the biggest improvement on busy evenings, where alternative times now keep guests who would have left.

servearound gives each venue its own booking page, designed for phones: party size as large buttons, a strip of upcoming dates and the available times as buttons, then a form for first and last name, phone and email, with a six-digit code sent to the guest's email to confirm it before the booking is made. That step stops mistyped addresses and fake bookings, at the cost of one more screen.

The guest gets a confirmation by email with a link to manage the booking. There is no notes field for guests today, so allergies and requests are recorded by your team on the booking or the guest's profile, where they show on the reserved table and the kitchen ticket. The same booking flow can be embedded as a widget on your own website. See the reservations module.

Online booking settings let you set the maximum party size, the notice you need, how long a guest has to finish booking and reminders, and a waitlist can catch guests when the night is full. Analytics shows bookings by source, so you can see how much of your trade arrives through the booking page and the widget.

Because for many venues most online bookings now start on a phone, often from Instagram or Google, by a guest who will give the booking page only a minute or two.

Fast enough that the booking options appear within a few seconds on an ordinary mobile connection. Test it on a real phone on mobile data, not on the venue's wifi.

Name, a way to confirm and contact the guest, and an optional notes field for allergies, access needs and occasions. Most other fields can be removed or collected later.

Party size, then date, then time. Party size and date decide which times are actually available.

It can be, but check it on a phone. If it is cramped or slow inside your website, a link to the full booking page often works better.

The nearest available times before and after, other days if the evening is full, and a waitlist if you run one.

Compare visits to the booking page with completed bookings over a period, and look at where in the flow guests drop out.

Book your own restaurant on a phone, one-handed, on mobile data, starting from Instagram or Google. Then watch a few people who do not know the page do the same without help.

As few as the information requires: party size, date, time, details and confirmation. Each extra screen or field is a point where some guests give up.

No. Requiring an account or a password adds steps and loses guests on a phone. Ask for the details needed to confirm the booking and nothing more.

Yes. Clear labels, large targets, support for larger text and not relying on colour alone help guests with impairments and make the page easier for everyone.

Mobile booking means designing for a distracted guest with one thumb, a small screen and a slow connection. Make the booking page fast, with the booking form first. Ask for party size, then date, then time, one step at a time, with large buttons and plenty of space. Keep the form to name, contact details and an optional notes field, with the right keyboards.

When the preferred time is gone, show the nearest alternatives instead of an empty screen. Confirm clearly on screen and by email, with calendar and map links. Check any embedded widget on a phone, keep the page accessible, and test the whole flow the way guests use it. Most of the bookings a venue loses on mobile are lost to small frictions that are easy to remove.