A booking system is the front door to a restaurant, and it is the piece of software most operators think about least carefully. We agonise over the menu, the lighting and the playlist, then sign a two-year contract with whoever the last person recommended and never look at it again.
That is the wrong order of priorities, because the booking system quietly decides two things that matter more than almost anything else in the building. The first is how easily a stranger can give you their custom. The second is whether you keep any useful record of them once they have. Get those two right and the rest of your guest relationship has somewhere to live. Get them wrong and you are renting your own customers back from a company that met them through you.
I have run independent venues, and I have made most of the mistakes in this guide before writing it. So this is not a feature comparison dressed up as advice. It is the way I would choose a booking system today, in 2026, if I were opening tomorrow.
What a booking system is actually for
Ask most vendors what their product does and they will tell you it takes bookings. That is true and almost beside the point. Taking a booking is the easy bit. A spreadsheet and a phone can take a booking.
The real job of a booking system is to manage the gap between demand and capacity without losing money or goodwill, and to do it while quietly building a record of who came in. That means handling the rush of a Friday at 7pm, the slow drip of a wet Tuesday, the no-shows, the walk-ins, the big table that wants the back room, and the regular who books the same time every fortnight and would be quietly offended to be asked for a deposit.
A good booking system makes those jobs invisible. A bad one turns them into work, and worse, it forgets everyone the moment they leave.
Two shapes of booking system, two sets of economics
Almost every product on the market is one of two shapes, and the difference is not features. It is economics, and it is the single most important thing to understand before you sign anything.
The first shape is the network. These products run a consumer-facing app or website where diners search for somewhere to eat, and your venue appears in those results. The pitch is discovery: people who have never heard of you find you and book. That is a real product and for some venues it earns its keep, particularly in tourist spots, brand-new openings, or anywhere most of your covers come from people who have never been before.
The catch is how a network charges. On top of a monthly subscription, you usually pay a fee for every cover the network sends you, and sometimes a further percentage on prepaid transactions. The arithmetic feels small per booking and is anything but small over a year. A venue doing a few hundred network covers a month can pay more in per-cover fees than in subscription. The more successful you are, the more you pay, and crucially you pay it on guests who would have come back anyway. I have written more about that specific maths, and how a network compares to running your own widget, in the Grace vs OpenTable comparison.
The second shape is the tool. These products give you a booking widget that runs on your own site, your own brand on the confirmation emails, and no consumer marketplace behind them. They do not bring you discovery. They take the guests you already have, or the ones your own marketing brings in, and manage them well. You pay a flat fee, and the hundredth booking this month costs the same as the first.
Neither shape is correct in the abstract. The question is where your covers actually come from. If you genuinely depend on a marketplace to fill the room, a network can be worth its fee. If most of your covers come from people who already know you, from your own social, your own list and your regulars telling their friends, then paying per cover is paying a tax on a relationship you built yourself. Most established independents are in the second camp and do not realise it until they add up a year of cover fees.
The features that earn their place
Once you have settled the shape, the feature list matters far less than vendors want you to believe. Here are the ones I would not open without.
Deposits, applied with judgement. A deposit is a blunt instrument. Ask for one on every table and you will lose bookings from perfectly good guests who simply will not give their card details to a restaurant they have not been to. Ask for none and you carry the cost of no-shows on your busiest, most valuable services. The feature that matters is not "deposits", it is the ability to ask for a deposit on the bookings that can hurt you and waive it for the guests you trust. The large party on a Saturday gets asked. Your fortnightly regular does not. A system that cannot tell those two apart is making you choose between protecting your revenue and respecting your best customers.
Returning-guest recognition. When a guest who has been in five times books again, the system should know. It should know their usual table, roughly how long they tend to stay, and that the host should greet them by name rather than ask whether they have booked. This is the difference between a booking tool and a guest relationship, and it is the thing most systems do worst, because they treat every booking as a fresh transaction.
Table management and pacing. You need to be able to shape a service: how many covers you will take in a given window, how long you hold a table, which tables can combine. This is not glamorous and it is where a system either saves your floor team an hour a night or costs them one.
Your brand, on your domain. The booking page should look like your venue, carry your name, and ideally live on your own web address. Every time a guest books through a page that is clearly someone else's brand, you are reminding them that the relationship is with the platform, not with you.
Waitlists and cancellation handling. Cancellations are not lost covers if you have a sensible way to fill them. A waitlist that quietly offers a freed table to the next person in line, without spamming twenty people at once, turns a gap back into revenue.
Private hire and enquiries. If you do events or whole-venue bookings, the enquiries, deposits and details for those should not live in a separate inbox and a paper diary. They should sit in the same place as everything else.
The features that are mostly noise
Vendors compete on feature count, so the list gets padded. Be suspicious of anything that sounds impressive and changes nothing on a Friday night. Elaborate "guest sentiment" dashboards you will never open. Integrations with tools you do not use. Loyalty bolt-ons that do not actually connect to the bill. A long feature list is not a sign of a good product. It is often a sign of a product trying to look worth its price.
The test I use is simple. Would this feature survive a real service? If I cannot imagine my floor team using it at 8pm on a Saturday with three tables waiting, it is decoration.
Reading a quote honestly
When you get a quote, separate it into its real parts before you compare anything.
Start with the fixed monthly cost, then add the variable cost, the per-cover or per-transaction fees, calculated at your actual volume rather than a flattering example. A small subscription with per-cover fees can easily cost more than a larger subscription with none, and the gap grows as you get busier. Then look for the fees that do not appear in the headline: charges on prepayments and deposits, setup costs, the cost of leaving.
Two more questions decide more than price. How long is the contract, and what happens to your data when it ends. A twelve or twenty-four month lock-in is common and rarely in your favour. If a vendor cannot tell you plainly how you export your guests and bookings the day you leave, treat that as the answer.
The question almost nobody asks: who owns the guest?
Here is the part that took me years and several systems to understand. A booking is not the valuable thing. The guest is. The booking is just the first time you met them.
Most booking systems are perfectly happy to take a reservation and remember nothing useful about the person who made it. The name and the covers go into a list, the guest comes in, pays, leaves, and the next time they book they are a stranger again. Meanwhile your till knows what they spent, your WiFi knows they were here, your email tool has their address, and none of those facts ever meet. You have a guest in four places and a relationship in none.
A booking system should be the start of a guest record, not a silo that forgets. Every booking, every visit, every preference and every no-show should land on one record for that person, so that the second, fifth and twentieth time they book, you know more than you did the first. That is the whole argument for treating reservations as part of something larger rather than a standalone tool.
How to choose: the questions to ask any vendor
If you take nothing else from this, take these questions into your next demo.
Where do my covers come from today, and does this product change that or just charge me for it? What does this actually cost at my real volume, including every per-cover and per-transaction fee? Can I waive deposits for guests I trust while requiring them where I need to? Will returning guests be recognised, or is every booking a blank slate? Does the booking page carry my brand on my own address? How long is the contract, and how do I get my data out on the day I leave? And the one that cuts through most sales decks: which of these features would my team actually use during service?
If a vendor gets uncomfortable around cost or data ownership, you have learned the most important thing about them.
Where Grace fits
I will be straight about where we sit, because the honest version is more useful than a pitch.
Grace is not a network. We do not run a diner-discovery marketplace and we never will, so if your covers depend on a marketplace, that is a real reason to look at one. What Grace does is treat reservations as one module of a single platform built around the guest record. The booking page runs on your brand, returning guests are recognised, deposits can be required or waived guest by guest, and every booking feeds one record that the till, the marketing and the rest of the system share. There are no per-cover fees, ever. A flat monthly cost per venue, and the busiest Saturday of the year costs you the same per booking as a quiet Monday.
You can see how the bookings module works in detail on the Reservations page, and the wider thinking behind it on our restaurant booking system overview.
Grace is tested every week on a real Friday-night service at The Nuthatch, the independent restaurant I run, because if a feature cannot survive that, it does not ship. The reservations module exists because I was tired of booking tools that took my guests' details and gave me nothing back.
The short version
Decide whether you need a network or a tool, and be honest about where your covers actually come from. Read the quote in its real parts, including the fees that hide below the headline and the cost of leaving. Insist on owning your guest data. And treat the booking system as the start of a guest relationship, not a list that forgets. Choose on that basis and you will pick well, whether or not the system you choose is ours.
---
FAQ
What is the best booking system for a small independent restaurant?
There is no single best one, because it depends on where your covers come from. If you rely on a marketplace to be discovered, a network product may justify its per-cover fees. If most of your bookings come from people who already know you, a flat-fee tool that runs on your own brand will usually cost less and keep the guest relationship yours. Decide that question first and the shortlist gets short quickly.
How much should a restaurant booking system cost in the UK?
Compare the real total, not the headline. A subscription with per-cover fees can quietly cost more than a larger flat subscription once you are busy, because the per-cover charge grows with your success. Always calculate the cost at your actual monthly covers, and add any fees on deposits or prepayments before you compare two products.
Should I take deposits on every booking?
No. A deposit on every table costs you bookings from good guests who will not hand over card details to a venue they do not know. The better approach is to require deposits on the bookings that can hurt you, large parties, peak services, known risks, and waive them for guests you trust. The feature to look for is that level of control, not deposits in general.
Will I lose my guest data if I switch booking systems?
You should not, but check before you sign rather than after you want to leave. A reasonable vendor will tell you plainly how to export your guests and bookings in a standard format at any time. If a company is vague about how you get your data out, treat that vagueness as the answer.
Do I need a booking system with a diner network like OpenTable?
Only if you genuinely depend on discovery. A network earns its cover fees for venues in tourist locations, new openings, or anywhere most covers come from people who have never been before. For an established venue with a strong base of regulars, paying per cover is often paying a fee on guests who would have returned anyway. We cover that trade-off in detail in our OpenTable comparison.
Can a booking system recognise returning guests automatically?
Some can, most do not do it well. Many treat every booking as a fresh transaction and forget the person between visits. The systems worth having tie each booking to a single guest record, so by the fifth visit you know their usual table and roughly how long they stay. That recognition, not the act of taking a booking, is what separates a booking tool from a guest relationship.
---