The booking widget and the four taps that lose a guest

A booking widget is the small part of your website that does the most important job on it: turning a guest who wants to eat with you into a confirmed table. When it works, guests barely notice it. They choose a date, a party size and a time, leave their details and receive a confirmation, all in under a minute. When it does not, they leave, and most of them never come back to try again. They book somewhere else, phone during service, or simply give up.

The trouble is that a booking widget rarely fails loudly. Nobody writes to say the form asked for too much, or that the time they wanted was full and nothing else was offered. They just close the page. The only sign is a quiet gap between the number of people who looked at your booking page and the number who booked.

This guide follows a guest through a typical booking flow and looks at the four taps where most guests are lost: the tap that finds the booking, the tap on a time, the tap into the form and the tap that confirms. For each, it sets out why guests leave and what to remove from the screen. It also covers mobile booking, speed, accessibility, and how to measure booking conversion one step at a time.

A booking widget is a booking flow that sits inside your own website, rather than on a separate page or a third-party site. The guest stays on your page, in your design, and books without being sent anywhere else. It is usually added with a short piece of code that your website shows wherever you place it: on the home page, on a dedicated booking page or behind a button on every page.

It differs from a booking page, which lives on its own link and can be shared anywhere, and from a listing on a booking platform, which lives on the platform's site. All three can feed the same diary, and many venues use all three. The booking widget matters most for guests who are already on your website, because they have already chosen you. The only question left is whether booking is easy enough to finish.

Our pillar guide to online booking on your own site covers the whole set-up, from the diary behind the widget to the policy guests see. This guide focuses on the flow itself, screen by screen.

Booking abandonment is the share of guests who start a booking and do not finish it. Some of it is unavoidable: a guest checking availability for next month, a guest comparing two restaurants, a guest whose friend has just booked somewhere else. Much of it, though, is caused by the flow itself, and that part can be fixed.

The pattern is consistent across booking flows. Guests leave when they cannot find the booking, when the time they want is unavailable and nothing else is offered, when the form asks for more than they expected, and when the final step leaves them unsure whether they have booked at all. Each of these is a single tap, and each loses a share of the guests who reach it.

Because losses multiply, small improvements at each step add up. A flow that keeps nine in ten guests at each of four steps confirms about two thirds of the guests who start; one that keeps three in four at each step confirms about a third. The difference is rarely one big redesign. It is four small fixes, one at each tap.

The first tap is the one guests make to start booking, and the most common problem is that they cannot find it. A booking button tucked into a menu, placed at the bottom of a long page, or labelled with a vague word such as "Enquire" in small grey text loses guests before the booking widget has even opened.

Put the booking button at the top of every page, in the same place, with the same plain words, such as "Book a table". On a phone, it should be visible without scrolling, and it should stay visible as the guest reads the menu or looks at photographs. A guest who decides to book while reading about your Sunday lunch should not have to scroll back to the top to find the button.

When the guest taps the button, the booking should open where they are, quickly. Sending them to a different site, opening a new tab or showing a loading spinner for several seconds all lose guests at the very first step. The widget should feel like part of your website, because it is.

The second tap is the time. The guest chooses a date and a party size, and the widget shows the times available. This is where most booking abandonment happens on busy nights: the guest wanted 8:00 on Saturday, 8:00 is full, and the widget shows a message saying so and nothing else.

A dead end is the most expensive screen in any booking flow. The guest has already decided to eat with you and chosen the night; all they need is a time. Show the nearest times that are free, on that night and the nights around it, and offer a place on the waitlist for the time they wanted. A guest offered 7:30 or a waitlist place is still a guest. A guest shown a red message is gone.

Show times in a way that is easy to scan on a phone: large, tappable buttons in time order, not a drop-down list that hides what is available. If some times are only available for smaller parties, or only at the bar, say so beside the time rather than after the guest has chosen it. Our guide to waitlist management covers what happens to the guests who join the waitlist.

The third tap takes the guest into the details form, and every one of the booking form fields on it costs something. A name and an email address are expected. A phone number is usually accepted. A required postcode, a date of birth, a "how did you hear about us" question, a password and a page of marketing preferences are each a reason to leave.

Go through your booking form fields one by one and ask what each is for. If you do not use it before or during the visit, remove it. If you need it only sometimes, such as an occasion or a dietary note, make it optional and keep it short. Never ask the guest to create an account to book a table; a booking is not a membership.

Order matters as much as number. Ask for contact details only after the guest has chosen a time, so they have something to lose by leaving. Help the guest fill the form in: on a phone, show the right keyboard for email and phone fields, and let the browser fill in their name and email. Show errors beside the field that caused them, in plain words, as the guest types.

The fourth tap is the one that confirms, and it is where many flows lose the guests they worked hardest to keep. A slow final step, a vague message, or a screen that says "request received" when the guest expected "booked" leaves the guest unsure. Some will try again and create a duplicate; others will phone to check; a few will book somewhere else to be safe.

Make the final step quick and the outcome unmistakable. The confirmation screen should say clearly that the table is booked, for how many, on which date and at what time, and that a confirmation email is on its way. If bookings stay pending until somebody confirms them, say so plainly, and say when the guest will hear back.

Hold the time while the guest completes the form. Nothing frustrates a guest more than choosing a time, typing their details and finding the time was taken while they typed. A short hold on the chosen slot removes that disappointment entirely, and it costs the venue nothing.

Verifying the guest's email before a booking is confirmed makes every booking more reliable. Reminders reach the guest, changes reach the right person, and bookings made with a mistyped or invented address never reach the diary. Done badly, verification adds a step that loses guests. Done well, it takes a few seconds and guests barely notice it.

The simplest form is a short code sent to the guest's email and entered on the same screen. Keep the screen open while the guest checks their inbox, make the code easy to paste, and offer to resend it if it does not arrive. Explain why in a single line, such as "so we can send your confirmation and reminder", and most guests will happily do it.

Verification also pays off later. A confirmed email address is what lets a reminder reach the guest before the booking, and a link to change or cancel arrive with it. Our guide to reducing no-shows without annoying guests covers how those pieces fit together.

Most guests who book a table do so on a phone, often while doing something else: on the way home, in a queue, on a sofa with friends deciding where to go. Mobile booking is therefore not a version of the booking widget; it is the main one. Design and test the flow on a phone first, and treat the desktop view as the variation.

On a phone, every screen should fit without sideways scrolling, every button should be large enough to tap with a thumb, and the next step should always be visible. Avoid tiny calendars, drop-down lists of times and pop-ups that cover the form. A responsive layout that rearranges itself for the screen is the minimum, not the goal.

Test it on a real phone, on a mobile connection, not just in a desktop browser shrunk to phone width. Book a table yourself every month, start to finish, and note every moment you hesitate. If you hesitate, your guests do too, and some of them will not carry on.

Speed is the step nobody sees. A booking widget that takes several seconds to open, or pauses after every tap, loses guests at every step, because each wait is another chance to change their mind. Guests on a phone, on a mobile connection, feel every delay more than anyone testing on office broadband.

Keep the widget light. Load it with the page rather than only when the guest taps the button, avoid heavy images and animations inside the flow, and make sure availability arrives quickly when the guest changes the date. Google's Core Web Vitals are a useful guide to how quickly a page appears and responds to a tap.

Watch the slowest moments as well as the average. A flow that is quick most of the time but stalls when the guest changes the party size will lose guests at exactly that point. Test the slow paths, such as changing the date twice, as well as the fast ones.

Some booking flows offer more than a time: a choice of table, a celebration package, a note for the kitchen. These can make the booking better, and they can make it longer. The rule is simple: every optional step must be easy to skip, with one tap and no penalty.

Letting guests choose their own table is a genuine draw for some guests, especially for special occasions, and a good reason to book directly rather than through a platform. Keep it optional, with a clear way to skip it, so guests who do not mind where they sit are not slowed down.

Add-ons such as a celebration package or a set menu work best shown after the time is chosen and before the details form, with a clear way to move on. Guests who want them will add them; guests who do not should be able to continue in one tap. Notes, such as an allergy or an occasion, belong in one short optional field near the end.

A booking widget should work for every guest, including those who use a screen reader, navigate by keyboard or need larger text. That means a label on every field, buttons that say what they do, colours with enough contrast, and a flow that does not depend on dragging or tiny targets. The principles of web accessibility apply to a booking form as much as to any page.

Accessible design is also simpler design. Clear labels, large targets and plain error messages help every guest, especially one on a phone in a hurry. A flow that works with a keyboard alone is usually a flow that works well with a thumb.

Booking conversion is the share of guests who start a booking and finish it. To improve it, you need to know where guests leave, which means counting them at each step: how many reach the booking page, how many choose a date and party size, how many choose a time, how many complete the form and how many confirm.

Your website analytics can usually show the first steps, and your booking system shows the bookings that were made. Compare the two over a few weeks, then change one thing at a time and watch the step it affects. Our guide to booking conversion from page view to confirmed works through each number in turn.

Read the numbers by device. A flow that converts well on a laptop and poorly on a phone has a mobile problem, not a demand problem. Follow bookings past the confirmation too, because a booking that never arrives is not much better than one that was never made. Our guide to your no-show rate covers how to read it by source.

Here is an illustrative month for a booking widget, to show how small fixes add up. The figures are examples, not benchmarks.

No new marketing brought those extra 380 bookings. They came from guests who had already decided to book and were being lost by the flow. That is why the booking widget is often the cheapest place to find more covers.

In servearound, guests book on a page in your colours, with your logo and your photographs, on its own link or embedded inside your website, with the allowed domains set per venue. Guests pick a date, a party size and a time. Where you allow it, they can choose their own table from the floor plan or skip that step, and a celebration package or set menu can be offered on the booking itself. When a time is full, the booking page offers the waitlist.

The chosen time is held while the guest finishes, the guest verifies their email with a six-digit code before the booking is confirmed, and the confirmation carries a link to change or cancel. A booking taken there carries no commission. Analytics shows bookings by source, so the booking widget and the embedded widget can be compared with phone and walk-in bookings, and follows them from booked to seated. See the reservations module.

Either can work, as long as it opens quickly, fits the screen and does not hide the next step. On a phone, a full-screen flow is usually easier to use than a small pop-up.

If you call guests about their booking, yes. If you never use it, consider making it optional.

Yes, if you can take them. Same-day bookings are often guests ready to book immediately. Set the notice you need in your booking rules rather than closing the day entirely.

All the times you can genuinely take, in a grid that is easy to scan. Hiding available times to create scarcity usually loses bookings.

It helps. A booking page on its own link can be shared on social profiles, in emails and on your Google listing, while the widget serves guests already on your site.

Monthly at least, and after every change to your website or booking rules. Book a real table on a real phone, then cancel it.

A booking widget turns guests who have already chosen you into confirmed tables, and most booking abandonment happens at four taps: finding the booking, choosing a time, filling in the form and confirming. Make the button easy to find, never leave a guest at a dead end when a time is full, keep the booking form fields to the ones you use, and make the confirmation quick and unmistakable.

Design for mobile booking first, keep the widget fast, make every optional step easy to skip and the whole flow accessible. Measure booking conversion at each step, change one thing at a time, and test the flow yourself on a real phone every month.