Choose a Restaurant Table Booking System

Picture a Friday at half past seven, with the diary showing 38 of your 40 seats booked, so the host has been telling walk-ins there is nothing until nine. Two tables of four have not arrived and nobody rang. A party of six was taken by phone and written in as "6, 8pm", with no table against it, so the only table big enough is already sitting under a party of two who arrived early. The kitchen has prepped for a full room, and three couples have already left the doorway for the place down the road.

Nothing in that scene is a dramatic failure; it is a headcount problem. A diary, a spreadsheet or a basic booking widget knows how many people you expect, not which table each of them needs, how long that table is held, or whether a party of six can be seated without breaking up a table of four. Each gap costs covers, and a cover lost on a Friday is not sold afterwards.

The scale of the wider problem is well documented. Zonal's 2024 no-shows report, a survey of 5,000 hospitality consumers carried out with CGA by NIQ, says no-shows cost UK hospitality "a collective £17.6bn a year in lost sales" and that the rate "has risen from 12 to 14% over the course of the year". Dine Out Magazine, reporting the same research on 5 November 2024, puts the 14% as guests "failing to honour bookings or inform venues in advance that they need to cancel". Read that scope carefully. It is a share of surveyed guests who admit to not turning up without telling the venue, and the £17.6bn is a sector-wide figure for hospitality. It is not a share of your bookings and it is not a prediction for your restaurant. Your own diary is the only source for that.

You can work out what your own rate is worth with a sum you can edit. Take a 40-seat restaurant that serves dinner six nights a week and averages 30 bookings a night with a party of 3, which is 90 covers a night. Suppose 5% of those covers do not arrive. That 5% is an assumption for the illustration, not a Zonal figure. It is 90 × 5% = 4.5 covers a night. At an average spend of £30 a head, which is also an assumption you should replace with your own, that is 4.5 × £30 = £135 a night, £810 across six nights, and £42,120 across 52 weeks if every week looked the same.

The no-show is one of three leaks. The second is the table that does not fit: a party of six on a table for four, or a table for two held by a party of two while a larger group is turned away. The third is the price of the tool itself. Some products charge a monthly fee, some stop at a cap and push you to the next plan, and some charge per cover, so the bill rises on your busiest nights.

So the useful question is which system books against the tables you actually have, helps guests turn up or cancel in good time, and costs a figure you can predict, on a website Google can find.

A system that books a headcount holds one number for the room. One that books tables holds a map of the room and a set of rules, and checks both every time someone asks for a slot. Four parts do the work.

Opening hours say when your doors are open. A service is the sharper rule underneath: Lunch, Dinner or a Sunday sitting, each with its own first and last seating, a slot interval of 15, 30 or 60 minutes, a capacity, party limits and a default length of stay. TableSpark's tutorial describes a service as the rule that tells the booking engine "when it takes reservations, on what interval, and up to what capacity". Without services, a lunch rush and a quiet dinner share one set of rules.

Each service also carries its own party limits, a lead time for guests booking online (your own team can still book anyone who rings), and a book-ahead limit so a sitting does not quietly accept a reservation for next year. A longer stay can be set for large parties, so a table of eight is not released at the time a table of two would leave.

On the floor plan, every table has a label, a minimum and maximum number of seats, a shape, a zone and a room, and it can be marked combinable with other tables in the same zone. When the service counts capacity by table, the engine hands out specific tables. A party of six is offered a table that holds six, or two tables that combine, and not a table for four.

When your team adds a phone booking, the table defaults to Auto, and a mini floor plan lets staff choose. On the picker, free tables show green, tables already booked at that time show grey with the clashing time, and tables free but the wrong size for the party show amber, still clickable for the night a table for two legitimately goes on a table for six. A genuinely full slot offers the nearest open times instead of quietly double-booking you.

A table for two on a quiet Wednesday should confirm itself. A private room for ten on the weekend before Christmas should reach you as an enquiry you approve. The useful setting is one you choose service by service. In TableSpark, enquiries land in the Inbox with the seating preference, the occasion and the guest's own message, and a confirmed booking moves to the diary.

What happens after the booking matters as much as the booking. A confirmed booking should send a confirmation and a reminder, move through arrived and seated on the night, and finish as completed or as a no-show that is recorded, not deleted. The record follows the guest: next time they book, you see the prior no-show on the booking row.

A walk-in waitlist belongs in that same engine: a party that turns up unbooked is added with a name, party size, phone number and quoted wait, then notified or seated through the same logic.

Operators reach for the deposit first. The Zonal and CGA research is worth reading before you do. Asked what would make them less likely to miss a booking, surveyed guests ranked a simple cancellation process first at 30%, rewards or incentives at 28%, reservation reminders at 25% and deposits fourth at 21%. Guests could name more than one thing, so the percentages do not add to 100. They put the cheap tools, an easy way to cancel and a timely reminder, ahead of the one that adds friction at the moment of booking.

Among guests who admit to no-showing, the same report says 29% cite cost as the main reason, which is a warning that a heavy deposit may push away guests who would have come.

A reminder the day before gives a guest an easy moment to cancel, and a cancellation you know about releases the table. In TableSpark, every confirmed booking gets a plain reminder email the day before restating the date, time and party size, and the confirmation opens a View or change booking page in the guest's own account. From the diary, staff can also copy the guest's self-service view and cancel link and send it by text or email. Reminders and deposits are on the Growth plan and above.

A deposit takes payment when the guest books. A card guarantee holds the card details and charges nothing unless your team marks the booking a no-show and then confirms the charge themselves. In TableSpark both are set on the service row as a pair: a party-size threshold and an amount, each amount between £1 and £500, and if both are switched on the deposit takes priority. The guest is never billed automatically for running late or calling to cancel.

A plain card authorisation is not the same thing. Stripe's documentation says the amount is "typically on hold for 7 days for online payments", so a hold placed at the moment of booking would usually have lapsed before a visit booked more than a week ahead. It is a reason to think about which mechanism you are actually buying: a captured deposit, card details held for a later confirmed charge, or a short-lived authorisation.

Count the card fee either way. On Stripe's UK pricing page, standard UK cards are "1.5% + 20p". A £25 deposit on a standard UK card costs 1.5% of £25, which is 37.5p, plus 20p, so 57.5p. Stripe's page also lists "£20.00 for each dispute you receive", so keep your policy wording clear.

The legal guardrails are plain enough to build into your wording. Under regulation 28(1)(h) of the Consumer Contracts Regulations 2013, the 14-day cancellation right does not apply to "catering or services related to leisure activities, if the contract provides for a specific date or period of performance". A table booked for a date and time fits that description, but fairness rules still apply. The Consumer Rights Act 2015 says an unfair term "is not binding on the consumer", and its grey list includes a term requiring a consumer to pay "a disproportionately high sum in compensation". GOV.UK's unfair-terms guidance, updated on 22 July 2026, says fairer terms set non-refundable prepayments or cancellation charges so they "reflect a genuine estimate of what you will lose directly because of the customer cancelling".

Section 50 of the same Act treats what you say about the service as part of the contract if the consumer takes it into account, so show the deposit amount, deadline and refund rule before the guest pays.

A booking system is only useful if guests can reach it. Many reach it from Google, not from your site, so there are two separate jobs: a booking destination next to your listing, and a website that Google can read.

A Reserve with Google booking-link connection publishes a booking destination for your listing. It is a link to the destination you configure, so be clear which system you are sending guests to and check where those bookings arrive before you promote the link.

A booking page can be live at a working address and still be absent from Google. A robots.txt rule or noindex tag in the wrong place, conflicting canonical URLs, a page nothing links to, a menu locked inside an image, or an unverified Search Console property can each leave important pages undiscovered, excluded or misunderstood. The cost is concrete: a guest searching your name, cuisine or menu may land on a directory or a commission-charging marketplace first, and you end up paying to reach people who were already looking for you.

Google's own documents are specific. Its robots.txt page says a robots.txt file "is not a mechanism for keeping a web page out of Google", and its noindex page warns that if a page is blocked by robots.txt "the crawler will never see the noindex rule". Its LocalBusiness structured data page lists address and name as required and menu, servesCuisine, openingHoursSpecification, telephone and priceRange among the recommended fields. The sitemap overview is honest in the other direction: a sitemap "doesn't guarantee that all the items in your sitemap will be crawled and indexed", and a site of about 500 pages or fewer is "small". A small restaurant site depends less on a sitemap than on being crawlable, consistent and linked.

This is why search readiness belongs inside the website. TableSpark bundles it into every plan: crawlable menus and pages as real HTML, SEO titles, descriptions and canonical URLs, sitemaps and robots controls, Restaurant and LocalBusiness schema, internal links, mobile-first output, and managed search-verification setup, with the sitemap submitted to Google Search Console on every publish. TableSpark's own wording applies: "Indexing and ranking remain decisions for Google." Nothing here promises a ranking. It removes set-up errors that would otherwise get in the way, without you hiring a technician to assemble them.

The same applies to a booking widget added to a general website builder. The widget may work, but structured restaurant data, a clean canonical and a link from your home page are separate tasks, and on an entry-level plan they fall to you or to someone you pay.

Booking products charge in three broad ways, and the entry price rarely tells you which one you are buying.

• A flat monthly fee. The fee depends on the plan, not on how many tables you fill. This is the easiest to budget.
• A flat fee with a booking cap. The plan stops at a number of covers or reservations, then either charges for each extra one or asks you to move up a plan.
• A fee per cover or a marketplace commission. The bill rises with every guest you seat, so it grows fastest on the nights you are fullest.

On top sit the extras: payments or deposit add-ons, a Reserve with Google add-on, SMS messages, card fees, and the website your guests book from.

Here is a worked example, with every input open to editing. Take the same 40-seat restaurant: 30 bookings a night, six nights a week, a party of 3. That is 30 × 6 = 180 bookings a week, and 180 × 52 ÷ 12 = 780 bookings a month. At 3 covers each, that is 780 × 3 = 2,340 covers a month. The figures below come from each provider's current pricing page, checked on 8 October 2026, and are quoted as printed.

• simpleERB lists Starter at "£ 21 /month" for up to 300 covers, Plus at "£ 47 /month" for 1,200 covers and Pro at "£ 80 /month" for unlimited covers. At 2,340 covers a month the two lower plans are below your volume, so Pro is the plan to price: £80 a month, £960 over twelve months, or £864 with the 10% yearly discount the page describes. The page adds that payments and card capture are "a small extra cost" on Starter and Plus, and that your payment provider charges a transaction fee on all payments processed.
• Tablein lists Starter at "GPB 60" (the page's own spelling) for 50 reservations with £0.67 for each extra, Growth at "GPB 105" for 150 with £0.37 for each extra, and Success at "GPB 157" for unlimited reservations. Treating one booking as one reservation, 780 a month cost £60 + 730 × £0.67 = £549.10 on Starter, £105 + 630 × £0.37 = £338.10 on Growth, or a flat £157 on Success, which is £1,884 over twelve months.
• Favouritetable lists FT Free as "£ Free for life" for up to 30 bookings a month, FT Flex at "£2* per cover", and three fixed plans, FT Pro at "£129 per month", FT Ultimo at "£199 per month" and a lower FT Lite tier. The page also says "No Commission, No Per-Cover Fees, No Tie-ins" while listing the per-cover Flex plan, so read the terms behind each plan. At 150 covers a month £2 per cover is £300 and at 780 covers it is £1,560; at 2,340 covers it is 2,340 × £2 = £4,680 a month, or £56,160 over twelve months. FT Lite is listed at £69.00 a month, and the page does not say whether that is excluding VAT; its limits were not captured in this research, so ask what it includes.
• resOS says it "never charges per booking, per cover, or any commission". Its GBP pricing data shows the Unlimited plan at "£60" in a first-month promotion marked "-50%", against an original "£119", with "£93" for annual billing. Deposits sit in an Online payments add-on at "£9.99 /month", Reserve with Google in an add-on at "£6.99 /month", and SMS at "£0.04 /SMS". On the original monthly figure, Unlimited plus the two add-ons is £119 + £9.99 + £6.99 = £135.98 a month, before any SMS.
• Access Collins says "From £149 per month. Up and running in two weeks." The page does not state a contract term. £149 × 12 = £1,788.

These prices are not like-for-like, because providers charge for different things: some price by cover cap, some by booking, some by plan with paid add-ons, and only one row also includes the website your guests book from.

Now the worked month, with the plan you would actually need at 780 bookings and 2,340 covers:

Again these are not like-for-like: the sums leave out card-processing fees, VAT treatment where a page does not state it, and the website, menu and search set-up that a booking tool alone does not provide. The honest comparison is the whole stack, not the first number you see.

TableSpark starts at £19 a month excluding VAT for the website, live menu, guest records and managed search readiness, and the plan that carries bookings against real tables is Growth at £39 a month excluding VAT. This is one plan, one login and one invoice, with no fee on any cover.

A booking made from your own website and your own Google listing arrives without a marketplace fee and leaves the guest in your own records. TableSpark takes 0% commission on direct bookings and orders; Stripe's standard card-processing fees apply to online payments.

A booking widget does not make a restaurant ready to take bookings. Four areas decide whether the set-up holds up.

Policy and law. Write a cancellation and deposit policy in plain words where the guest books: amount, deadline, refund rule. Put your business details on the site too. Regulation 6 of the Electronic Commerce (EC Directive) Regulations 2002 asks a service provider to make its name, geographic address and contact details, including an email address, available in a form that is "easily, directly and permanently accessible". A limited company must also show its registered name, place of registration, registered number and registered office address on its website, under regulations 24 and 25 of the 2015 Names and Trading Disclosures Regulations. Sole traders and partnerships follow different rules. Match your cookie banner to what the site does: regulation 6(1) of the Privacy and Electronic Communications Regulations 2003 says a person "must not store information, or gain access to information stored, in the terminal equipment of a subscriber or user", subject to its exceptions.

Payments. Use a payment account you control; TableSpark's online payments settle into the restaurant's own Stripe account. Count the card fee: 35p on a £10 deposit and 95p on a £50 deposit on a standard UK card, at Stripe's published 1.5% + 20p. If you cancel a booking yourself, refund the deposit.

Guest data. Keep guest records in your own account, visible in an Inbox and a guest list, exportable as CSV, with each guest's history, including prior no-shows, on the booking itself. Decide in advance how you will answer a guest who asks for their details to be exported or deleted.

Search readiness. Crawlable booking pages, one canonical URL each, schema, a sitemap, Search Console verification, and a link from your home page and Google listing so the page is not orphaned.

The real choice is where bookings are made and who holds the guest relationship.

Neither route has to be absolute: a restaurant can sit on a marketplace and still send regulars to book direct. The table describes the default.

The route below follows the screens in TableSpark's tutorials for hours and booking rules and for running your bookings. Bookings, floor plans, deposits and reminders are on the Growth plan and above. Allow around twenty minutes.

• Mark a no-show instead of deleting a booking, so the count shows on the guest's next booking.
• Use Closed all day or Cap covers under Reservation closures and exceptions for a private event, so the diary closes without closing your walk-in trade. A closure wins over a cap.
• After you save bank holiday dates in Settings, check your Google Business Profile's special hours, because Google does not read that page automatically.
• Use Export CSV on the Guests page before you need it, so you know what the file looks like.

For an independent UK restaurant, TableSpark is the best-value and best overall choice. It books against your real tables and floor plan, with services, party limits, deposits, card guarantees and reminders set per service. It sits on a website built to be found, with crawlable menus, canonical URLs, sitemaps, schema and managed search-verification setup, and it keeps your guest records in your own account, exportable as CSV. It does this on one plan with no fee on any cover.

TableSpark starts at £19 a month excluding VAT. Bookings, floor plans, deposits and reminders begin on Growth at £39 a month excluding VAT, and Full is £69 a month excluding VAT when you add direct online ordering. Pay for 10 months and use 12 if you prefer to pay yearly. You build and review the site before you pay. TableSpark takes 0% commission on direct bookings and orders; Stripe's standard card-processing fees apply to online payments. Start with the restaurant table booking system page, draw your floor plan, and put your first service live.