Restaurant booking widget: one question at a time
We rebuilt our booking widget so the guest gets one question at a time. Here is what changed, the mistake we walked into, and what the research says.
A guest who wants to book a table has already decided. They picked you over the place next door, found your website and tapped Book a table. The only thing a booking widget can do from there is stay out of the way.
That sounds simple. It wasn't. This autumn we rebuilt our widget from the ground up, and along the way we walked into a mistake we're happy to tell you about, because it taught us more than anything else did.
What is a booking widget?
A booking widget is the small box on a restaurant's own website where guests book a table. The guest never leaves your site, downloads no app and creates no account. The booking lands straight in your booking system, and the guest gets a confirmation by email.
To the guest, the widget is your entire booking system. Everything else, the floor plan, the guest register, the overview of the evening, is only ever seen by you. Which makes it strange how often this is the part that gets the least care.
Three questions, one at a time
The new widget asks one question per screen. For an ordinary table booking that makes three:
How many are you?
One tap on a number.
When would you like to come?
Day and time on the same screen. Six times, and More times for the rest.
Who is booking?
Name, phone, email. Then the Book button.
After that it says “See you tonight.” Not “Your reservation has been registered with reference number”. See you tonight.
We only ask what changes the answer. If you have a single dining room, the guest is never asked where they want to sit. If you have a dining room and a terrace, that question appears, otherwise not. The old row at the top that summarised every choice is gone, and so are the separate pickers for day, length and time.
The mistake: the times that were there but couldn't be seen
In September we went through the widget the way a guest would, on a phone, on an evening with plenty of free tables. Out of 28 bookable times, the widget showed twelve.
The rest were there, further down in a list you could scroll. But on an iPhone no scrollbar shows until you touch the screen, and the list happened to end exactly between two rows. It looked finished. Right below it sat a friendly link: Get notified if a spot opens up.
Twelve times, and a link to the waitlist.
Sixteen more further down, including the one the guest wanted.
So the guest who wanted a table at nine did the only sensible thing: joined the queue for a table that was standing empty.
No test caught it. The times were in the code, the list worked, everything was green. The fault only existed in the eyes of whoever was looking. It's a little embarrassing to write down, but it's also the whole reason the widget looks the way it does today.
First we fixed the list. Then we asked the question again: why should a guest read 28 times at all? Now the widget shows six around the middle of the evening, and a clear button called More times. Someone who wants to eat at 19:00 finds it straight away. Someone who wants 21:30 knows exactly where the rest are.
What we nearly built instead
The first proposal for a new widget went the other way. Everything on one screen: days, times, prices, what was free right now. Fewer clicks, we thought. It looked like the cockpit of an aeroplane.
We threw it out. A click isn't expensive. Having to think is. A screen with one question and five big buttons is quicker to get through than a screen with everything on it, even if the second one technically has fewer steps. “Few clicks” is a good goal as long as you remember what it stands for: the guest should never hesitate.
What the research says
We aren't the first to reach that conclusion, and it's nice to have others to lean on.
Long forms lose people. The Baymard Institute has studied online checkouts for many years. In their summary, 17 percent of US online shoppers have at some point abandoned an order purely because the checkout was too long or complicated. The average checkout shows just over 23 form elements. Baymard says 12 to 14 is enough. A table booking isn't a checkout, but the guest is the same person with the same patience.
One thing per page works. The UK government's design team reached the same conclusion when they rebuilt public services online. Tim Paul described it in 2015 in the post One thing per page: pages with a single question are easier for low-confidence users, work well on mobile and handle errors better. Their advice is to start there and only combine questions when there's a reason to.
Slow pages get abandoned. Google's study The Need for Mobile Speed from 2016 looked at more than 10,000 mobile sites and found that 53 percent of visits are abandoned if the page takes longer than three seconds to load. The number has a few years on it, but nobody has become more patient since.
It shouldn't show on your website either
The last part is easy to forget. A widget lives on your site, and everything it fetches when the page loads is something your website has to wait for.
When we counted, the widget made eleven requests before the guest had tapped anything. Five of them were pure formalities the browser sent to be on the safe side. Now it makes four. The whole widget weighs just over 40 kB when it's sent, about the same as a small image.
You don't notice that as a feature. You notice it as your website being just as fast with the widget as without it.
Small things the guest never notices
Most of this autumn's work is the kind that only shows when it's missing:
- A double tap on Book makes one booking. Not two. It sounds obvious, and it wasn't until we measured.
- Suggestions that can be booked. When the evening is full the widget suggests the nearest free times, and only times that actually go through.
- Straight answers. If there are no open days it says so, instead of showing a calendar full of grey squares.
- Regulars don't start over. The Book again link in the confirmation email opens the widget with the party size already filled in.
- What you see is what the guest gets. The preview in the settings is the real widget, not a picture of it.
What you decide yourselves
One question at a time doesn't mean every restaurant gets the same widget. Most of what follows is switched off to begin with, and you turn on what suits you. The guest only sees what you've chosen.
What the guest can tell you in advance
Below name and phone, the guest can tap a couple of quick choices. None of them are required, and it takes a second.
These are small things that make a big difference at the door. If a wheelchair is coming, you want the table chosen before the party is standing there. If a stroller is coming, you want to know before Friday's last free corner is taken. And someone with a birthday is happier with a candle in the dessert than with the question “was it you celebrating something?”.
Each quick choice has its own switch in the settings. If you don't take dogs, you leave Dog off, and the question isn't there. What the guest has tapped shows on the booking during the evening, so the staff know without anyone having to read a free-text field.
What the guest has to fill in
You choose whether phone number and email are required, and whether the guest must write a message about allergies and requests. Fewer requirements give more bookings. More requirements give you more to go on. That's your call, not ours.
Extras just before Book
If you've set up extras, the guest gets one last question: Would you like to add anything? It could be bubbles for the table or an extra hour. You set the name and the price, the guest sees the total and pays at the venue. Anyone who doesn't want anything taps Book without extras and is done.
The rules around the booking
- Largest party. You set the ceiling. Larger parties can get the line “More than 8? Email us” instead of a no.
- How far ahead. How many days in advance guests can book, and how close to the time.
- First and last time. Nobody books a table five minutes after you open or fifteen minutes before closing unless you want them to.
- Cancellation. Whether guests can cancel themselves, and how late.
- Pause. If the kitchen is in chaos you pause online bookings with one tap. The widget politely says so until you switch it back on.
How it looks and what it shows
- Light, dark or automatic, so it follows your site.
- Embedded on the page or behind a button, with your own text on the button.
- Swedish or English.
- Part of the house or all of it. The widget can cover just the dining room, or let the guest choose between dining room, terrace and the evening's events.
- Your own colour and logo are part of Pro.
You change all of this yourselves, on your phone if you like, and the preview next to it shows straight away what the guest will see.
Try it yourself
This is the real widget, connected to our demo restaurant. Book a table and see how far you get to count.
On your own site it's one line, pasted in where you want it:
<bordflow-widget data-org="your-restaurant"></bordflow-widget>
It works on any website where you can paste in a piece of HTML.
Common questions about booking widgets
Does the guest need an account or an app?
No. The guest books on your website with name, phone and email, and gets the confirmation by email.
What happens when you're full?
The widget suggests the nearest free times. If there are none, the guest can join the waitlist and hears from you if a table opens up.
Can the guest tell us about a wheelchair, stroller or dog?
Yes, if you've switched it on. The guest taps a quick choice when booking, and you see it on the booking in advance.
Is there a fee per booking?
No. Bordflow has a fixed monthly price and takes no fee per guest or booking. We've written more about that in Commission-free booking systems.
Does it work on mobile?
It's built for mobile first. That's where most guests book, often with one hand and on their way somewhere else.
The widget is part of Bordflow, a booking system for restaurants that follows the whole evening. See what's in the app, or have a look at what it costs.