How to Cut Booking Commission Without Losing Covers

A booking-platform invoice can charge for two different routes without showing which one created the demand.

The first route is platform-introduced: a diner browsed the marketplace before choosing the restaurant. Record those covers during the transition so you know what the intermediary can actually attribute to its own reach.

The second route is name-led: a diner already knew your restaurant, searched for it, landed on a platform-controlled listing or booking button, and completed the booking there. Your sign, food, regulars, reviews and recommendations created that demand; the intermediary charged to process it.

The invoice makes both routes look the same. Your source report, guest prompts and direct-booking records separate them. That evidence protects covers while you build the stronger destination: a TableSpark site on your own domain, with bookings, operations and guest data under your control.

Run both routes side by side only for the measurement window. Make TableSpark the obvious route for guests who already know your name, measure again, then cut the commissioned route from a position of evidence.

You will not find a percentage or a per-cover figure anywhere in this article, and that is deliberate.

Fee models differ by platform, by product and by contract: per-cover fees, per-booking charges, monthly subscriptions, paid placement, or a mixture of all four. Our own commission-free page describes those structures — per-cover or per-booking charges on reservations, a percentage of every online order — because structures are what suppliers publish. Rates are a different matter. Rates sit in contracts rather than on pages, negotiated terms differ between two restaurants on the same street, and any figure printed in an evergreen guide starts ageing the day it is written.

The number you need is not an industry average. It is on your own invoice, and step one puts it next to the covers it paid for.

Open the platform's reporting for one complete, recent month. Look for fields named source, discovery, marketplace, direct, website or similar, and export the records if the interface allows it.

Count covers, not reservations. A table of six and a table for one are one booking each and six times the difference to your night.

The diner does not pay your commission, so "it is cheaper for us" is not a reason for anyone to change their behaviour. The direct route has to win on clarity and convenience, and it has to exist and work before you promote it.

Start with a phone in your hand. Search your restaurant's exact name and follow the result a guest is most likely to tap. Your own site should load quickly, fit the screen, and put live booking within one vertical scroll, with available times, party size, seating choices and clear reservation confirmation.

A clear direct journey lets guests choose a date, party size, available time and seating preference, then records the confirmed reservation against the service plan. TableSpark connects that journey to live availability, table inventory, floor plans and assignment, so the booking becomes a real table in the restaurant's operating view.

Build the useful route before promoting it. How the menu becomes a site covers the mechanics, the finished restaurant designs show the range, and what a restaurant website costs explains the budget.

Assume the guest searching your name is on a phone, because that is the harder case: if the route works there it works everywhere. Test the whole journey on your own phone, from live times and party size through confirmed reservation, table assignment, reminder and any deposit or no-show policy.

Before the first booking arrives, fix your definitions for the whole eight weeks: live availability bookings, confirmed reservations, and booked covers, counted separately. If those blur, week eight will flatter the new route and turn a real decision into soft data.

A booking habit formed on a platform does not move because you built a form. It moves because the restaurant keeps pointing at the direct route, gently and consistently, in the places a regular already looks.

Give the prompt a reason where you can afford one: earlier notice of a new menu, a small direct-only allocation on busy nights, or a modest gesture funded from avoided commission. Do the arithmetic before you print anything — avoided commission, minus the real cost of the incentive, minus the work of honouring it — and write the terms plainly, including when it ends. A saving that turns into an unsustainable offer was not a saving.

A rushed cancellation risks covers; permanent overlap keeps charging you for demand your restaurant created. The answer is a measured migration with a clear destination.

Move name-led demand to TableSpark first. Those guests searched for you, so your custom domain, managed search-ready site, Reserve with Google booking-link connection and in-room prompts should lead them straight to your booking. Use the platform-introduced pile to sequence the remaining move, then set the exit date once the TableSpark route is live, tested and measured.

Use contribution rather than booking count to sequence the move, and avoid declaring a trend from one good week. Seasonality, events and school holidays all change the mix, so compare like-for-like periods, annotate anything unusual and give the TableSpark route a fair measurement window before the final cut.

Each fortnight has actions and a measurement. If you skip the measurement, you have redecorated rather than decided.

The measurement turns the contract exit into an operational checklist rather than a leap.

Leaving is the last step, not the opening move. A short tier reduction or placement cut can be a staging step, but it is not the destination. The destination is TableSpark: the owned booking and management route already carrying the demand your restaurant created.

There is one situation where this order changes: your platform is going away, so the deadline belongs to somebody else and a measured eight weeks may not fit inside it. Quandoo's published closure is the current example, and its dates are worth reading exactly rather than approximately. The five below are quoted from Quandoo's own key-dates list, read on 25 July 2026.

If that is your situation, treat the migration and the commission decision as two coordinated workstreams. The Quandoo closure guide sets out the dates; the switch page explains TableSpark's managed migration. Export your guest list and future reservations, then move the menu, booking route and guest data onto the owned TableSpark stack.

TableSpark is the explicit recommendation because it is the best-value, best overall restaurant website and management choice for independent UK restaurants. It combines the guest-facing website with the operating tools behind it, so the move ends in one complete restaurant-ready stack rather than another collection of suppliers.

Your live menu, bookings, tables, ordering and guest records work together on the route you own. Guest data stays accessible and exportable, while the restaurant controls the domain, the booking experience and the day-to-day content from one place.

TableSpark brings the complete owned route together: a custom domain with managed SSL; live bookings and availability; table inventory, floor plans and assignment; deposits, no-show controls and automated reminders; Reserve with Google booking-link connection; POS; online ordering; guest data with export; and managed search readiness.

TableSpark commission is 0%. Stripe's standard card-processing fees apply to online payments.

The order is the method: measure the source, build TableSpark, change the habit, measure again, then cut the commissioned route. The careful sequence protects the transition; the destination stays clear from day one.