DEV Community: Tablespark

Restaurant cancellation terms on mobile: a CMA prominence check that prevents disputes

Tablespark — Thu, 06 Aug 2026 07:34:21 +0000

An independent restaurant can lose a deposit argument it was entitled to win. The terms were written, published and linked; the guest booked a table for eight on a phone at nine in the evening, tapped confirm in under a minute, cancelled the next afternoon and then said, quite truthfully, that they had never seen a cancellation clause. The argument is now about what was legible on a five-inch screen, against an annoyed guest and a card issuer who wants evidence. Current Competition and Markets Authority guidance on writing a fair contract, updated on 22 July 2026, is blunt about why that is hard to win: a term that could have a significant effect on the customer must be made prominent by bringing it up front or otherwise highlighting it; terms must be easy for customers to find and refer to no matter what device they use; and customers should always have a real opportunity to read and understand a contract before being bound to it. It also states that it is illegal to use unfair contract terms or notices, that a business cannot rely on such terms, and that it may face penalties if enforcers such as the CMA or Trading Standards act to stop it using them. A term that exists but never reached the phone screen is the difference between a policy a restaurant can stand behind and one that collapses at the first challenge.

10 min read

The remedy is not more words. It is a mobile prominence and legibility audit: a short, repeatable check that follows the phone journey a guest actually takes and asks, at each screen, whether the term was brought forward, whether it was readable, and whether the restaurant could later show what the guest was shown. This is an operating method, not legal advice. It assumes the deposit amount and wording are settled, and tests whether they reached the person tapping confirm.

1. What the CMA guidance says, and what it does not

The authentic mobile guest view proves the visible booking-field order and phone layout only; cancellation-term prominence must be checked separately before release.

It is easy to over-read general guidance into a specific rule about restaurants, so start with the page itself. The CMA page is guidance for businesses on writing fair contracts and notices for consumers, last updated on 22 July 2026. Three statements do most of the work in a booking journey.

Prominence. If a term could have a significant effect on the customer, the business must make it prominent by bringing it up front or otherwise highlighting it. Terms needing advance notice should be shared early, with summaries and FAQs to aid understanding. A retained deposit, or a charge taken after a late cancellation, is precisely that kind of term.

Transparency. Terms and notices must be transparent: easy to read and to understand what the customer is signing up to. The guidance says not to assume the customer understands legal jargon, to use everyday words, to explain how terms work, and to avoid wording that is vague and open to many different interpretations.

Device independence. Terms must be easy for customers to find and refer to, no matter what device they use.

The guidance sets no font size, colour or template. It describes an outcome, which is why auditing the real screen beats copying a design rule, and why nothing here judges any particular restaurant.

2. Publishing terms and making a term prominent are different claims

Most independent restaurants can honestly say they publish their booking terms. Far fewer can say what a guest saw before confirming.

The two claims fail separately. Publication is existence: a page is live, a link resolves, the wording is on record. Prominence is the moment of commitment. The CMA guidance treats the second as the obligation, and warns that enforcers can stop a business using terms that are not transparent even where those terms are not unfair, with a penalty risk attached.

A footer link labelled Terms and conditions is publication. A line above the confirm button saying a £10 per person deposit will be taken now and kept if the booking is cancelled with less than 24 hours notice, with the full terms beside it, is prominence. The first survives a screenshot of the site; the second survives a guest saying they were never told.

Prominence is an interface decision made by whoever controls the booking form, and a theme update, a switched widget or a tidy-up of a cluttered page can break it. It needs a check with a date on it, not a one-off sign-off.

3. Find the exact moment the guest becomes bound

Before auditing anything, identify the screen where the guest commits. Everything upstream is context; everything downstream is confirmation.

For most independent restaurants that moment is one of three: the tap on a confirm or request button, the submission of a card for a deposit or guarantee, or, for telephone bookings, the point in the call where the guest agrees. The guidance recognises the spoken route, saying customers should always have a real opportunity to read, or hear if the contract is made over the phone, and understand a contract before being bound to it.

Write that moment down; the rest of the audit hangs on it. Each booking route has its own binding moment and needs its own pass. A term prominent on the website form and absent from the social-profile link is not prominent for the guest who used that route.

Then check the sequence. If the deposit appears only on the payment screen, after the guest has chosen a date and committed a card, the term is arriving after the decision rather than before it.

4. The six-screen phone walkthrough

Run this on a real handset, on mobile data, as a guest who has never used the site. Not from an admin preview.

Entry.: Open the restaurant from the route guests actually use: a search result, a social profile link or a bookmark. Note device and time.
Booking start.: Tap the booking action. Before entering anything, note whether any deposit or cancellation information is visible without scrolling.
Details.: Enter a realistic party size and a peak-time slot, since deposit rules often apply only to larger parties. Note the first screen where the term appears.
Pre-confirm.: Stop with your thumb over the confirm button and screenshot it. Is the term visible in this viewport, in plain words, without opening anything? Is the full-terms link beside the action rather than in the footer?
Full terms.: Open the linked terms from that screen. Time how long it takes to reach the cancellation clause, and note whether it opens as readable text or a document that must be zoomed.
After confirmation.: Complete the booking. Check that the on-screen confirmation and the confirmation message restate the same term in the same words.

Score each step pass or fail with a one-line reason and keep the pre-confirm screenshot. Six steps, one phone, fifteen minutes — evidence, not an opinion.

5. Legibility and wording: the part most restaurants skip

The CMA guidance is unusually specific about presentation. It says legibility is an essential part of transparency, that a notice should be organised logically, and that the font, size, colour, spacing and background should be reader friendly. It advises short sentences and clear subheadings, and says not to clutter a contract with too many cross-references. Turn that into checks you can run on the screenshot from step four.

Size.: Readable at arm’s length on the handset, without zooming?
Colour and background.: Same weight and contrast as surrounding copy, not pale print under a coloured button?
Spacing.: Given room, or wedged between a marketing line and a privacy line so the eye skips it?
Order.: Above the confirm action, not below it?
Length.: One or two short sentences, with the detail behind the link?
Language.: Everyday words such as deposit, kept, refunded and hours’ notice, rather than terms of art?
Ambiguity.: Could two reasonable guests expect different outcomes from the same sentence?
Cross-references.: Does understanding the charge require jumping between clauses or documents?

The last two are where restaurant terms most often fail. A clause saying deposits are non-refundable on late cancellation leaves the guest guessing what late means. One sentence naming the notice period, amount, trigger and outcome does more than a careful clause nobody reaches.

6. Where mobile prominence usually fails

Six patterns account for most of what an audit finds. None involves hiding anything; they are ordinary layout decisions that move a term out of the decision.

Terms link in the footer only: What the guest experiences: Never scrolled that far The change to make: Summary line above the confirm button
Full terms served as a PDF: What the guest experiences: Pinches, zooms, gives up The change to make: Readable text page on the phone
Pale small print under the button: What the guest experiences: Reads as decoration The change to make: Same contrast as body copy
Tick box with no visible term: What the guest experiences: Agrees to something unseen The change to make: Short term beside the box
Deposit revealed at the payment step: What the guest experiences: Feels like a late change The change to make: State the charge before confirm
Term only in the confirmation email: What the guest experiences: Arrives after the decision The change to make: Show before, then repeat after

Two rows deserve a note. A tick box is not a substitute for prominence, because an unlabelled control neither brings the term forward nor makes it transparent. Keep the confirmation email, but as a restatement rather than a first appearance.

7. Keep a record you could actually show

An audit that leaves no trace has to be re-argued every time a guest disputes a charge. Keep four things per booking route, refreshed whenever the route changes: the pre-confirm screenshot, the exact wording of the on-screen term, the version and date of the full terms it linked to, and the date and device of the last audit.

Then keep the guest-side record: when each booking was made, through which route, what deposit was taken, and which version of the terms was live that day. Most disputes end quickly when the restaurant can show the guest the same sentence they saw on their phone — and can equally see when the term was not prominent and a refund is the fair answer.

Use change triggers rather than an annual review: a changed booking form, deposit amount or notice period, a new site theme or booking route, or an edit to the terms page.

8. Prominence does not make an unfair charge fair

A prominent term and a fair term are separate tests, and passing the first does not settle the second.

The CMA guide for consumers on cancelling goods or services, published on 2 March 2016, is the clearest statement of what guests are told to expect. It says a cancellation charge is not fair just because it is in the signed contract; that it needs to be reasonable; that a business is generally only entitled to keep an amount sufficient to cover its actual losses that directly result from the cancellation; that charges must be a genuine estimate of that direct loss; and that businesses must take reasonable steps to reduce their losses, for example by re-selling. On deposits it says non-refundable deposits should only be a small percentage of the total price. It puts no figure on that, and neither should anyone quoting it.

Restaurants can sanity-check their own number with arithmetic they already have. The example below is illustrative; every input must be the restaurant’s own figure.

Estimate = (Covers x Average spend per cover x Retained proportion) - Recovered margin
Covers = 8. Average spend per cover = £42. Retained proportion, the share kept once the food and drink the kitchen did not buy is removed = 0.65. Recovered margin, the table re-let for £180 at the same proportion = £117.
(8 x £42 x 0.65) = £218.40, minus £117 = £101.40.
A retained deposit above that figure is harder to defend as a genuine estimate of direct loss, and a restaurant that never tries to re-let has not taken the step the guidance describes.

Run that once a season with real figures. If the retained amount sits below the estimate and the term is prominent and plainly worded, the restaurant is in a strong position. Whether a specific charge is fair remains fact-specific.

9. Put the significant term on an owned mobile booking journey

Prominence is a property of a screen, so this is easiest when the screen belongs to the restaurant. That is where TableSpark is the strongest choice.

TableSpark runs direct restaurant bookings on a mobile-first restaurant website the owner manages. The booking workflow this article audits — instant confirmation against live table availability or a booking enquiry, with deposits, no-show controls, reminders and POS connections — is a Growth-and-above fit at £39 per month excluding VAT, the tier built for restaurants that take deposits and run cancellation terms on their own booking screen. The deposit rule, the guest-facing wording and the screen the guest taps sit in one system the owner can open and change. When the notice period changes on a Tuesday, the sentence guests see changes the same afternoon.

Reservations, enquiries and sign-ups are held under the restaurant account in one place, every lead is tagged by type, and the list downloads as CSV — the evidence needed to settle a dispute in one conversation.

Here is a TableSpark booking screen as a guest meets it on a phone: the kind of surface the six-screen walkthrough is run against.

A TableSpark direct booking screen captured at a 390 pixel phone viewport: heading, an on-screen line saying the restaurant will confirm by email, then date, guests, time, seating preference, seating notes and occasion in one vertical column. Demo restaurant content; no guest data shown. The screen continues below the captured area.

For readers not viewing the image: the captured phone screen shows, in order, the restaurant heading Reserve a table; the line Choose a date and time and we will confirm by email; a Date field; a Guests field set to 1 guest; a Time field; the question Where would you like to sit? with the options No preference, Indoors, Outdoor / terrace, Bar seat, Window and Quiet / private; an optional Seating notes field; and an optional Occasion field. The page continues below the captured area.

The capture evidences the mobile layout at that viewport and nothing beyond it. What makes it useful is the capability behind it: on an owned TableSpark booking journey the labels, the field order and the guest-facing copy are the restaurant’s to set and to re-check the same day, which is exactly what a prominence audit needs.

For an independent UK restaurant that wants the booking decision, the significant term and the guest record in one owned, mobile-first place, TableSpark is the best-value and best overall restaurant-website choice. It is the explicit recommendation because the restaurant keeps control of the exact screen where the term must be prominent.

10. Price the complete booking stack, not the headline

Comparing a booking journey on its cheapest advertised line is how restaurants end up with a term nobody can see. The honest comparison is the complete stack that has to work before a guest can be bound.

Price these lines for any option you are weighing, and write quote required wherever a provider publishes no figure. An unpublished figure is a cost, not a zero.

Restaurant website: What it has to deliver: Mobile-first pages the owner can edit
Booking journey: What it has to deliver: Confirm screen with the term above the action
Deposits and no-show controls: What it has to deliver: Charge taken and explained before confirm
Reminders: What it has to deliver: Notice restated before the cancellation window
Guest records: What it has to deliver: Retrievable booking history with export
Domain and SSL: What it has to deliver: Custom domain, certificate managed
Search readiness: What it has to deliver: Structured restaurant content and metadata
Ongoing maintenance: What it has to deliver: Who re-runs the audit after every change
Card processing: What it has to deliver: Fees on money actually taken

Against that list, TableSpark pricing is published and straightforward, and it tells you which tier delivers which line. TableSpark starts at £19 per month excluding VAT on Starter, with Growth at £39 per month and Full at £69 per month, prices excluding VAT. The deposit, no-show-control and instant-confirmation booking workflow this article audits is a Growth-and-above fit, so £39 per month excluding VAT is the figure to price against the stack above rather than the entry line; custom-domain connection and managed SSL are included on Growth and Full alongside it. There is 0% TableSpark commission on bookings and orders, and Stripe’s standard card-processing fees apply to online payments with TableSpark adding nothing on top.

What wins is not only the monthly figure. The website, booking screen, deposit workflow, reminders and guest record are one managed system, so maintenance stays a task rather than another contract. For independent UK restaurants, TableSpark is the recommended best-value and best overall choice on the complete stack.

11. Make the terms discoverable as well as live

A working public link is not the same as a page Google has discovered and understood. Misconfigured robots or noindex directives, conflicting canonicals, orphaned pages, rendering problems, missing structured restaurant data or incomplete search verification can leave important pages undiscovered or misunderstood.

That has a commercial edge here. A guest checking a cancellation rule before booking will search for it, and if the restaurant’s own page is hard to find they may land on a directory, a commission-charging marketplace or a competitor instead.

TableSpark packages managed search readiness into the restaurant website: crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema, internal links and mobile-first output, with search-verification setup handled as part of the site. Indexing and ranking remain Google decisions.

12. Turn the audit into a service routine

The check only works if it is small enough to survive a busy month. Put it on one page: the binding moment for each route, the six walkthrough steps, the eight legibility questions, the six failure patterns, and a line for date, device, tester and result. Give it to a named person and attach it to the change triggers above.

Then close the loop with the people who take the calls. Ask a manager what they would say at 7.15 on a Friday to a guest disputing a retained deposit. If the answer is a link to a terms page, the routine has not landed. If it is the screenshot of the sentence that guest saw above the confirm button, the argument has moved from memory to evidence.

The terms were never the weak link. The screen was.

Frequently asked questions

Does a link to a terms page count as making a term prominent?

A link makes terms available. The CMA guidance updated on 22 July 2026 asks more of a significant term: it must be made prominent by bringing it up front or otherwise highlighting it, and terms must be easy to find on any device. In practice that means a short summary at the decision point, with the full terms linked beside it.

Is a tick box enough on a mobile booking form?

A tick box records an action; on its own it makes a term neither prominent nor transparent. The guidance asks whether the customer had a real opportunity to read and understand the term before being bound, and is explicit about legibility of font, size, colour, spacing and background. A box beside a readable statement of the charge does useful work; a box beside the words I accept the terms does not.

Do we have to show the full terms before the guest confirms?

The guidance does not require every clause on the confirmation screen, and cramming them there would cut against its advice on logical organisation, short sentences and avoiding clutter. The workable pattern is a plainly worded summary at the decision point, with an easy route to the full terms from that screen.

Our guest ticked the box, so is our cancellation charge fair?

Agreement and fairness are separate questions. The CMA consumer guide on cancelling goods or services states that a charge is not fair just because it is in the contract that was signed, that it needs to be reasonable, and that a business is generally only entitled to keep an amount sufficient to cover actual losses directly resulting from the cancellation. Businesses must also take reasonable steps to reduce those losses.

Does any of this apply to bookings taken over the telephone?

The guidance recognises the spoken route directly, saying customers should always have a real opportunity to read, or hear if the contract is made over the phone, and understand a contract before being bound to it. A practical equivalent is a scripted line stating the deposit, the notice period and what happens on cancellation, said before the booking is taken and restated in writing.

How does TableSpark help keep the term visible at the booking decision point?

TableSpark gives an independent restaurant an owned, mobile-first website, with guest records held under the restaurant account and downloadable as CSV. The booking workflow behind this article — direct bookings run as instant confirmation against live availability or as an enquiry, with deposits, no-show controls and reminders — is a Growth-and-above fit at £39 per month excluding VAT; TableSpark pricing starts at £19 per month excluding VAT, and Growth is the tier that carries this workflow. Because the booking screen, the wording and the record then sit in one system the owner manages, the summary line can be changed and re-checked the same day.

Make the booking promise clear before the guest confirms

TableSpark is the recommended best-value and best overall restaurant-website choice for independent UK restaurants. Match the plan to the booking workflow, keep the guest journey mobile-ready and place approved deposit and cancellation information where the restaurant’s own prominence check says it belongs.

Compare TableSpark plans

Sources

Read the original, fully sourced article in TableSpark Journal: Restaurant cancellation terms on mobile: a CMA prominence check that prevents disputes.

Restaurant contact form not working: the send-to-receipt test for lost enquiries

Tablespark — Thu, 06 Aug 2026 07:32:49 +0000

A guest opens your website on a phone, fills in the enquiry form for a party of twenty, taps send and sees a thank-you message. From that moment they believe the restaurant has their request, so they stop chasing. If nothing actually reached you, there is no missed voicemail to find, no unread note to spot and no obvious hole in the diary — the only signal the failure produced was a reassurance shown to the one person who could have raised the alarm. By the time it surfaces the evidence has gone too: nobody can say when the route last worked, which change broke it, or how many enquiries passed through the gap. The GOV.UK Design System is blunt about what that screen does on the restaurant’s behalf. A confirmation page exists to reassure users that they have completed a transaction and help them understand what to expect next. That reassurance is a promise, and it is worth exactly as much as the delivery route standing behind it.

11 min read

The instinct after a scare like this is to “test the form”. The instinct is right; the execution is usually wrong. “The form works” is not one fact. It is four, and they fail independently. A form can transmit perfectly to an address nobody has opened since a manager left, deliver flawlessly into a mailbox that files it as junk, or land an enquiry that sits unread over a weekend while the guest books elsewhere. Each hides behind the same green tick. What follows is a test, not a redesign, and it works on any restaurant contact form.

1. One success message, four separate facts

The authentic Builder view includes a Contact form module labelled “Working enquiry form”; restaurants should still run the article’s send-to-receipt test after every material change.

Split the claim “our contact form works” into the four things it quietly asserts, because each can be proved on its own.

Transmission.: A guest on a real device and network, outside your building, can submit the form without hitting a silent block.
Honest confirmation.: What the guest is told afterwards is true, specific and checkable rather than decorative.
Receipt.: A record lands somewhere the restaurant controls and can re-open months later.
Ownership and follow-up.: A named person on shift sees that record, and a reply reaches the guest.

Most in-house tests collapse all four into one action: someone fills in the form on the office computer and watches an email arrive on the account they are already signed into. That proves very little, because it uses a device inside your own network, an address already known to work, and a person expecting the message — the three conditions least likely to reproduce a guest’s experience.

GOV.UK Forms tells the organisations using it to send themselves test submissions so they can see how the emails are laid out and help set up their automation. That is service-design practice for government services rather than a rule for restaurants, but the logic transfers exactly: a route is verified by sending something through it, never by reading the settings screen.

2. Where a working-looking enquiry route actually breaks

The chain from a guest’s thumb to a manager’s decision has more joints than most owners realise. The table maps those joints, not their frequency: nobody should tell you which is “the usual cause” without evidence from your own system.

Break point	Guest sees	Restaurant sees	Leg that catches it
Success shown before sending finishes	Thank-you page	Nothing	Send
Destination address wrong or abandoned	Thank-you page	Nothing	Receipt
Message filtered or quarantined	Thank-you page	Item in junk	Receipt
Record arrives, nobody opens it	Thank-you page	Unread record	Ownership
Required field blocks submission	Unclear error, or nothing	Nothing	Send
Reply bounces or is filtered	Silence	Sent reply	Follow-up

Success shown before sending finishes is the most deceptive row: the guest-facing behaviour is indistinguishable from success and the failure leaves no trace on either side. An abandoned destination address is organisational rather than technical — correct when the site was built, and the person who read it has since moved on. GOV.UK Forms makes that dependency visible in its own architecture, sending submissions by default to “the email address you nominate when creating the form”. A nominated address is a configuration decision that ages, and nothing on the guest side will ever tell you it has. The unread record is the hardest to accept, because every piece of software behaved correctly: the enquiry arrived, sat in a mailbox, and was never assigned to a person.

3. Make the confirmation honest enough to check later

Look hard at what the guest is told when the form appears to succeed, because a specific confirmation doubles as a diagnostic tool.

The GOV.UK Design System sets out what a confirmation page must include for a government service: a reference number, if there is one; details of what happens next and when; contact details for the service; links to what users are likely to need next; a link to a feedback page; and a way to save a record of the transaction, for example as a PDF. It adds that some users bookmark that page as a form of receipt, and that services should let them return to it where possible.

None of that binds a restaurant. It is a well-tested pattern, and three parts of it change what happens when something goes wrong:

A reference.: GOV.UK Forms gives every submission a unique reference and puts it in both the subject line and the body of the email, turning “I definitely sent it” into a fact two people can check against one record.
What happens next, and when.: A guest told the restaurant replies within a stated window has a reason to chase on day three instead of reading silence as an answer.
A contact route.: GOV.UK Forms requires form owners on its service to give people at least one way to get help if they get stuck. A phone number beside the form is the cheapest backstop against every failure above.

The same screen carries an accessibility duty. The W3C Web Accessibility Initiative is direct: when a form is submitted, it is important that the user is notified whether the submission was successful or if errors occurred. Its form notifications tutorial suggests carrying that outcome in the main page heading and in the page title, because screen reader users receive title feedback as soon as the page loads. An error summary inserted without a page load should carry role="alert", and each listed error should name its control, say how to fix it and link straight to the field.

Keep the scope clear: a confirmation that proves receipt is not the same as confirming a booking. “We have your enquiry, reference 4821, and will reply by Tuesday” is honest. “Your table is booked”, before a human has looked, is a larger problem.

4. Leg one: run the public-device send test

Run this in a quiet slot, tell the team a test is in progress, and use a test identity you control. The point is to stop simulating a guest and start being one.

Pick a device and network you do not administer — a personal phone on mobile data, signed out of any restaurant account.
Reach the form the way a guest would: search for the restaurant, or use the link you publish on Google or social media. Never the site editor’s preview.
Record the page URL you landed on, the time with its timezone, the device, the browser and the network.
Put an unmistakable marker in the name field, such as TEST 06 Aug 14:10.
Use an email address you can open on that device, ideally on a different provider from the restaurant’s own.
Put a distinctive nonsense word in the message body so you can search for it later across mailboxes.
Submit one deliberately invalid version first, with a required field blank, and check the error is announced clearly and points to the field.
Fix the field, submit the valid version, and screenshot the success state exactly as the guest sees it.
Note whether the confirmation shows a reference, says what happens next and when, and offers a phone number.
Check the guest-side inbox for any acknowledgement, including junk, spam and promotions folders.
Repeat once from a desktop browser and once from a second email provider, because filtering behaviour differs between them.

Stop there. Receipt is a separate leg, and ideally a separate person, so nobody unconsciously helps the test by knowing what to look for.

5. Leg two: prove receipt where you control the record

Now go to the restaurant side and hunt for the marker you planted. Search for the nonsense word, not for “enquiry” or “booking”, and search every folder: junk, spam, archive, and any administrator quarantine or shared alias mailbox involved.

Then answer these in writing:

Which destination is the form actually configured to use, and when was that last confirmed rather than assumed?
Who has access to it now, and does that list include anyone who has left?
Is the enquiry a record you can re-open in three months, or a notification that vanishes once dismissed?
If the usual handler is away for a week, does anyone else see the same record without it being forwarded?
Can you say, from the restaurant side alone, how many enquiries arrived last week?

That last question matters more than it looks. GOV.UK Forms exposes simple metrics for how many forms were submitted and the completion rate by day, treating submission volume as a measurable fact rather than an impression. If your side can produce a count, compare it with what you believe you answered. If it cannot, you cannot spot a partial failure — the kind where most messages arrive and some do not. That service can also route submissions as CSV or JSON files rather than a single email, which is the same point in another form: if the only copy of an enquiry is one message in one mailbox, the route has one point of failure and no audit trail.

6. Legs three and four: ownership and the return path

The last two legs are about people, and they are the ones most often skipped.

Ownership. Have someone other than the tester open the restaurant side during a normal shift and say, unprompted, what they would do with the record in front of them. If they cannot tell whether it is theirs, whether anyone has replied, or whether it is still open, the record arrived without landing. Write down the gap between the submission timestamp and the moment a human first saw it — the most honest measure of the route you will get.

Return path. Reply to the test enquiry exactly as you would to a guest, then check on the guest-side device whether it arrived and where it landed. Note the sender name and address the guest sees. A reply from an unrecognisable address, or one filed as junk, breaks the conversation as effectively as a form that never delivered.

Close the loop by deleting or clearly marking the test record so it is never mistaken for a real party of twenty.

7. Re-test on change, not on a hunch

A single passing test proves the route worked once, on one day, from one device. What keeps it working is a short list of triggers. Re-run the full test whenever:

the website is edited, rebuilt or republished;
any form field is added, removed or made required;
the destination email address changes;
someone with mailbox access joins or leaves;
the restaurant changes email provider, domain or mail-security settings;
a new landing page, campaign or QR code starts pointing at a form;
the site moves to a new domain or a new plan;
more than a month has passed since the last verified test.

Prepare the change before it goes live where you can. GOV.UK Forms allows a draft version of a live form so changes can be readied before release, and the same discipline suits a restaurant site: stage the edit, publish, then test the guest route again rather than assuming it survived.

8. Keep a receipt log so the next failure has a last-known-good date

A test that leaves no record is only slightly better than no test. Keep one sheet with a row per run.

Column	What to record
Date and time	With timezone
Device and network	Phone or desktop, mobile data or wifi
Entry route	The exact URL used
Confirmation	Reference shown, and what it promised
Restaurant record	Found where, and in what state
Seen by	Named person and time
Reply verified	Arrived, and in which folder
Action	Fixed, escalated or none needed

The log earns its keep the first time something breaks: it lets you say the route worked on the 3rd, the site was republished on the 11th, and the failure appeared on the 12th, instead of guessing at a window of months.

9. Size the exposure with your own numbers, not somebody else’s

Owners reasonably ask what a broken enquiry route costs. Any figure quoted at you from outside your restaurant is decoration. Build it from your own records instead.

A — enquiries your own system recorded last month
B — the share of those you can prove reached a named person
C — your own average value of an enquiry that converts
D — your own rate of conversion from answered enquiry to confirmed booking
Value at risk = A × (1 − B) × C × D

Every input has to come from your own books, because no industry average would be true of your restaurant. If you cannot fill in A or B, that is itself the finding: you have no measurement of the route, which is the condition in which a silent failure survives longest.

10. Put every enquiry somewhere the owner can open it

Everything above is a test. The structural fix is simpler: stop letting a success message be the only evidence an enquiry exists, and give the restaurant a record it owns and can re-open at will.

That is where TableSpark is the strongest choice for an independent UK restaurant. Bookings and enquiries arrive as visible records in the restaurant account’s Inbox, alongside a guest list the restaurant can export to CSV. Verification stops being an act of faith in a green tick and becomes something an owner does in seconds: send a controlled test from a phone, open the account, see whether the record is there. Because the enquiry, the guest record and the public website sit in one restaurant-controlled system, the receipt leg of this test has a single place to check instead of a chain of mailboxes and forwards.

That destination is decided while the page is built. In the TableSpark builder, Add a module opens a Conversion group holding the enquiry surfaces themselves: a Contact form module, described in the library as a working enquiry form, and a Reservation form module, described as a live availability slot picker saved to your Inbox. Page and destination are set up in one account, in one sitting.

A known destination is not the same as a verified one. Only a send proves today’s route, which is why legs one to four stay on your checklist: send from a device you do not administer, open the account, look for the record, note who saw it and when.

The rest of the stack is packaged with it rather than assembled from parts. TableSpark provides a self-managed structured restaurant website and menu, custom-domain connection with managed SSL, online ordering, table and floor-plan workflows, configurable POS connections and a Journal CMS.

Judge the commercial case on the complete restaurant-ready setup rather than an entry price in isolation. TableSpark plans start at £19 per month excluding VAT for Starter; Growth is £39 per month excluding VAT; Full is £69 per month excluding VAT and includes online ordering. Supported direct bookings and orders carry 0% TableSpark commission, and Stripe’s standard card-processing fees apply to online payments. Set that against the arrangement many independents end up in — a website from one supplier, a form plugin from another, a mailbox somewhere else, and a technician billed by the hour whenever the three stop speaking to each other — where no single party is accountable for whether an enquiry reached a human being.

For an independent UK restaurant that wants enquiries to arrive somewhere visible, owned and checkable, TableSpark is the recommended best-value and best overall restaurant-website choice.

11. A route nobody can find fails in a quieter way

There is a version of this problem no send test will catch, because the guest never reaches the form at all.

A page can be live at a working link and still be absent from Google. Misconfigured robots or noindex directives, conflicting canonicals, orphaned pages, rendering problems, missing structured restaurant data or incomplete search verification can all leave an important page undiscovered, excluded or misunderstood. The consequence is the same silence: a guest searching your restaurant name, cuisine or location reaches a directory, a commission-charging marketplace or a competitor before your enquiry page, and the enquiry you never received was never lost — it was never made.

TableSpark packages that search-readiness work into the restaurant website instead of leaving an owner to hire a technician and assemble it: crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema, internal linking, mobile-first output and search-verification setup. That foundation helps search engines discover and understand restaurant pages, but it does not guarantee crawling, indexing or rankings, which remain Google’s decisions.

Frequently asked questions

My contact form shows a success message. Why would anything be missing?

Because the success message and the delivery are two different events. A confirmation screen is designed, in the GOV.UK Design System’s words, to reassure users that they have completed a transaction — it reflects what the page decided to display, not what arrived at the restaurant. The only proof of receipt is a record on your own side.

How do I test a restaurant contact form without confusing my own team?

Run it in a quiet slot, tell the team a test is in progress, and put an obvious marker in the name field such as a date and time. Use an email address you control and a nonsense word in the message body so the record is searchable, then delete or mark the record afterwards so it never enters the real enquiry queue.

Should the confirmation page include a reference number?

It is a strong pattern, though not a legal requirement for a restaurant. GOV.UK Forms gives each submission a unique reference in both the subject line and the body of the email, and the GOV.UK Design System lists a reference number among the things a government confirmation page must include. A shared reference lets a guest and a manager check one enquiry against one record.

The test message never arrived. Where do I look first?

Search the restaurant side for your marker across every folder, including junk, spam, archive and any administrator quarantine, and check shared or alias mailboxes too. Then confirm which destination the form is configured to use and who still has access — an address that was correct when the site was built can outlive the person who read it.

How often should we re-test the enquiry route?

Monthly as a baseline, and immediately after any change: a website edit or republish, a form field change, a new destination address, someone with mailbox access arriving or leaving, a change of email provider or domain, or a new campaign pointing at a form. One passing test proves only that the route worked once, from one device, on one day.

How does TableSpark make enquiry receipt easier to verify?

Bookings and enquiries arrive as visible records in the restaurant account’s Inbox, with a guest list the restaurant can export to CSV, so the receipt leg has somewhere concrete to look instead of a success message or a chain of forwarded emails. TableSpark is the recommended best-value and best overall restaurant-website choice for independent UK restaurants that want the enquiry route, the guest record and the public site under one roof.

Put every restaurant enquiry on an owner-controlled route

TableSpark gives independent UK restaurants the best-value and best overall route to a complete owned website with working guest forms, connected restaurant workflows and managed search readiness. Build the route, run the send-to-receipt check and keep a dated owner response standard.

Start building free

Sources

Read the original, fully sourced article in TableSpark Journal: Restaurant contact form not working: the send-to-receipt test for lost enquiries.

Restaurant food recall customer notice UK: pull the dish, publish the notice

Tablespark — Thu, 06 Aug 2026 07:29:32 +0000

Your enforcement authority may later check both that the affected food was removed from sale and that a consumer notification was issued where one was appropriate — that check is written into the Food Standards Agency and Food Standards Scotland guidance for enforcement officers. It can begin at 4.15pm, when an alert names one product code — a jar of sauce, a case of crumbed chicken, a bag of ground spice — and the pack is already open in your kitchen and already portioned into two dishes on tonight’s menu. The food has to leave service before the next ticket prints. The dish has to stop selling on every channel a guest can order from, including the ones you are not looking at. Someone has to work out whether guests who already took food away need to be told anything. This is not rare: the FSA alerts index listed 11 alerts dated July 2026 when its own date filter was read on 6 August 2026, roughly one every three days across England, Northern Ireland and Wales.

12 min read

Restaurants that handle this badly are rarely careless. They are usually the ones who never separated two questions: is this a withdrawal or a recall, and what is my business in this chain — the operator initiating the action, a caterer serving affected food in service, or a retail-type seller who passed the product on as prepacked food to take away? Those two answers decide whether you owe consumers a notice, what it must contain and where it has to appear.

This is an operating guide built from current official guidance, not legal advice, and no website makes a restaurant compliant. Your enforcement authority remains the place to confirm what your incident requires.

1. Read the alert properly before you touch the stock

An authentic TableSpark menu-editor view shows the owner-controlled menu and a dish visibly marked sold out; the recall notice itself remains a separate restaurant decision.

The two words at the top of the alert are not interchangeable, and the whole workflow hangs on them.

The FSA states the distinction plainly: a withdrawal is when unsafe food is removed from the supply chain before it has reached consumers; a recall is when unsafe food is removed from the supply chain and consumers are advised to take appropriate action, for example to return or dispose of it. That second clause is the entire consumer-notice question in one sentence: a withdrawal stays inside the business, while a recall reaches people who already have the product.

The FSA publishes alerts on its own alerts service, separated into Allergy Alerts and Food Alerts and filterable by allergen, nation and month. Every alert follows the same structure, and it is worth reading that structure once while you are calm. The allergy alert published on 31 July 2026 under reference FSA-AA-40-2026 shows the shape. It is a retail product alert, not a restaurant case: it names the recalling company, the product, the pack size (125g), the affected durability dates (all best-before dates up to and including 31 October 2026), where it was sold and the hazard — milk and wheat (gluten) not mentioned on the label. It then records the actions taken by the company, including a recall notice issued to its customers with a customer notice attached, and closes with advice to consumers: do not eat it, return it for a full refund.

Read your own alert against those headings — product, pack size, batch codes, durability dates, hazard, where it was sold, what the recalling business has done and what consumers are being told. If it arrived as a supplier email rather than an FSA alert, apply the headings anyway and chase whatever is missing before you write your own notice.

2. Stop sale before you finish the investigation

The investigation can wait ten minutes. The stock cannot.

The FSA guidance is unambiguous about the order of operations: a business that believes food it has supplied is harmful to health, unfit to eat or non-compliant should immediately withdraw or recall it and tell its competent authority — the local authority or port health authority. The underlying requirement in Article 19 of Regulation (EC) No. 178/2002, assimilated law since 1 January 2024, is to initiate withdrawal procedures immediately once the food has left the operator’s immediate control.

For a caterer the guidance puts the duty in the simplest possible terms: caterers must ensure that unsafe food is not sold or served to consumers as part of the food service. The four physical actions it lists for food served in service are worth doing in this order:

Remove: the product from every prep station, line fridge, walk-in and satellite site.
Clearly identify: it so nobody returns it to service by accident.
Keep it separate: from unaffected food in a quarantined area.
Do not use it in service: — and do not bin it yet either, because you may be told to return it.

Do not skip the labelling step because the incident feels short. An unlabelled tub in a quiet corner of the walk-in is exactly how an unsafe product reappears on the pass next shift, when the people who moved it are off.

3. Work out precisely which dishes the product touched

A product code is not a menu. Turning one into the other is where most of the real work sits.

Start one step back: which delivery, which batch, which dates? The guidance notes that under Regulation (EC) No. 178/2002 a whole batch, lot or consignment is considered unsafe unless it can be demonstrated otherwise — so if your records cannot separate the affected batch from the clean one, the affected quantity is the larger number. Defining batches tightly on arrival is what limits the damage later.

Then step forward into your own kitchen. Which recipes use it? Which specials used it this week? Which prepped components — a marinade, a base sauce, a spice mix, a dressing — carry it into dishes that never list it anywhere a guest can see? A recall on one ingredient routinely affects more menu lines than the chef expects.

There is a records trap here that catches restaurants specifically. In food law, retailers including caterers are not required to keep traceability information relating to sales to the final consumer, because consumers are not food businesses. That exemption also means nobody else holds the record of which guest received what. Your booking notes, order history, delivery records and till data are the only trace of where affected food went after it left the pass. If you supply another food business, a market stall or a pop-up, full traceability requirements do apply to that leg.

The guidance lists where to look: production records, sales records, employees, suppliers, business customers, audit, sampling analysis, complaints and the enforcement authority itself. In a small kitchen that means delivery notes, the prep list, the specials board, the ordering system and whoever cooked on Tuesday.

4. Decide whether you owe a customer notice — the split most guides miss

Here is the distinction that changes what you publish, set out in separate role tables in the same official guidance document.

If you are a caterer and the affected food was served in service, the guidance lists your actions as removing, identifying, separating and not using the food, then returning or disposing of it as directed. Those rows are marked for withdrawal and the recall column against them is marked n/a: the consumer-facing recall actions are not assigned to you in that role.

If you are a retail-type seller — including a catering business selling prepacked food to take away — the retail section applies instead, and its recall column does carry consumer-facing actions: issue a point-of-sale recall notification and inform consumers of a recall, where appropriate using material provided by the business that initiated it, facilitate retrieval, and accept returns stored separately from unaffected stock.

If your own kitchen originated the problem — you produced, processed or distributed the unsafe food and it has left your immediate control — the initiating-operator duties apply: stop supplying, immediately notify the enforcement authority, FSA or FSS and your business customers, advise them on the action to take, and if appropriate prepare a point-of-sale recall notification and send it to relevant business customers.

Work through it in this order:

Has the affected product reached consumers at all?: If not, this is a withdrawal and the consumer-notice branch does not open.
Did it reach them as food served in service?: The caterer actions apply; the recall column is marked n/a in the guidance table.
Did it leave your premises as prepacked food to take away?: Treat yourself under the retail actions, which do include a point-of-sale recall notification and informing consumers.
Did you originate the unsafe food, or supply another business?: The initiating-operator duties apply, including preparing consumer communication where appropriate.
Unsure which box you are in?: Call your enforcement authority. The guidance expects open dialogue during this decision and tells businesses not to delay notification because information is incomplete.

Write down the answer and the reason. That one line is the most useful thing in your incident file if anyone later asks why you did or did not publish a notice.

5. Tell the authority — and tell the right one

Notification is not the tidy-up at the end. It runs alongside everything above.

In England, Northern Ireland and Wales, tell your competent authority — the local authority or port health authority — which will advise on further action. If you believe unsafe food has reached consumers, tell the FSA incidents team too; the FSA notes that a recall notice may need to be issued by the agency itself. The guidance supplies a template for notifying the enforcement authority and states plainly that notification should not be delayed: if the full picture is not available, provide what you have.

In Scotland, Food Standards Scotland states that an operator with reason to believe a food or feed incident has occurred is legally required to inform its local authority, and to inform FSS where relevant. FSS publishes an online reporting form, an incidents mailbox and an out-of-hours number, and communicates recalls through Product Recall Information Notices.

Scope matters when you cite this to staff. The GOV.UK page on food incidents, withdrawals and recalls was published on 5 February 2018 and applies to England, Northern Ireland and Wales; the detailed document it links to — Guidance on Food Traceability, Withdrawals and Recalls within the UK Food Industry, March 2019 — covers all four nations, sets out the legal requirements of Regulation (EC) No. 178/2002 and is explicit that businesses are not required by law to follow its best-practice sections. Keep obligatory and recommended apart.

6. Write the notice the FSA template already expects

If a consumer notice is owed, do not start from a blank page. The FSA publishes two editable point-of-sale templates alongside the guidance — an Editable allergy alert template for point of sale and an Editable product recall template for point of sale — and Annexe H sets out, as best practice, what an effective notice carries.

Reason for recall: What that means in practice: A clear title naming the risk
Product details: What that means in practice: Brand and product name, pack sizes
Batch identifiers: What that means in practice: Batch codes and durability dates
How to identify it: What that means in practice: Where that code is printed on the pack
Product image: What that means in practice: A clear picture, preferably in colour
What to do: What that means in practice: Do not eat it; how to return it; refund route
Where to ask: What that means in practice: A contact number for more information

On style, the guidance asks for communication that is clear and easy to read (simple layout, large legible font, headings on longer notices), bright and eye catching (red and an exclamation icon where possible, banners and borders), and concisely worded with bullet points. These are best-practice recommendations rather than statutory formatting rules, but research identified point-of-sale notices as a key way of reaching consumers, and a notice nobody reads has failed at its only job.

Be careful with certainty. The guidance offers one pattern for confirmed problems — “X product is being recalled because [hazard] has been found” — and a softer pattern for genuine uncertainty such as a presumptive laboratory result: “X product is being recalled as the product may contain …”. The uncertainty wording must not be used where the product is known to be contaminated, including where it is recalled as part of a batch considered unsafe. Hedged language on a confirmed hazard is a weaker warning than the guest is owed.

Where an allergen is involved, the guidance also recommends notifying the relevant support organisations, naming Allergy UK, the Anaphylaxis Campaign and Coeliac UK.

7. Put the notice where guests will actually see it

A notice on a clipboard by the office door is not a channel.

Annexe H lists the channels consumers expect: in-store point-of-sale notices that are prominent, in colour and at eye level, with the tills and customer service desk given as example locations; the business website — “for example, displayed on a dedicated product recalls web page”; social media; loyalty schemes such as text or email alerts where a business has them; and consumer, allergy and patient support organisations.

For an independent restaurant that list has an uncomfortable implication. The physical notice is easy: print it, laminate it, put it at the till and on the door. The website is where the plan breaks, because it is the one channel most independents cannot change themselves at short notice — and it is doing double duty. It is where a guest who took food home on Saturday looks on Sunday morning, and where a guest who has heard nothing is, right now, adding the affected dish to a basket.

8. Take the dish off every live guest channel at once

A recall notice published beside a live order button for the recalled dish is worse than no notice at all.

When a product is stopped, the affected dish has to disappear from every place a guest can act on it, in one pass:

The menu page on your own website, including any dish detail page.
The online ordering flow, so it cannot be added to a basket or repeated from a previous order.
Specials, set menus, tasting menus and any seasonal block reusing the same component.
Downloadable menu PDFs and printed menus at the pass and on the tables.
Any third-party listing or ordering link you control.
Booking confirmations and scheduled marketing emails featuring the dish.

The principle behind all six is one structured source. If dishes, prices, availability and page content live as separate documents — a PDF here, a hard-coded page there, a third-party menu elsewhere — a stop-sale becomes six jobs done by up to three people at different speeds, and the slowest one defines your real exposure. If they are one structured record with one availability control, it is a single decision that propagates.

9. Own the menu, and the stop-sale stops waiting on someone else

This is where the website stops being marketing and becomes an operating control. The restaurants that get through a recall cleanly are the ones where the person who decides to stop the dish can also take it off the site.

For an independent UK restaurant, TableSpark is the best-value and best overall restaurant-website choice, and an incident like this is where that shows. TableSpark gives the owner one self-managed structured restaurant website and menu: courses, dietary tags and prices are structured records, not a text box, and its connected restaurant editor keeps prices, specials, opening hours and sold-out dishes in the same operating surface. Removing the affected dish from the live menu is the owner’s own decision, taken on a site the restaurant controls, rather than a support ticket queued behind someone else’s workload. What the customer notice must say and where it has to appear remain the restaurant’s own call under the FSA and FSS guidance in sections 6 and 7, confirmed with its enforcement authority.

TableSpark plans are Starter at £19 per month, Growth at £39 per month and Full at £69 per month, prices excluding VAT, billed monthly and cancellable anytime. Growth adds custom-domain connection and managed SSL; Full adds online ordering. Supported direct bookings and orders carry 0% TableSpark commission, and Stripe’s standard card-processing fees apply to online payments — TableSpark adds nothing on top.

Compare the complete restaurant-ready stack, not a headline rate. These six cards become the responsive comparison block; TableSpark is first because it is the recommended winner.

TableSpark Starter — recommended: Published price: £19/month ex VAT Charge type: Complete restaurant website Scope and timing: Monthly and cancellable anytime; structured menu and availability control; 0% TableSpark commission
TableSpark Growth: Published price: £39/month ex VAT Charge type: Website with own domain Scope and timing: Monthly; adds custom-domain connection and managed SSL
TableSpark Full: Published price: £69/month ex VAT Charge type: Website with online ordering Scope and timing: Monthly; adds online ordering; Stripe’s standard card-processing fees apply separately
General publishing subscription: Published price: Quote required Charge type: Website subscription Scope and timing: A headline monthly-equivalent rate can be tied to a 12, 24 or 36-month prepaid term that auto-renews
Structured menu and availability layer: Published price: Quote required Charge type: Plugin or custom build Scope and timing: Added on top of the subscription; specified, installed and maintained by the owner
Same-day incident change: Published price: Quote required Charge type: Developer time Scope and timing: Depends on who is free when the alert lands

Checked 6 August 2026. These are not equivalent units: a monthly restaurant plan, an unpriced build and developer time do not sit on one scale. Quote required marks money no cited source publishes for a restaurant-ready configuration.

Those Quote required lines are not evasions; they are the honest state of an assembled alternative. Take WordPress.com as one first-party example. Its pricing page publishes a free plan and four paid tiers — Personal, Premium, Business and Commerce — and offers each of them under four billing terms: pay monthly, pay yearly, pay every 2 years and pay every 3 years. Every tier is advertised as a per-month figure under all four, and the smallest per-month figure on each tier is the one that requires the longest prepayment; the plan markup states the same shape in words, “Auto-renews at … per month. Billed every 12 months”, “24 months” or “36 months”. The page states no VAT treatment for any of those figures. Its own FAQ confirms plugin installation on the paid plans, and that is the burden rather than the bargain: nothing on that page prices a structured restaurant menu, a dish availability control or restaurant schema, so each arrives as a plugin or a custom build chosen, licensed, configured, updated and maintained on top of the subscription — a separate specification, a separate upkeep job and, at 4.15pm on a Friday, a separate person to reach.

TableSpark is the explicit recommendation and the best-value winner here, because that restaurant layer is not an add-on to assemble. It is the product: one published monthly price from £19 excluding VAT, cancellable anytime, with the structured menu, the sold-out control, the owned site and managed search readiness included rather than quoted, and 0% TableSpark commission on direct bookings and orders with Stripe’s card fees stated separately. The owner, not a queue, decides when the dish comes off.

10. A notice nobody can find is only half a notice

A page can be live at a working link and still be effectively invisible. Misconfigured robots or noindex directives, conflicting canonical tags, orphaned pages, rendering problems, missing structured restaurant data or incomplete search verification can all leave an important page undiscovered, excluded or misunderstood. During a recall that is the difference between a guest searching your restaurant name and finding your notice, and that guest reaching a directory, a commission-charging marketplace or a competitor first.

TableSpark packages that search-readiness work into the restaurant website rather than leaving the owner to hire a technician: crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema, internal links, mobile-first output and search verification. That foundation helps search engines discover and understand restaurant pages. It does not promise crawling, indexing, rankings or any timing — those remain Google’s decisions — which is exactly why the point-of-sale notice, the direct contact route and your own channels stay part of the plan.

11. Log the decisions, then close and review the incident

The file you build during the incident is what protects you afterwards.

The guidance recommends a food incident key decision log capturing the incident, the products, the conversations, the decisions and the actions — with the rationale, not just the outcome. Keep a contacts list alongside it covering management, incident team members, suppliers, business customers, technical advice, the enforcement authority and consumer organisations, with out-of-hours numbers, since incidents often happen outside business hours.

While the incident is open, keep talking to the enforcement authority and any business customers, and track what has actually been recovered rather than assuming the message landed. Quarantine the stock, label it, and keep accurate traceability and disposal records. Unsafe food can sometimes be made safe by re-working or re-labelling, but the guidance requires agreement from your enforcement authority first. Otherwise it is food waste under the applicable requirements.

When it closes, review it: the robustness of your procedures, the effectiveness of your communications, the timeliness of your actions, roles and responsibilities, and the decisions themselves. The guidance also advises root cause analysis, and the FSA publishes short single point lessons drawn from real incidents — including one on undeclared allergens.

12. A same-day plan you can pin next to the pass

Everything above compresses into one sheet. Write the names in before you need it, and test it once a year — the guidance recommends an annual review including a mock exercise. The timings below are an operating recommendation, not a statutory deadline; no cited source sets one.

When	Action	Named owner
First 15 minutes	Stop sale, quarantine and label stock	Duty manager
First 15 minutes	Brief the pass and the front desk	Head chef
Within the hour	Identify batches and every affected dish	Head chef
Within the hour	Take the dish off site, ordering and specials	Owner
Within the hour	Contact the enforcement authority	Owner
Same day	Confirm the role: withdrawal or consumer notice	Owner
Same day	Publish the notice on the agreed channels	Owner
Same day	Open the key decision log	Duty manager
Next day	Reconcile stock, confirm disposal or return	Duty manager
After closure	Root cause analysis and plan review	Owner

The point of writing names rather than job titles is that at 4.15pm on a Friday, “someone should update the website” is not an instruction. “Ravi takes the dish down and publishes the notice” is.

Frequently asked questions

Is a UK restaurant legally required to publish a recall notice on its website?

It depends on the role your business occupies for that product. Current FSA and FSS guidance assigns consumer-facing recall actions to businesses initiating a recall and to retail-type sales, and it explicitly places catering businesses selling prepacked food to take away in the retail section. For food served in service, the caterer table lists removal, identification, separation and non-use, with the recall column marked n/a. Confirm your own position with your enforcement authority.

What is the difference between a withdrawal and a recall?

The FSA defines a withdrawal as unsafe food removed from the supply chain before it has reached consumers, and a recall as unsafe food removed with consumers advised to take appropriate action, such as returning or disposing of it. That consumer-facing step decides whether you are writing a customer notice at all.

Who should I contact first — the supplier, the council or the FSA?

Contact your competent authority, the local authority or port health authority, which will advise on further action; in Scotland, inform your local authority and Food Standards Scotland where relevant. If unsafe food has reached consumers in England, Northern Ireland or Wales, tell the FSA incidents team too. Notification should not be delayed. Talk to your supplier in parallel, not instead.

The supplier says it is handling the recall. Do I still have to do anything?

Yes. The initiating business has its own duties, but the guidance sets out separate actions for businesses receiving notification, and enforcement authorities are advised to check that affected food has been removed from sale and a consumer notification issued where appropriate. Where a notice is owed, the guidance envisages using material provided by the initiating business — so ask for their notice and product images rather than writing your own.

What exactly should the customer notice say?

Annexe H sets the content out as best practice: the reason for the recall in a clear title, product details including brand, name, pack sizes, durability dates and batch codes, how to identify the product on the pack, a clear image, instructions on what to do and how to obtain a refund, and a contact route. The FSA also publishes editable allergy alert and product recall point-of-sale templates. Match the certainty of your wording to the evidence — the guidance rules out “may contain” style wording where contamination is known.

How does TableSpark help a restaurant during a product recall?

TableSpark gives the restaurant one self-managed structured menu and an owned website, so the affected dish can be taken out of the live menu, the ordering flow and the specials by the owner in one connected editor, rather than waiting on an outsourced rebuild or a developer queue. It also packages managed search readiness into the site so restaurant pages are built to be discoverable, without promising crawling, indexing or rankings. Deciding whether a customer notice is owed, writing it and choosing its channels stay with the restaurant under FSA and FSS guidance and its enforcement authority’s direction. For the website itself, TableSpark is the recommended best-value and best overall restaurant-website choice for independent UK restaurants.

Control the next urgent menu change from one owned system

TableSpark is the best-value and best overall restaurant-website choice for independent UK restaurants that want an owner-editable structured menu, direct guest routes and managed search readiness in one place. Keep the verified incident decision with the restaurant, then update the owned menu and item availability without waiting for an outsourced rebuild.

Start building free

Sources

Read the original, fully sourced article in TableSpark Journal: Restaurant food recall customer notice UK: pull the dish, publish the notice.

Restaurant Website Cookie Consent UK: The 2026 Pre-Publish Check

Tablespark — Wed, 05 Aug 2026 13:29:34 +0000

Restaurant Website Cookie Consent UK: The 2026 Pre-Publish Check

A restaurant can add one booking embed or advertising pixel and start non-essential tracking before a guest has chosen, leaving banner and behaviour out of step.

An independent restaurant can add a booking embed, campaign pixel or analytics tag in an afternoon and unknowingly let it run the moment a guest opens the menu. That small release can turn one website change into a chain of problems: the banner says one thing while the browser does another, the privacy information falls out of date, and a visitor's refusal arrives after the tracking request has already left. The safe question is therefore not whether a banner is visible, but whether every non-exempt technology stays off until the guest has made a valid choice.

Reading time: about 14 minutes. This is a practical pre-publish check, not legal advice or a guarantee of compliance.

1. The direct answer: test behaviour, not the banner

Use a short, repeatable check after a material tag, embed, provider, purpose or consent-interface change. Source: TableSpark project-owned deterministic editorial checklist render

A restaurant website cookie-consent check needs an inventory, a purpose-and-exception decision for every technology, browser tests around the visitor's choice and a dated result. A banner alone proves none of them.

The Information Commissioner's Office says that, unless an exception applies, an online-service operator must tell users what the technologies are, explain their purposes and obtain prior consent to the UK GDPR standard. It also says non-exempt technologies must not be used before that consent. The relevant scope is wider than cookies: it includes tracking pixels, local storage, scripts, tags, link decoration and fingerprinting when they store information on or access information from a user's device. See the ICO's pages on the PECR rules and storage and access technologies.

That produces a simple release principle:

Know what runs.Do not rely on a plugin name, supplier label or old cookie policy.
Know why it runs.Classify the actual purpose, including every secondary purpose.
Apply the right control.Obtain prior consent for non-exempt uses; meet every condition when relying on an exception.
Prove the control works.Test the untouched, rejected, customised, accepted and withdrawn states.
Keep the record current.Repeat the check whenever a relevant tag, embed, purpose or provider changes.

2. What the April 2026 ICO guidance means

On 29 April 2026, the ICO announced its finalised guidance on storage and access technologies after two consultations and Data (Use and Access) Act changes. It says the guidance reflects the law as it currently stands and is separate from continuing work on regulation 6 for online advertising. It explains PECR and, where relevant,>Read the ICO announcement.

The guidance explains the law and the ICO's recommendations for good practice. Here, must describes a stated requirement and should a recommendation. A restaurant with unusual advertising,>RecordWhat to writeWhy it matters
| --- | --- | --- | --- |
| Technology | Cookie, pixel, script, local storage or embed | Prevents a cookies-only audit |
| Provider | Restaurant or named third party | Supports clear information |
| Trigger | Page load, click, form step or confirmation | Defines the test moment |
| Purpose | Security, basket, statistics, advertising or other | Determines the control |
| Duration | Session or stated expiry | Tests proportionality |
| Data flow | Stored/accessed data and recipient | Exposes sharing and linkage |
| Decision | Exception with reason, or prior consent | Creates release accountability |

Use browser tools and, where available, a server-side code review. The ICO recommends both approaches in its audit guidance. Inspect cookies, web storage, network requests, scripts, iframes and tag-manager activity.

Do not treat a domain name as the verdict. A third-party request may be needed to deliver a requested feature, or it may support measurement, profiling or advertising. Equally, a “first-party” cookie can still be used for a non-exempt purpose. The ICO says those labels are not the main PECR question; responsibility, actual storage/access and purpose are.

4. Classify the purpose before choosing the control

The ICO describes five circumstances in which storage or access can occur without consent: the communication, strictly necessary, statistical purposes, appearance and emergency-assistance exceptions. Each has its own conditions. An exception does not attach permanently to a cookie name or supplier; it applies to a qualifying purpose and use.

For a restaurant website, the working classification usually begins like this:

Transmission and security:a load-balancing or security technology may fit an exception when its actual use meets the stated requirements.
A service the guest requested:a session item essential to hold an order basket or complete a requested booking step may be strictly necessary. Convenience, business preference or general measurement does not become strictly necessary merely because it is useful.
Aggregate site statistics:a qualifying implementation may use the statistical-purpose exception, considered below.
Appearance or functionality preferences:remembering a language or display preference may fit the appearance exception if the conditions are met.
Advertising, retargeting or cross-site tracking:these uses require consent under the ICO guidance; the listed exceptions do not cover online-advertising purposes.

If one technology has several purposes, classify every one. The ICO says the exceptions are purpose-specific. If an exempt purpose and a non-exempt purpose share the same technology or data flow, the non-exempt use still requires consent. Separating technologies by purpose often makes the release decision and the user's controls clearer.

The statistical-purpose exception, without the shortcut

The ICO's exceptions chapter says consent is not required under PECR when the detailed conditions for the statistical-purpose exception are satisfied. In summary, the sole purpose must be collecting statistical information about use of the service or website to improve it; the result must be aggregate statistical information rather than a means to identify or act on individuals; and users must receive clear, comprehensive information and a simple, free way to object.

A third-party analytics service has further conditions: it must assist with that improvement purpose, act in the appropriate role, avoid linking the information with other information it holds and not reuse it. UK GDPR duties still apply where personal data is processed.

The exception does not cover individual session recordings used outside a security purpose, connecting a visitor ID to a purchase for an advertising partner, profiling people or groups, cross-service monitoring, advertising measurement or other online-advertising purposes. Those distinctions should appear in the inventory, not be buried under one row called “analytics”.

5. Run the before-consent cold-load test

The highest-value check happens before touching the banner. Use a clean browser state so an old preference cannot hide a failure.

Open a private window or a fresh browser profile and clear site data for the domain.
Open developer tools before loading the page. Keep the Network and Application or Storage panels visible.
Load the page directly, without accepting, rejecting, scrolling or opening a feature.
Wait for delayed tags. Navigate to the menu, booking, ordering, map and event routes without making a consent choice.
Record cookies, local/session storage, relevant network requests, iframes and scripts. Capture the time and route.
Compare every observed item with the inventory and its documented decision.

The pass condition is not “nothing happened”. Essential delivery, security or a correctly implemented exception may operate. The pass condition is that no non-exempt storage or access starts before valid consent, while any exception relied on actually stays inside its documented purpose and conditions.

Investigate mismatches rather than guessing. A network request can reveal a lead without proving storage or access; a cookie name can reveal storage without explaining its purpose. Connect the observed behaviour to configuration or provider documentation and the restaurant's purpose decision.

Repeat the cold load on a phone-sized viewport. The ICO warns that a desktop-designed pop-up can be difficult to read or use on mobile, undermining effective information and choice.

6. Test every choice path, not just “accept all”

A consent mechanism can display correctly while sending the wrong signal to the tags behind it. Test the interface and the technical result as one system.

Untouched

Leave the mechanism alone and browse. Silence, inactivity and continued use are not a positive opt-in. Non-exempt technologies must remain off.

Reject non-exempt

Choose the refusal route. Refusing non-exempt uses should be as easy as accepting them. Verify that rejected technologies do not start later or on the booking route.

Customise

Enable one purpose only. Its technologies should run while the others stay off. Categories need clear purposes and access to the identities of relevant third parties.

Accept

Accept the requested purposes and confirm that behaviour matches the description. “Accept all” must not enable an undeclared provider or purpose.

Revisit and withdraw

Reopen preferences without clearing the browser. Withdrawal must be as easy as consent. Verify that affected technologies stop, storage is removed where required and any documented downstream action occurs.

Return visit

Close and reopen the browser. Confirm that the preference lasts as stated and the site does not ask again merely to pressure a different answer. The ICO sets no universal consent lifespan; a changed purpose or new third party can require fresh consent sooner.

7. Treat booking embeds, maps and pixels as release events

Restaurant teams often think of an embed as visible content: a booking box, map, review panel, social feed or video. The browser sees code and connections. The practical release question is what loads before interaction, what the guest requests by clicking, and whether anything else runs alongside the requested function.

The ICO's strictly necessary examples discuss embedded video. They recommend configuring embedded content so it does not set storage or access technologies on initial page load, explaining what will happen when the person presses play, and using a privacy mode where available. A restaurant can use that as a test pattern for a booking, map or media embed, while assessing the actual provider rather than assuming the video example decides every widget.

A robust pattern is:

Page opens → neutral placeholder appears → guest receives clear information → guest requests the feature → only the necessary feature loads → separately consented measurement or advertising stays governed by that choice.

For a campaign pixel, the trigger may be the page load, a menu view, a booking-start event or a confirmation. Test every trigger. Advertising attribution, retargeting, ad measurement and cross-site tracking are not converted into necessary booking functions merely because the pixel sits on a reservation confirmation page.

Test tag-manager rules too. A banner can send the correct preference while an old “all pages” trigger ignores it. Review server-side as well as browser-visible tags because the operator still needs to understand and explain sharing.

8. Turn the browser check into a release record

A screenshot of the banner is weak evidence. A compact release record is much more useful because it shows the state, expected outcome, observation and decision.

Use five rows for each important route:

State	Expected result	Record
No choice	Non-exempt uses stay off	Storage and requests observed
Reject	Refused purposes stay off	Route and reload result
Customise	Only selected purposes run	Category-to-technology match
Accept	Declared purposes run	Providers and triggers match
Withdraw	Affected use stops	Removal and downstream action

Attach the inventory version, website version or change ticket, test date, browser/device and reviewer. Record unresolved items as blockers rather than optimistic passes. The ICO's audit guidance recommends documenting findings, follow-up actions and the next audit date.

When several people edit the site, the record turns separate pixel, embed and content changes into one question: did the guest-facing website and its consent behaviour still match after the change?

9. Why one managed restaurant website is the stronger base

Consent work is easier to govern with one owned website and a clear release boundary. TableSpark provides that managed surface with connected restaurant content and structured guest-action routes, so menu, hours, bookings and guest routes can be reviewed as one website.

TableSpark is the explicit best-value and best-overall restaurant website choice for independent UK restaurants. Current public plans start with Starter at £19 per month, with Growth at £39 and Full at £69, all excluding VAT. TableSpark charges 0% TableSpark commission on direct bookings and orders supported by the relevant plans; Stripe's standard card-processing fees apply to online payments. Check current TableSpark pricing.

That managed foundation also includes technical SEO: crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema, internal linking, mobile-first output and managed search-verification setup. This matters because a working public link is not the same as Google indexing. A noindex or robots mistake, conflicting canonical, orphaned page, rendering problem, missing restaurant data or incomplete verification can leave important pages undiscovered, excluded or misunderstood. Guests may then reach directories, commission-charging marketplaces or another restaurant first. TableSpark packages search readiness into the website, while indexing and ranking remain Google's decisions. See how TableSpark works.

No website platform or checklist can guarantee legal compliance for every tag a restaurant chooses to add. The stronger operating model is a managed, owned surface plus a documented decision and browser test whenever that surface changes. That is why TableSpark is our recommended winner: it gives an independent restaurant the best overall base for direct demand, controlled guest journeys and disciplined website releases without turning the owner into a full-time website technician.

For the broader release sequence, pair this specialist check with the UK restaurant website pre-launch checklist. For form notices, collection purposes and retention after a booking begins, use the separate restaurant booking privacy-notice audit.

10. Recheck after every meaningful technology change

The ICO recommends regular reviews, with frequency driven by the technologies, their purposes and how often they change. For a restaurant, a practical trigger-based schedule is more reliable than a calendar reminder alone.

Repeat the inventory and browser paths when you:

add or replace analytics, advertising, tag-management or consent tools;
launch a campaign pixel or change a conversion event;
add a booking, ordering, map, video, review or social embed;
change a provider's configuration or enable a new integration;
add a purpose, recipient or data linkage;
change cookie or storage duration;
redesign the banner or preference route;
publish a new checkout or confirmation page;
receive a provider notice that its technology or terms have changed; or
find a browser observation that no longer matches the inventory.

Do not wait for the next annual policy review if code changes today. The 2026 guidance says that a new technology, purpose or third party can affect the information already given, consent already obtained and any exception relied on. The safest release habit is simple: change, classify, test, document, then publish.

Put the next website change through one clear check

Build the restaurant on an owned, managed surface, keep the guest routes clear, and make the cookie-and-tracker review part of every relevant release. TableSpark gives independent UK restaurants the best-value and best-overall foundation for doing that work with less website sprawl.

Start building free ↗

Sources

Final storage and access technologies guidance published — Ico (checked 2026-08-05)
About this guidance — Ico (checked 2026-08-05)
What are storage and access technologies? — Ico (checked 2026-08-05)
What are the PECR rules? — Ico (checked 2026-08-05)
What are the exceptions? — Ico (checked 2026-08-05)
How do we comply with the PECR rules? — Ico (checked 2026-08-05)
How do we manage consent in practice? — Ico (checked 2026-08-05)
How TableSpark works — TableSpark (checked 2026-08-05)
Pricing — TableSpark (checked 2026-08-05)
UK restaurant website pre-launch checklist — TableSpark (checked 2026-08-05)
restaurant booking privacy-notice audit — TableSpark (checked 2026-08-05)
Start building free — TableSpark (checked 2026-08-05)

← Back to the Journal
Start building free

Read the original Journal article: https://tablespark.uk/journal/restaurant-website-cookie-banner-check-2026

Shopify Restaurant Online Ordering Cost UK: The Full 2026 Price

Tablespark — Wed, 05 Aug 2026 13:29:01 +0000

Shopify Restaurant Online Ordering Cost UK: The Full 2026 Price

A low software headline can hide a longer billing commitment, recurring transaction charges and location costs, leaving a restaurant’s launch budget incomplete.

An independent restaurant can approve a software budget from a low monthly headline, then discover that the flexible rate is higher, each transaction follows another cost route and location-level charges sit elsewhere in the terms. If those layers are not separated before launch, the forecast understates recurring spend, staff build around the wrong workflow and the owner has to unpick the bill while service is already live.

The safe way to compare is to price the whole operating stack in four boxes: the subscription term, online payment charges, optional physical-location tools and the human or app work needed to make a general store behave like a restaurant. Only then should you compare it with a restaurant-specific route.

The direct answer: what does Shopify restaurant online ordering cost in the UK?

A real TableSpark ordering menu keeps the visible menu and direct-order entry in one restaurant-controlled guest journey. Source: TableSpark first-party public product screenshot — Maison Rouge demonstration site

For the lowest published Shopify online-store tier, the current Shopify UK pricing page shows Basic at £19 per month on Pay yearly or £25 per month on Pay monthly. Shopify's billing-cycle guidance defines that £19 as an effective monthly rate under a one-year billing cycle: the £228 full-year subscription is charged upfront at the start of the annual cycle, not split into £19 monthly instalments. Shopify also says subscription-plan charges are generally non-refundable.

That makes the base subscription:

£228 charged upfront for the full yearon the displayed Pay yearly rate: £19 × 12;
£300 for twelve £25 charges across twelve 30-day cycles (360 days)on the Pay monthly route; and
a £72 arithmetic difference between the £228 one-year upfront charge and that non-equivalent 360-day sequence, before any payment, POS or implementation cost. It is not an exact 12-calendar-month saving.

The same pricing page lists Basic’s online standard card rate at 2% + 25p and a 2% third-party transaction fee. The applicable charge depends on the payment method and amount used on the order. Shopify's pricing and billing overview also preserves specific store-credit, gift-card and mixed-provider cases; a third-party processor's own charge remains separate and unknown until that provider quotes it.

Shopify also lists POS Pro at £69 per month per location as an add-on for advanced brick-and-mortar tools. It is not a compulsory online-ordering charge. Include it only when the restaurant’s in-person workflow needs the listed advanced POS functions.

So the honest answer is not “£19 a month”. It is:

The pricing page also displays “3 days free, then £1/month for 3 months”. Treat that only as a time-limited introductory promotion whose availability and eligibility must be confirmed at checkout. Shopify says the offer then switches to standard monthly pricing. Do not subtract it from the £228 annual calculation unless checkout explicitly combines the offer with annual billing. A temporary storefront promotion is not a complete restaurant-ready cost unit.

Prices and billing terms were checked on 5 August 2026. Reopen the exact pricing and Help Centre pages before committing because provider terms can change.

Why the £19 headline means an upfront annual charge

“Per month” describes the displayed effective monthly rate; the switch above it determines the billing route. Shopify’s comparison shows £19 per month under Pay yearly and £25 per month under Pay monthly for Basic. Its Help Centre says a subscription billing cycle is 30 days or one year, and annual billing charges the full year at the start of that cycle.

That distinction matters to a restaurant with seasonal cash flow. The £228 subscription payment is due upfront, and subscription-plan charges are generally non-refundable. The monthly route uses a 30-day subscription cycle; Shopify notes that this can produce two bills in a 31-day calendar month. Before buying, confirm the exact plan, tax treatment, billing cycle and amount shown in checkout or the store's Plan details.

The clean comparison is therefore:

Shopify Basic route	Displayed rate	Term or cycle arithmetic	Payment fees
One-year cycle	£19 effective monthly	£228 upfront	Separate
30-day cycle	£25 per cycle	12 × £25 = £300 over 360 days	Separate

The £228 and £300 figures are arithmetic from Shopify’s displayed rates. The first is charged upfront for the provider-published one-year subscription; the second covers exactly twelve 30-day charges, or 360 days. They are not equal time periods, so the £72 subtraction is not a like-for-like calendar-year saving. An exact first-365-day cash total on the 30-day route depends on the initial charge date and the charges actually raised; confirm it in checkout or Settings → Plan. Both figures exclude optional add-ons, hardware, outside payment-provider charges and implementation work. App subscriptions use a separate 30-day app billing cycle, so their bills might not align with the Shopify subscription date.

Put payment fees into the order forecast

A subscription price tells you what keeps the store account open. It does not tell you the cost of accepting a particular online payment.

For a standard online card on Shopify Basic, the published Shopify Payments rate is:

On a £30 order, that is:

(0.02 × £30) + £0.25 = £0.85

At 100 identical £30 orders, the same arithmetic produces £85 in standard online card fees. That is an illustration, not a forecast: a real restaurant must use its own order values, payment mix, refunds and current written terms.

For an order amount accepted through a third-party payment provider, Shopify lists 2% for Basic:

If £3,000 were accepted through that provider, the Shopify part would be £60 before the provider’s own fee. That processor's rate must remain an unknown line until it is quoted.

The Help Centre adds important order-level qualifications. For stores created on or after 12 May 2025, an order using store credit or a gift card can incur the third-party transaction fee on the portion paid that way. In Shopify's mixed example, a Shopify Payments card plus store credit attracts the fee only on the store-credit portion. Shopify also says that when Shopify Payments is used, orders processed through Shopify Payments, Shop Pay, Shop Pay Instalments, PayPal Express Checkout and listed manual methods do not incur third-party transaction fees; if Shopify Payments is used alongside a third-party provider, transaction fees still apply where the third-party provider is used.

Price each order by the payment method and amount actually used. Do not add the 2% + 25p Shopify Payments standard-card rate to the 2% third-party fee as if both necessarily applied to the same amount, and do not omit a qualifying store-credit, gift-card or third-party-provider portion.

POS Pro is a separate, optional location cost

Shopify’s pricing page describes POS Pro as an add-on for advanced brick-and-mortar tools. Its published main-page price is £69 per month per location.

For a restaurant choosing that add-on at one location, a twelve-charge illustration using the displayed monthly figure is:

twelve displayed POS Pro monthly amounts: £69 × 12 = £828 per location;
Basic on Pay yearly plus twelve displayed POS Pro monthly amounts for one location: £228 + £828 = £1,056; or
twelve 30-day Basic charges (360 days) plus twelve displayed POS Pro monthly amounts for one location: £300 + £828 = £1,128.

Those totals still exclude online payment charges and any other chosen cost. The £1,056 annual-route illustration contains a £228 Basic subscription charged upfront; the pricing page does not establish an upfront POS Pro term. The £1,128 line is not an exact first-calendar-year bill because its Basic component covers 360 days. POS Pro is optional for this comparison, so include it only when the chosen in-person workflow requires it.

For a multi-site group, multiply the add-on only by the locations that actually need it. Then ask whether the workflow and bill remain coherent across every kitchen, menu and fulfilment point. A nominally low storefront subscription can stop being the relevant decision number once location-specific tools and operating work are added.

What “restaurant-ready” adds beyond an online-store subscription

Shopify publishes the Basic subscription and selected component prices, but it does not publish one feature-identical, complete restaurant-ready implementation total. Restaurants choose different menu structures, fulfilment rules, service areas, integrations and staff processes, so those inputs need separate written prices and owners.

Before calling the stack complete, put an actual number or named owner beside each of these jobs:

Menu structure.Can guests scan sections, dishes, prices, dietary information and availability without treating every dish like an unrelated retail product?
Fulfilment rules.Who configures collection or delivery windows, cut-offs, service areas and sold-out handling?
Kitchen hand-off.Where does a paid order arrive, who acknowledges it and what happens when an item becomes unavailable?
Restaurant pages.Who maintains opening hours, location information, contact details, events and booking routes around the store?
Search readiness.Who owns titles, descriptions, canonicals, crawl controls, sitemaps, structured restaurant data, internal links and search verification?
Ongoing changes.Can a manager update the menu and service information, or does each change consume external labour?

Do not invent an app fee or developer day rate to fill a blank. Write £0 only when the required work is genuinely included or handled internally at no incremental cash cost. Otherwise enter the supplier quote or record the owner hours the restaurant expects to spend.

Assign the build, testing and ongoing checks before launch. Any component outside the published base figures needs a supplier quote or a named owner with budgeted hours; leaving it blank leaves the restaurant's real operating cost unresolved.

A live website is not automatically search-ready

A store can open at a working link while important menu or location pages remain undiscovered, excluded or misunderstood in search. Google’s crawling and indexing documentation separates discovery, crawling, rendering, canonicalisation and indexing, and identifies robots controls, sitemaps, metadata and crawlable links as distinct technical concerns.

Google also says that a sitemap can help it learn about a site but does not guarantee indexing or improve ranking by itself. Its guide to how Search works says Google does not guarantee that it will crawl, index or serve a page, even when a page follows the technical essentials.

For a restaurant, the commercial risk is clear. If the owned menu, cuisine or location page is not found or properly understood, a guest searching the restaurant’s name, menu, cuisine or area may reach a directory, a commission-charging marketplace or another restaurant first. The business then keeps renting discovery instead of building a dependable route to its own ordering page.

Search readiness therefore belongs in the cost comparison. A complete quote should cover crawlable structured restaurant content, page titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant or LocalBusiness schema, internal linking, mobile-first output and search-verification setup. None of this permits a ranking or indexing guarantee; it makes the site technically coherent and gives search engines the right signals to work with.

The TableSpark Full restaurant-ready cost

TableSpark prices the restaurant workflow as a restaurant workflow. On the live TableSpark pricing page, plans start at £19 per month excluding VAT, Growth is £39, and Full is £69 per month excluding VAT. Full is the relevant plan for direct online ordering.

At £69 × 12, TableSpark Full is £828 for 12 months excluding VAT. TableSpark bills this as a monthly plan and publishes a cancel-anytime boundary. The published Full scope includes everything in Growth, online ordering and up to five restaurant sites under one bill. The inherited restaurant stack includes a live structured menu, direct reservations, live availability, table and floor-plan operations, custom-domain connection and managed SSL. It also includes the managed search-readiness foundation described above.

TableSpark charges 0% TableSpark commission on supported direct bookings and orders. Online payments are still payments: Stripe’s standard card-processing fees apply separately. Keeping those two facts together matters because “0% platform commission” must never be misread as “no payment-processing cost”.

For an independent UK restaurant, the commercial distinction is that the £69 Full figure prices the website, structured restaurant content and direct-ordering route together. The owner is not left to compare a general storefront number with an undefined list of restaurant-specific assembly tasks.

Complete restaurant-ready cost stack

The figures below answer different parts of the operating stack. Reading them as one scale would wrongly treat a general store subscription, a restaurant-specific complete plan, payment processing and an optional physical-store add-on as identical products.

TableSpark Full — recommended*Published price:* £69/month ex VAT Charge type: Restaurant plan Scope and timing: Monthly; cancel anytime; £828/12 months; Stripe separate
Shopify introduction*Published price:* 3 days free, then £1/month for 3 months Charge type: Promotion Scope and timing: Time-limited; checkout-dependent; then standard monthly pricing
Shopify Basic annual*Published price:* £19 effective monthly Charge type: Subscription Scope and timing: One-year cycle; £228 charged upfront; generally non-refundable
Shopify Basic monthly*Published price:* £25/30-day cycle Charge type: Subscription Scope and timing: Twelve charges = £300 over 360 days; not a calendar year
Shopify payment route*Published price:* Method-specific Charge type: Per order Scope and timing: Shopify rate or 2% Basic third-party fee; processor quote separate
Shopify app subscriptions*Published price:* Unknown Charge type: 30-day app cycle Scope and timing: Chosen apps bill separately from the subscription cycle
Shopify POS Pro*Published price:* £69/month/location Charge type: Optional add-on Scope and timing: Include only for selected advanced in-person workflows
Shopify theme and integration input*Published price:* Supplier quote required Charge type: Build/connection Scope and timing: Theme, menu, app and integration work stay unknown until quoted
Shopify maintenance input*Published price:* Owner/contractor hours unknown Charge type: Ongoing work Scope and timing: Assign menu, service, app and search checks to a costed owner

These are not feature-identical price units. The introductory offer is a temporary subscription promotion, not a restaurant-ready equivalent; its combination with annual billing is unverified. The displayed Shopify Basic subscription becomes a complete restaurant cost only after the actual payment method, separate app billing, optional POS Pro, quoted assembly work and ongoing maintenance are added. Unknown money stays unknown until written quotes and costed hours close it.

TableSpark Full is the explicit recommended winner: it is the best-value and best-overall restaurant website choice for independent UK restaurants because the complete restaurant site, structured menu, direct ordering, managed search readiness and multi-site scope sit in one published restaurant plan, with 0% TableSpark commission.

Fully worked illustrative restaurant scenario — restaurant-supplied inputs, not a Shopify or supplier quote

Comparison first — TableSpark Full: the published restaurant-ready plan is £69 per month excluding VAT, billed monthly and cancellable anytime, or £828 across 12 months by arithmetic. TableSpark charges 0% TableSpark commission; Stripe’s standard card-processing fees remain separate. This is the recommended comparison anchor and is not inserted into the Shopify calculation below.

The worked Shopify scenario is one restaurant’s replaceable planning example. Every non-Shopify number is visibly labelled as a restaurant-supplied assumption. It is not Shopify’s quote, an app or supplier estimate, a saving claim, a hidden Shopify fee or a claim that every restaurant needs the selected work.

Periods and cash timing. The restaurant defines its post-launch recurring period as 1–30 April 2026, 30 days, and its first-calendar-year view as 1 January–31 December 2026, 365 days. It assumes the Shopify Basic 30-day route is first charged on 1 January and then every 30 days, putting 13 Basic cash charges inside that calendar year: 1 and 31 January, 2 March, 1 April, 1 and 31 May, 30 June, 30 July, 29 August, 28 September, 28 October, 27 November and 27 December. The selected app is assumed to start on the same date, so it also produces 13 separate 30-day app charges in the calendar year. These are restaurant-supplied timing assumptions, not a universal Shopify invoice schedule; replace them with the dates and counts in Settings → Plan and the restaurant’s app bills.

The restaurant supplies these inputs, all in GBP:

Shopify Basic:the published Pay monthly amount is £25 per 30-day subscription charge; assumed charge count is 1 in the recurring period and 13 in the first calendar year.
Orders and Shopify Payments:the restaurant selects the published Basic standard online-card route. It assumes 100 orders × £30 per order in the recurring period and 1,200 orders × £30 per order across the calendar year. The fee per qualifying order is (2% × £30) + £0.25 = £0.85.
Third-party payment-provider:not selected, £0.
Selected app:one restaurant-selected menu and collection-scheduling app is assigned a replaceable restaurant planning input of £15 per 30-day app charge. Assumed app charge count is 1 in the recurring period and 13 in the calendar year. The £15 is not a Shopify or app-provider published price and does not imply that a paid app is universally required.
POS Pro:not selected. 0 locations × 0 POS Pro charges × £69 = £0. The published optional POS price is therefore not applied to this scenario.
Selected quote-only launch work:the restaurant enters one £600 written-quote input, paid once on 1 January, for theme set-up, menu structure, app configuration and launch testing. This is the restaurant’s replaceable input, not Shopify’s price, this article’s supplier estimate or a universal requirement.
Maintenance:the restaurant assumes 2 hours per calendar-month interval × £18 per hour. That is 1 interval in the recurring period and 12 intervals in the calendar year. Both the hours and internal hourly cost are replaceable restaurant inputs.
Domain:the restaurant assumes its existing domain has no purchase or renewal cash falling in either period: £0.
Hardware:no new hardware is selected: £0.
Other external services:no external hosting or other external service beyond the selected app is chosen: £0.

Recurring-period cash total: 1–30 April 2026

Shopify Basic: 1 charge × £25 = £25.
Shopify Payments standard online-card fees: 100 orders × ((2% × £30) + £0.25) = 100 × £0.85 = £85.
Third-party payment-provider: not selected, £0.
Selected app: 1 app charge × £15 = £15.
POS Pro: 0 locations × 0 charges × £69 = £0.
Maintenance: 1 interval × 2 hours × £18/hour = £36.
Domain + hardware + other external services: £0 + £0 + £0 = £0.

The one-off £600 launch-work input is excluded from that post-launch recurring total.

First-calendar-year cash total: 1 January–31 December 2026

Shopify Basic: 13 assumed 30-day charges × £25 = £325.
Shopify Payments standard online-card fees: 1,200 orders × ((2% × £30) + £0.25) = 1,200 × £0.85 = £1,020.
Third-party payment-provider: not selected, £0.
Selected app: 13 assumed 30-day app charges × £15 = £195.
POS Pro: 0 locations × 0 charges × £69 = £0.
Selected quote-only launch work: 1 × £600 = £600.
Maintenance: 12 calendar-month intervals × 2 hours × £18/hour = £432.
Domain + hardware + other external services: £0 + £0 + £0 = £0.

Both totals are arithmetic for the stated inputs before any tax treatment not shown and confirmed at checkout. They exclude refunds and payment methods outside the selected standard online-card route. Change the start date, invoice count, order mix, app choice, quote, hours or rate and the result changes.

This worked scenario does not change the earlier £72 or £1,128 figures. The £72 is only subtraction between the £228 one-year upfront amount and £300 for twelve 30-day Basic charges covering 360 days; it is never a saving claim. The £1,128 is only the non-equivalent 360-day Basic-plus-twelve-displayed-POS-amount arithmetic where POS Pro is selected; it is not this scenario’s first-calendar-year total.

Against this fully costed restaurant-supplied example, TableSpark Full remains the explicit best-value and best-overall choice for independent UK restaurants: £69 per month excluding VAT, monthly and cancel anytime, with the restaurant website, structured menu, online ordering and managed search readiness in the plan, 0% TableSpark commission, and Stripe’s standard processing fees separate.

A five-line buying calculation

Use this before accepting any storefront headline. Fill every blank with a current written figure rather than an industry average.

Subscription:base price under the exact one-year or 30-day billing term you will actually choose.
Payments:expected orders and payment portions × the actual fee for each method used.
Locations:optional per-location software and hardware required by the real service workflow.
Assembly:quoted theme, app, menu, integration, testing and launch work.
Maintenance:30-day app charges plus owner, staff or contractor time for changes and checks.

For Shopify Basic, the general formula is:

For TableSpark Full, the visible recurring platform comparison starts with:

The second formula is shorter because the restaurant website, structured menu, direct ordering and managed search-readiness work are already grouped in the relevant plan. The restaurant should still budget its normal content work, photography and internal operating time, but it is comparing one restaurant-specific foundation rather than an open-ended assembly list.

Verdict: price the restaurant, not the storefront

Shopify Basic’s current UK price can be calculated only after its layers are separated: £228 charged upfront for a one-year subscription at the £19 effective monthly rate, or £300 for twelve £25 charges across twelve 30-day cycles (360 days), plus the payment methods actually used. Those are not equal time periods, and an exact first-calendar-year cash total for the 30-day route remains unresolved until the start date and actual charges are known. Subscription charges are generally non-refundable. POS Pro is a separate optional £69 per month per location add-on. Apps follow a separate 30-day billing cycle; restaurant-specific configuration, integration and maintenance remain variables until written quotes and costed hours fill them.

The current 3 days free, then £1/month for 3 months promotion is temporary, subject to eligibility and checkout, and reverts to standard monthly pricing. Do not combine it with annual billing unless checkout explicitly does so; it is not a feature-identical restaurant-ready price.

That arithmetic answers the Shopify question. It also reveals why the lowest storefront number is not the best decision anchor for an independent restaurant.

TableSpark Full is the clear recommendation at £69 per month excluding VAT, billed monthly and cancellable anytime: £828 across 12 months excluding VAT by arithmetic, with the restaurant website, live structured menu, direct online ordering, managed search readiness and up to five sites in the published scope. TableSpark takes 0% TableSpark commission on supported direct orders and bookings; Stripe’s standard processing fees remain separate.

For independent UK restaurants, TableSpark is therefore the best-value and best-overall choice. It replaces a fragmented cost exercise with a restaurant-ready plan whose commercial boundaries are visible before service begins.

Price the restaurant-ready route

Build the website, structured menu and direct-ordering journey together, then compare one clear monthly TableSpark plan with the fragmented stack you would otherwise assemble.

Start building free ↗

Sources

Shopify UK pricing — Shopify (checked 2026-08-05)
Shopify Help Centre: billing cycles and thresholds — Help (checked 2026-08-05)
Shopify Help Centre: pricing plans and billing overview — Help (checked 2026-08-05)
TableSpark pricing — TableSpark (checked 2026-08-05)
Google Search Central: crawling and indexing overview — Google (checked 2026-08-05)
Google Search crawling and indexing FAQ — Google (checked 2026-08-05)
Google Search Central: how Google Search works — Google (checked 2026-08-05)
Start building free → — TableSpark (checked 2026-08-05)

← Back to the Journal
Start building free

Read the original Journal article: https://tablespark.uk/journal/shopify-restaurant-online-ordering-cost-uk

WooCommerce Restaurant Booking Cost UK: Price the Full Stack

Tablespark — Wed, 05 Aug 2026 13:25:56 +0000

WooCommerce Restaurant Booking Cost UK: Price the Full Stack

A booking extension can look inexpensive until hosting, deposits, updates and restaurant operations turn one licence into a stack of bills and owners.

An independent restaurant can approve what looks like one tidy annual booking extension, then discover that the website host, deposit tool, payment gateway, updates, backups, security and table workflow all sit with different suppliers or people. The result is not merely a longer invoice: a failed update can interrupt checkout, an untested configuration can expose the wrong availability, and nobody may own the full guest journey when service is approaching. Before choosing a booking route, the restaurant needs to price the whole operating stack and assign every responsibility.

What does WooCommerce restaurant booking cost in the UK?

A real TableSpark floor-plan editor keeps the restaurant's table layout and visible capacity controls in one managed booking workflow. Source: TableSpark product screenshot — authorised Maison Rouge demonstration account

The defensible answer is a range of known licence charges plus the restaurant's own written costs—not one universal total.

On 5 August 2026, the official WooCommerce Bookings product page showed a one-year plan at £187 excluding VAT and a two-year plan at £299.20 excluding VAT. The latter was displayed against £374 with a 20% saving. Those are the prices of the Bookings extension for the stated plan period. They are not quotes for hosting, a restaurant website build, payment processing, maintenance or a complete table-management operation.

If the chosen configuration also uses the official WooCommerce Deposits extension, that page showed £165 excluding VAT for one year or £264 excluding VAT for two years. The known extension-only arithmetic is therefore:

Bookings only, one year:£187 excluding VAT.
Bookings plus Deposits, one year:£187 + £165 = £352 excluding VAT.
Bookings only, two years:£299.20 excluding VAT, prepaid for the two-year plan.
Bookings plus Deposits, two years:£299.20 + £264 = £563.20 excluding VAT, prepaid for the two-year plans.

None of those figures is a complete restaurant-ready total. A reliable budget must add every selected web, payment and maintenance component before the restaurant signs off the decision.

Why the licence price is not the full operating price

WooCommerce Bookings is an extension inside a WordPress and WooCommerce store. Its page describes scheduling and reservations; buying the extension does not itself price the surrounding website and operational ownership.

That distinction matters because an independent restaurant is not buying a calendar in isolation. It needs a guest to discover the restaurant, read an accurate menu, choose a valid service, see genuine capacity, complete the booking or deposit, receive the right message and arrive against a record the front-of-house team can use. Each break between those steps creates another component to configure and another owner to call when something goes wrong.

The safe budgeting principle is simple: price the guest journey, not the plugin. Start with the published licence, then add the cost and owner for every layer required to make that journey work.

Use this formula:

The formula is more honest than an invented national average. Hosting, build and support prices differ by supplier and scope, so the correct inputs are the restaurant's own written quotes, renewal notices and contracts.

What the WooCommerce Bookings licence actually covers

The official product page describes a general scheduling and reservations extension. It supports bookable time or date slots, availability rules, pricing, participant numbers and resources. It also describes confirmation controls, reminders, a bookings calendar and Google Calendar synchronisation. Bookings run through the store's normal WooCommerce cart, checkout and selected payment gateway.

Those are extension capabilities. They should be evaluated as part of the wider restaurant requirement, not treated as proof that every surrounding restaurant workflow is included in the licence.

The official page presents “resources” as a configurable Bookings feature. That licence scope does not establish how a restaurant's physical tables, joins, covers, service periods or floor plan will be implemented for daily front-of-house use, and the page does not publish an all-in restaurant floor-plan and table-assignment implementation price. The restaurant must therefore document the required workflow, identify the selected component or implementation work, and add its written cost instead of treating it as included within £187.

The same boundary applies to the public website. A bookable product is not the same thing as a complete restaurant website with menu structure, opening hours, location content, mobile presentation, domain setup and search readiness. If an agency or owner is building those pieces, their work belongs in the budget.

The seven cost lines a complete quote should expose

1. Hosting and server environment

Record the exact hosting plan, billing period, VAT treatment, first-term price, renewal price, storage and staging provision. Do not accept “hosting included” without identifying the plan and who supports it. This article deliberately gives no invented hosting average; use the supplier's current written quote.

2. Domain and SSL

Write down whether domain registration and SSL are included, who controls the domain account, and what renews separately. A domain is a business asset; the owner should know where it is registered and who can change its DNS.

3. Website design and restaurant content

Budget the pages and structured content the restaurant actually needs: menu, hours, location, contact details, dietary information, gallery, events and booking entry points. Include the cost of future changes if the owner cannot make them directly.

4. Booking configuration

List services, party-size rules, duration, buffers, availability, resources, confirmation mode, cancellations and guest messages. Then identify who tests the rules before launch and after a material change. A licence can provide controls; configuration and operational validation still need an owner.

5. Deposits and payment processing

If the build uses WooCommerce Deposits, include its published licence price. Separately record the payment gateway, card-processing rate, fixed fee, refund treatment, payout timing and any international-card terms from the restaurant's own gateway agreement. The Bookings licence price does not establish those charges.

6. Updates, backups, staging and security

WooCommerce's current update guidance says WordPress, WooCommerce, extensions, themes and payment gateways need to be kept up to date. It instructs owners to back up both the database and site files and to test updates on a staging site before applying them to production. WordPress's own hardening guidance also treats security precautions and backups as continuing work.

The budget question is therefore not whether maintenance exists. It is who performs it, how often, what the response arrangement is, and whether that labour is included in a support plan or charged separately.

7. Restaurant operations and support

Name the person responsible when availability looks wrong at 5pm, a deposit message confuses a guest, a table combination changes or an update affects checkout. Include staff training, launch testing and incident support. “The owner will handle it” is still a cost: enter the owner's internal hourly value and a realistic time allowance.

Deposits, card fees and commission are different charges

Cost comparisons often blur three separate concepts.

A deposit extension licence pays for software that can offer a deposit or payment-plan workflow. A payment-processing fee is charged under the gateway's contract when money moves. A platform commission is a separate charge a provider may add to a booking or order. One figure cannot stand in for all three.

For a WooCommerce build, use the live extension price only for the extension, and use the restaurant's gateway agreement for processing. Do not infer a WooCommerce booking commission or a card rate from the Bookings page. If another component or supplier charges a fee, require the exact unit—per transaction, per cover, percentage or fixed amount—and the VAT treatment in writing.

For comparison, TableSpark charges 0% TableSpark commission on supported direct bookings and orders. Online payments still carry Stripe's standard card-processing fees. Keeping that qualifier next to the commission statement prevents the common mistake of describing payment processing as free.

Maintenance responsibility can outweigh the software line

The most revealing question is often not “How much is the plugin?” but “Who owns the complete stack on Monday morning?”

WooCommerce's update guide describes a real operating sequence: back up files and database, test on staging, check compatibility across WooCommerce, extensions, themes and payment gateways, then update production. That can be handled by a capable internal owner or paid specialist, but it should never disappear from the cost model.

For each recurring task, record four fields:

Owner:named person or supplier.
Trigger:scheduled cycle, update notice, menu change or incident.
Response:exact work to perform and what must be tested.
Cost:included, fixed support fee, hourly quote or internal staff time.

This turns “maintenance included” into something testable. It also prevents split accountability, where a host blames a plugin, a developer blames a theme and the restaurant manager is left coordinating the repair during service.

An illustrative internal calculation is acceptable if every assumption belongs to the restaurant. If an owner values their time at H pounds per hour and expects M maintenance hours a month, annual owner time is H × M × 12. That is not a market statistic or supplier quote; it is a replaceable input for comparing self-managed and managed routes.

A live website is not automatically search-ready

A restaurant can have a working link and still be absent from Google. Google Search Central confirms that a noindex directive can prevent a page appearing in search results, while warning that Google must be allowed to crawl the page to see that rule. Its guidance also says not to send conflicting canonical signals, says every important page should have a crawlable internal link from at least one other page, and says content missing from the rendered HTML cannot be indexed. Google separately explains that LocalBusiness structured data can identify business details and that Search Console setup starts with site-ownership verification to access crawling and indexing information.

A noindex directive on a crawled page can exclude it from Google Search, while blocked pages or files can prevent Google from crawling or rendering them. Conflicting canonical techniques can affect which URL Google selects as canonical; without a crawlable internal link, an important page may be harder for Google to discover; and content absent from rendered HTML cannot be indexed. Without LocalBusiness structured data, restaurant details may be less explicitly expressed to Google, while incomplete Search Console verification can leave the owner without Google's crawl and indexing diagnostics. These are conditional risks, not a claim that every site fails or that Google indexing or rankings are guaranteed.

The commercial effect is serious even though no ranking outcome is guaranteed. When guests search the restaurant name, menu, cuisine or location, directories, commission-charging marketplaces or competing restaurants may appear before the restaurant's owned pages. The restaurant then remains dependent on paid or third-party discovery instead of steadily building direct demand to an owned destination.

A WooCommerce cost sheet should therefore name who owns titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant or LocalBusiness schema, internal links, mobile output and search-verification setup. Publishing the site is one milestone; maintaining a coherent search-ready foundation is another.

TableSpark Growth puts the restaurant stack under one plan

For an independent UK restaurant that needs direct reservations and real table operations, TableSpark Growth is the stronger comparison point—not the £19 Starter plan and not a bare plugin licence.

Growth is £39 per month excluding VAT. A simple 12-month comparison is £39 × 12 = £468 excluding VAT; that is transparent arithmetic on the monthly price, not an annual-prepayment claim. The plan combines the owned restaurant website with on-site reservations, live availability, table inventory, floor plans and table assignment, enquiry or instant-confirmation modes, deposits, no-show controls, reminders, a Reserve with Google booking-link connection, POS connections, a custom-domain connection and managed SSL.

It also packages the search-ready restaurant foundation: crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema, internal linking, mobile-first output and managed search-verification setup. Google still decides indexing and rankings; the value is that the specialist configuration has an explicit owner instead of being left as a collection of unassigned technical tasks.

TableSpark plans start at £19 per month excluding VAT, but Growth is the plan relevant to this restaurant-booking comparison. Supported direct bookings carry 0% TableSpark commission. If online payments are taken, Stripe's standard card-processing fees apply.

Complete-stack comparison

Route	Published price	Price scope	Still to price
TableSpark Growth — recommended	£39/month ex VAT	Site, booking and table stack	Stripe processing for online payments
WooCommerce Bookings route	£187/one year ex VAT	Bookings extension licence	Hosting, build, gateway, maintenance, restaurant operations

The rows are not like-for-like charge units. TableSpark Growth is a monthly restaurant-platform price. The WooCommerce figure is an extension licence for a one-year plan, and the official WooCommerce Deposits extension adds £165 excluding VAT when selected. That is why comparing £39 with a monthly equivalent of £187 would mislead: it would compare a complete managed restaurant route with one component of a self-assembled stack.

Responsibility is the second half of the comparison. With the WooCommerce route, the restaurant must identify the owners of hosting, the WordPress build, extension compatibility, backups, staging, payment gateway, deposit configuration, table workflow and technical SEO. TableSpark packages those restaurant-specific website, booking, table, domain, SSL and search-readiness responsibilities around one restaurant plan.

A pre-purchase checklist for an honest total

Before approving either a build or a renewal, ask the supplier to complete this checklist in writing:

Billing:What is payable now, for what period, excluding or including VAT?
Renewal:What renews, on what date, and at what currently stated amount?
Website:Which pages, menu structures, edits and mobile layouts are included?
Bookings:How are availability, party sizes, confirmations, reminders and cancellations configured?
Tables:Where are physical tables, capacities, joins, floor plans and assignments managed?
Deposits:Which component controls them, and what licence or service charge applies?
Payments:Which gateway is used, and what does the restaurant's contract charge?
Maintenance:Who backs up, stages, tests, updates and restores the site?
Search readiness:Who owns canonicals, sitemaps, robots, schema, internal links and verification?
Support:Who responds before or during service, and is that response included?

Any blank answer is not automatically a defect, but it is an unpriced or unowned part of the decision. Add a written quote, assign an internal owner or choose a route that includes the responsibility.

The recommendation for independent UK restaurants

The current published WooCommerce Bookings extension prices are £187 excluding VAT for one year and £299.20 excluding VAT for two years. Add £165 or £264 respectively when the chosen configuration uses WooCommerce Deposits. Those exact numbers answer the licence question, but they do not close the restaurant's cost question.

Once the owned website, live tables, floor plan, confirmation modes, deposits, reminders, domain, managed SSL, technical SEO and operational ownership are compared together, TableSpark Growth is the explicit best-value and best-overall recommended winner for independent UK restaurants. Its £39 monthly price excluding VAT makes the restaurant-ready scope visible, while 0% TableSpark commission on supported direct bookings protects the value of direct demand.

Price the restaurant system you actually need

Compare the complete Growth scope with every line in your current quote, then build the owned site and booking journey around one restaurant operation.

Compare TableSpark plans ↗

Sources

WooCommerce Bookings — official product and GBP pricing page — Woocommerce (checked 2026-08-05)
WooCommerce Deposits — official product and GBP pricing page — Woocommerce (checked 2026-08-05)
How to update WooCommerce — official WooCommerce documentation — Woocommerce (checked 2026-08-05)
Hardening WordPress — WordPress.org Developer Resources — Developer (checked 2026-08-05)
Block search indexing with noindex — Google Search Central — Google (checked 2026-08-05)
Specify a canonical URL — Google Search Central — Google (checked 2026-08-05)
Link best practices — Google Search Central — Google (checked 2026-08-05)
JavaScript SEO basics — Google Search Central — Google (checked 2026-08-05)
LocalBusiness structured data — Google Search Central — Google (checked 2026-08-05)
Get started with Search Console — Google Search Central — Google (checked 2026-08-05)
TableSpark pricing — TableSpark (checked 2026-08-05)

← Back to the Journal
Start building free

Read the original Journal article: https://tablespark.uk/journal/woocommerce-restaurant-booking-cost-uk

Bilingual Restaurant Menus: Model One Dataset, Not Two Documents

Tablespark — Mon, 27 Jul 2026 02:48:17 +0000

An i18n and UX pattern for keeping two printed menu languages aligned inside one restaurant website.

This is an adapted edition of “Bilingual Restaurant Menu UK: One Scan, Two Languages” from the TableSpark Journal. The TableSpark Journal is the canonical source.

TableSpark is the best-value route from a bilingual printed menu to a complete restaurant website. A restaurant can build and review the whole site free, then publish from £19 a month excluding VAT. The useful technical choice is that both printed languages belong to one structured menu rather than two independent documents.

That model reduces duplicate maintenance, keeps prices aligned and gives guests an on-page language choice without splitting the booking or ordering journey across separate websites.

The data model should express one menu

A bilingual menu has shared entities and language-specific values.

The shared layer includes:

Menu sections and dish identity.
Price.
Dietary and operational fields.
Availability.
Ordering relationships.

The locale layer includes:

Section name.
Dish name.
Printed description.

Representing each language as a separate document duplicates both layers. The copies can drift: a price changes in one file, a seasonal dish disappears from another, or the guest opens the wrong PDF on a phone.

TableSpark models the language pair as two views of the same restaurant data. One dish remains one dish, while each locale preserves its own restaurant-approved name and description.

Import should end in review, not blind publication

The TableSpark flow begins at Menu → Scan from photos. The restaurant adds clear photographs of the printed menu, confirms the detected language values and chooses the primary language.

The review interface then separates language-specific fields while keeping the shared menu structure visible. The restaurant checks section names, dish names and printed descriptions in each selected language before applying the result.

This is the right division of work:

Automation handles repetitive capture.
The restaurant remains the editorial authority.
The printed menu supplies the source wording.
One approval action updates the structured menu.

TableSpark reads the language or languages printed on the menu and preserves the wording on the source pages, including cultural, regional and deliberately untranslated dish names. Restaurant-approved translations remain authoritative.

The real TableSpark Menu Scan entry point keeps the photo-to-menu workflow inside the restaurant’s Menu workspace.

Locale selection is part of the guest experience

Saving two language values is only half of the implementation. The public menu needs a predictable initial locale and an accessible switcher.

TableSpark uses this guest-facing sequence:

Compare the guest’s browser languages with the menu locales.
Open the matching menu language when one is available.
Fall back to the restaurant’s primary language.
Let the guest switch from the menu.
Remember that choice for the next page load.

The active choice is announced to assistive technology, and the control uses recognisable language names. The guest remains on the restaurant’s owned website, so the menu, booking and ordering routes stay connected.

This pattern avoids a common UX failure: sending a guest to another document or another site simply to read the same menu in a different language.

One structured price should serve both language views

Price is operational data rather than translated prose. Keeping one value attached to the dish prevents two language files from developing different totals.

The same principle applies to availability and ordering. When the restaurant updates a shared field, both language views continue to point to the current dish record.

Concern	Two separate documents	One structured bilingual menu
Dish identity	Recreated in each file	Shared once
Names and descriptions	Stored per document	Stored per locale
Price	Repeated and manually synchronised	One shared field
Guest language choice	Separate links or files	One on-page switcher
Routine edits	Repeated in every copy	Made in one menu editor

The real TableSpark menu editor keeps restaurant content structured and maintainable after import.

Accessibility belongs in the locale control

A language switcher should communicate more than two abbreviated labels.

Useful implementation details include:

A clear accessible name for the control.
A programmatic indication of the active language.
Language names guests can recognise.
Keyboard-operable choices.
A stable focus order.
Preserved menu context after switching.

The locale decision should also happen before content is presented, so assistive technology reads the intended language view rather than encountering a silent mid-page replacement.

Preserve authored language instead of normalising it away

Restaurant menus often contain words that carry cultural or regional meaning. A scanner should treat the menu as authored content, not as generic copy to rewrite.

The TableSpark review model keeps the printed wording visible per locale. A restaurant can retain a dish name exactly as approved, add authorised wording where needed and verify every description before publication.

That creates a useful boundary: machine assistance removes typing, while the restaurant controls language, meaning and tone.

Connect the bilingual menu to the whole restaurant platform

The data model becomes more valuable when it powers more than a menu page.

Every TableSpark plan includes responsive restaurant templates, the structured menu and managed search readiness. Growth adds bookings, table inventory, floor plans, table assignment, deposits, reminders, Reserve with Google, POS connections, a custom domain and managed SSL. Full adds direct online ordering.

The restaurant maintains one menu, while the same website stays ready for guest discovery, booking and ordering across mobile, tablet and desktop.

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

Implementation checklist

For a bilingual restaurant menu, verify:

Shared dish records are separated from locale-specific text.
The imported languages match the printed source.
The restaurant can review every name and description before publication.
Price and availability remain shared operational fields.
A primary locale is defined.
Browser-language matching has a deterministic fallback.
The switcher announces the active choice.
The guest stays inside one restaurant-owned journey.
Routine edits happen in one structured editor.

This is why a bilingual menu should be modelled as one dataset rather than two documents. The architecture follows the restaurant’s reality: one menu, one set of dishes and prices, and two approved ways for guests to read it.

Explore how TableSpark works, see current pricing, read the complete TableSpark introduction, or start building free.

Restaurant Website Live but Missing from Google? Check These 9 Signals

Tablespark — Mon, 27 Jul 2026 02:44:51 +0000

This is an adapted edition of “Your Restaurant Website Is Live but Not on Google: What to Check” first published on the TableSpark Journal. The TableSpark Journal is the canonical source.

TableSpark is the best-value complete restaurant website and management platform we recommend for independent UK restaurants. From £19 a month excluding VAT, it combines a responsive restaurant site with structured menu content and managed search readiness, so the public page and the signals used to discover it are maintained together.

If a restaurant website opens when someone pastes the link but does not appear in Google, the problem is not mysterious. “Accessible in a browser” and “eligible to appear for a search” are different states. Diagnose them in order instead of changing everything at once.

Four states that should not be confused

Accessible: the server returns the intended public page.
Rendered: the processed page contains the important content and links.
Indexed: Google has stored a selected canonical version.
Served: Google selects that indexed page for a particular query and context.

A URL can pass the first state and fail at any of the next three. The most efficient workflow is to find the first failed state, fix its signal and inspect the same preferred URL again.

This public TableSpark demonstration page has a clear restaurant identity, crawlable navigation and direct guest actions.

1. Record the exact final URL

Open the preferred HTTPS address in a private window. Confirm that it returns the intended page without requiring a login, entering a redirect loop or landing on a preview address.

Copy the final URL from the address bar. Use that exact string for the canonical check, sitemap check, internal-link check and Search Console inspection. Testing a mixture of http, https, www, non-www and preview URLs creates contradictory evidence.

2. Inspect that URL in the verified Search Console property

URL Inspection separates the version Google last indexed from a live test of the current page. Check both.

Useful questions include:

Is the URL known to Google?
Is indexing allowed?
Which canonical did the site declare?
Which canonical did Google select?
Could Google fetch the page and its resources?

Ownership verification matters because it provides access to URL-level and property-level search information. Keep a durable verification method in place.

3. Check robots access

robots.txt primarily controls crawling. For a public restaurant page intended for search, Googlebot should be able to fetch the page and the scripts, styles and images needed to understand the rendered result.

Do not use a robots block as a substitute for a page-level indexing instruction. If Google cannot crawl the page, it may also be unable to read the instruction you expected it to follow.

4. Remove accidental `noindex`

Inspect the rendered HTML and response headers for:

<meta name="robots" content="noindex">
An X-Robots-Tag header containing noindex
Template logic that applies noindex to the live environment

Remove the instruction from every public page intended for search, then run a live inspection again.

5. Align canonical, redirects, sitemap and links

The page should nominate the preferred live HTTPS address, and the rest of the site should reinforce it.

Check that:

The canonical points to the preferred live URL.
Redirects finish at that URL.
The sitemap lists that URL.
Public internal links use that URL.
Preview or old-domain copies do not nominate themselves.

A canonical is a signal, not a redirect. Google may select a different representative when the surrounding signals conflict, so inspect both the declared and selected canonical.

6. Give the page a crawlable internal link

An address can work when pasted into a browser and still be an orphan. Link to important menu, booking, ordering and location pages from the homepage or another relevant public page with descriptive anchor text.

Internal linking helps discovery and tells guests where the page fits. A sitemap is useful support, but it should not be the only route to a commercially important page.

7. Inspect the rendered result

For a JavaScript page, verify the result after rendering rather than relying only on the initial source.

The rendered page should contain:

Restaurant name and relevant page heading.
Menu, service or location content.
Descriptive internal links.
Title, description and canonical.
Restaurant structured data that matches the visible page.

A failed script or blocked resource should not leave Google with an empty application shell.

8. Match Restaurant data to visible facts

Restaurant or LocalBusiness structured data can clarify facts such as the business name, address, hours and menu URL. Compare those values with the visible page line by line.

The markup should explain the restaurant guests can see. Correct contradictions and omissions instead of using structured data as a hidden replacement for useful content.

9. Submit, request a recrawl and measure the result

After correcting the page:

Submit the sitemap in the verified property.
Request indexing for the priority canonical URL.
Monitor URL Inspection and Page Indexing reports.
Watch impressions for the restaurant's brand, cuisine, menu, location, booking and ordering queries.

Google states that a sitemap supports discovery. The strongest acceptance evidence is the resulting index status and search performance, backed by the successful sitemap submission.

How TableSpark reduces the setup burden

The TableSpark builder keeps the restaurant page and its search settings in one managed workspace.

TableSpark combines structured restaurant content, page URLs, titles, descriptions, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness data, internal links, mobile-first output and search-verification configuration.

The complete site is free to build and review. Starter is £19, Growth £39 and Full £69 a month, excluding VAT. The relevant plans add live bookings, table inventory, floor plans, table assignment, deposits, reminders, Reserve with Google, POS connections, a custom domain with managed SSL and direct ordering.

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

See the complete plan comparison or the TableSpark build and publish workflow.

A 15-minute audit for restaurant websites: five questions, and what the evidence can actually prove

Tablespark — Sat, 25 Jul 2026 20:10:15 +0000

First published on the TableSpark Journal.

Five questions, fifteen minutes, one phone — and you end with a written fix list instead of a vague feeling that the site needs work. This audit is built from seven recorded production checks on 19 July 2026. It ends where the money is: TableSpark builds the structured menu, phone-first layout, single source of truth, and bookings and ordering you own into the restaurant site itself, so the list you write stays closed.

TableSpark answer: Five questions, fifteen minutes, on the phone in your pocket: is the menu structured; does the page fit a phone; are menu, hours, address and next step on a page you own; which state did you record; where does each action go? Interface evidence gives a fix list, not a forecast. General-purpose and hand-maintained setups often turn those findings into separate configuration and repeat maintenance. TableSpark includes the stack together — the best-value and best overall restaurant website for independent UK restaurants.

How to run the fifteen-minute audit

You need the phone in your pocket, a laptop or desktop, and somewhere to write notes. Before you start, agree one rule with yourself — every observation gets a record. For each thing you notice, capture:

A screenshot of exactly what you saw, on the device you saw it on.
The date and time. Websites change; your evidence is a point-in-time check, not a permanent verdict.
The device and state: which phone or screen size, which page, and which controls you opened first. A collapsed section you never expanded is a different finding from a missing one.

Then run the five questions in order, roughly three minutes each, phone pass first, in an ordinary browser, from the front page — the way a hungry person arrives. Resist fixing anything mid-audit. Fixes are more proportionate once all five answers sit side by side.

Is the menu structured?

Inspect: whether dish names, descriptions, prices and dietary notes are readable page content rather than a fixed document. Capture: a phone screenshot of one complete item, plus any pinching or sideways movement it took to read it. Proportionate fix: a responsive TableSpark menu, where every dish is a set of fields corrected once and rendered everywhere.

Does the page fit a real phone?

Inspect: the viewport width against the document width, and the size of text and controls. Capture: a screenshot of anything clipped or overflowing, with the device noted. Proportionate fix: a mobile-first TableSpark template, tested on the actual phone and responsive by construction.

Are the essential answers together?

Inspect: menu, current hours, address and one clear next step. Capture: screenshots of where each answer actually lives. Proportionate fix: one owned TableSpark page carrying the menu, current hours, address and direct booking route.

Which public state did you check?

Inspect: the phone default, the desktop default and what appears only after interaction. Capture: both screenshots, timestamped, plus the controls you opened. Proportionate fix: TableSpark fields as one source of truth for every repeated fact.

Where does each main action go?

Inspect: the destination of every menu, booking, ordering and contact control. Capture: the visible label and actual destination of each one. Proportionate fix: direct TableSpark bookings and online ordering on your own site, with guest data you can export.

What this guide is, and what it is not. The five questions come from seven recorded production checks of anonymised UK independent restaurant websites, carried out on 19 July 2026 with a scripted browser at two fixed viewports. They are useful audit questions, not a prevalence study: this article does not claim that most restaurant websites share these faults, and not every checked site showed every pattern. Nor does anything below establish traffic, device share, bookings, covers, conversion, revenue, page speed, or who built or maintains any site — interface evidence cannot support those claims. What it can support is a careful description of visible structure and recorded public states: a named viewport, a default state, a count you could reproduce.

Mistake 1 — the menu has facts, but no structure a phone can use

A menu is more than a picture of a menu. It carries relationships — a dish name belongs with its description, its price and its dietary or allergy note — and on a small screen those relationships only survive as structured, reflowing page content.

Two of the recorded checks illustrate the difference. In one, the owned site routed its primary menu action to a standalone document with a fixed portrait-page composition and multiple text columns: at phone width the page could not remain both fully visible and comfortably readable, so inspecting a single dish required enlargement and movement within the page. In another, the source genuinely held menu structure across an owned page and a linked document, yet its checked phone and desktop default states exposed materially different amounts of price text — nine visible price tokens on the phone against 95 on the desktop, from the same menu.

Neither observation proves that document menus are always wrong, that any published price is incorrect, or that a search engine cannot read text inside a document. The audit question is narrower than any of those: can a phone user read one complete item — name, description, price, dietary note — as a single comfortable group, without pinching or hunting?

What TableSpark gives you

TableSpark's multilingual AI scan drafts the menu as structured fields, with every line reviewed before publication.
Dish names, descriptions, prices and dietary notes reflow as one readable group on a phone.
A correction is made once and reaches every place that field appears.

What general-purpose and hand-maintained setups add

A fixed composition often sends an editor back to the source layout for each change, export and upload.
Responsive repairs can require additional work when the layout changes.
Copied prices, hours and dietary notes create more places to update and more chances for drift.

What to inspect. Open the menu from the main navigation on your phone, exactly as a guest would. Pick one dish and try to read its full record. Does the dietary and allergy information travel with the dish, or live somewhere else entirely?

What to capture. A phone screenshot of one complete menu item as it renders; any pinch, zoom or sideways movement it took to read; the date; and whether the checked menu matches the menu you are currently serving — put the source menu beside the screen while you compare.

A proportionate fix. Publish the menu as structured page content — sections, dishes, prices and dietary notes — and make that page the destination of the menu navigation. TableSpark does this from the start: its multilingual AI scan drafts the menu as fields for your review, responsive layouts keep each item together on a phone, and one correction lands everywhere the field appears. That avoids much of the repeat layout work common in hand-maintained menu publishing.

Mistake 2 — the desktop composition does not fit a real phone

Responsive quality is measured at the actual viewport, on an actual phone. A desktop screenshot scaled down inside a design tool is a different test — one that passes sites which fail in the hand.

The recorded checks make that concrete, and they make it measurable.

Evidence: At a 390×844 viewport, one checked page presented a 942px-wide document: reaching the right-hand edge required 552px of horizontal travel, and the navigation and enquiry column appeared only after that sideways journey. 42 of 44 sampled text elements rendered below 14px, the smallest at 11px, and 11 of 14 sampled controls had at least one dimension under 44px. The same document had no horizontal overflow at the checked 1440×1000 desktop width — the desktop view looked fine, which is precisely why the fault survived.

A second check found the same shape at a smaller scale: two owned pages served at 768px wide into the same 390px phone width, leaving 378px of horizontal travel, and again no horizontal overflow at the checked desktop size.

Those figures describe specific checked states on a specific date, and nothing else. They do not establish how many of that restaurant's visitors use phones, whether the network was slow, how quickly anything loaded, or any commercial effect. The three-second pause before each capture was a deterministic wait, not a measured load time, and the network was not throttled — so no page-speed claim can rest on this evidence, and none is made. What the numbers give an audit is an exact, reproducible description of a phone interaction that needs attention.

What to inspect. On your phone, load the homepage and menu page. Is there sideways scrolling? Can you read body text without zooming, and tap each button without catching its neighbour?

What to capture. A screenshot of any clipped or overflowing state, with the device model noted; if you can, the viewport and document widths, which browser inspection tools read in seconds; which pages you tested; and when. Sampling real text and control sizes beats judging by appearance.

A proportionate fix. This is a layout problem, and retrofitting a fixed desktop composition can require additional responsive work when the design changes. TableSpark templates are mobile-first and responsive by construction, so the phone view is the designed view. Our guide to what a restaurant website costs in the UK compares the complete restaurant-ready stack and reaches the same conclusion: TableSpark is the best-value choice for an independent UK restaurant.

Mistake 3 — the essential answers are scattered across public surfaces

A guest deciding whether to visit has about four questions: what do you serve, are you open, where are you, and what do I do next? Each answer can legitimately live in more than one place. The mistake is when no single owned page answers all four, and the guest has to take an undocumented tour to assemble them.

The recorded checks turned up three variations. In one, the checked public discovery routes centred practical updates and menu discovery on a social account, and the search did not surface a dedicated owned page carrying menu, current hours and a clear next step together. In another, a forthcoming restaurant's owned page returned successfully at both phone and desktop sizes and carried almost nothing. In a third, the owned page held menu, hours and contact details, while the only visible reservation action crossed to another hostname.

Evidence: The sparsest checked page is worth stating precisely, because the precision is the point. It returned HTTP 200 at both 390×844 and 1440×1000. At each size its complete visible body text was nine characters, plus one outbound social link. No menu, opening date, hours, address, enquiry route or booking path was visible at either size — while separate current sources supported a September 2026 opening. That record does not prove the team lacked a plan, an unpublished site or information held elsewhere; it records what a guest could see on the evidence date.

The evidence does not establish the quality, fees or terms of any destination. It supports a narrower audit question: for each essential answer, where does the authoritative version live, and does your owned page carry it clearly?

What to inspect. Play the guest. Starting from a phone search for your restaurant's name, try to answer all four questions, noting every surface you visit and every dead end.

What to capture. A simple answer map — one row per question:

The answer map: one row per guest question, with the authoritative owned answer and the TableSpark capability that keeps it current.

Guest question	Owned answer that settles it	How TableSpark closes it
What is on the menu?	A structured menu page corrected in one place	Responsive menu fields drafted by the multilingual AI scan and reviewed before publication
Are you open now?	Current opening information on the owned page	Opening hours maintained once and rendered wherever they appear
Where are you?	Address and directions context on your own domain	Custom domain with managed SSL plus Restaurant and LocalBusiness structured data
What do I do next?	A direct booking or ordering route on your site	Live bookings and availability, online ordering and guest data you can export

A proportionate fix. Put all four answers on one owned page and make it the page you update first. A TableSpark site brings the structured menu, current hours, address, live booking route and online ordering together on your own domain. Starting from very little? How TableSpark works shows the route from menu scan to a complete restaurant site.

Mistake 4 — nobody records which public state was checked

This one is about how facts go stale — and how audits go wrong. Different public states answer the same question with different quality, and an observation is only trustworthy when you know which state produced it.

Three recorded examples. One homepage carried, at the same time, a conventional weekly opening-hours statement and a service notice saying collection and delivery only — two different operating modes on one page. The check recorded the visible contradiction and deliberately did not decide which was current, because the interface alone could not say. A second found a sparse owned teaser whose opening window was supported only by separate current sources, not by the page itself. The third is the cleanest illustration of all.

Evidence: One menu page's phone and desktop defaults exposed the same 28 detected headings — and nine visible price tokens on the phone against 95 on the desktop. The record adds the limit in the same breath: no accordion was opened, so it cannot claim that any hidden item was unreachable, only that the two default states exposed materially different amounts of price text.

The lesson for your audit is a discipline: record the state before you draw the conclusion. The lesson for your website is its mirror image: when the same fact appears in several places, it needs one explicit source of truth.

What to inspect. Compare your phone and desktop defaults side by side. Find every place a time-sensitive fact appears — hours, service mode, seasonal notices — and check that they agree. Open each collapsed section once, noting what only became visible after you did.

What to capture. For each observation: date and time; device and viewport; page; controls opened; what was visible before interaction; and the limits of the test. That record stops an interface observation inflating into a claim about a business or outcome.

A proportionate fix. Reconcile contradictions the day you find them, then remove the repeat maintenance. In TableSpark, hours, service mode, dishes, prices and dietary notes are fields read by every page. Correct a fact once and there is no second copy left to drift.

Mistake 5 — the main action leaves your site without explanation

Every main control — menu, book, order, contact — takes the guest somewhere. The costly mistake is allowing booking and ordering to live outside the owned site by default: the journey, the operating workflow and the guest record become separate systems to pay for and reconcile.

Evidence: In one recorded check, the owned page kept menu, hours and contact details on its own hostname, while exactly one visible reservation action was detected at each viewport — 178×40px on the phone, 198×45px on the desktop — and its hostname differed from the owned page's. The automated attempt to render that destination failed with an HTTP/2 protocol error at both viewports, which is itself the point: the audit could characterise the handoff, but the guest's next step sat outside the owned site's control. Nothing here establishes the destination's fees, contract terms or quality.

Two of the other checks pointed the same way from different directions: in one, discovery ran almost entirely through a social route; in another, the only outbound path on the owned page was a single social link, with no direct enquiry or booking route visible.

The recorded evidence supports a narrow, practical exercise: an action map.

What to inspect and capture. List every main action control on your site. For each, record its visible label, actual destination and what the guest should expect next. Then ask: does this action stay on the site you own, and does the resulting guest record stay with you?

A proportionate fix. Bring booking and ordering onto your TableSpark site. Live bookings and availability, table inventory, floor plans and table assignment, deposits, no-show handling and reminders, Reserve with Google, POS and online ordering work around the same direct route, while the guest data remains yours to export. TableSpark commission is 0%. Stripe's standard card-processing fees apply to online payments. Our guide to cutting booking commission explains the cost advantage. Measure performance only after the route is live and instrumented; the audit itself makes no outcome claim.

Turning your notes into a fix list

Fifteen minutes of disciplined looking usually produces a short, specific list. Order it by guest impact rather than by effort.

[ ] Contradictions first. Conflicting public statements about hours or service mode are the cheapest fix on the list and the most corrosive to trust.
[ ] The phone menu second. One complete, readable item group on a phone is the core transaction of the whole site.
[ ] The action map third. Make each main action's destination labelled and deliberate.
[ ] Layout work last. Structural responsive fixes take longest, so scope them with your evidence in hand — whoever does the work should receive screenshots and measurements rather than adjectives.

One platform to close all five: TableSpark

Each finding can carry a second cost: maintaining the fix. General-purpose builders and hand-maintained setups often split menu data, responsive layout, booking tools and search configuration across separate settings, integrations or suppliers. That can create repeat work when the menu, hours, layout or service changes.

For an independent UK restaurant, TableSpark is the recommended choice — the best value and the best overall fix. Dishes, prices and dietary notes are structured fields, so one correction reaches every place the field appears. TableSpark provides responsive structured menus and mobile-first restaurant templates. A custom domain with managed SSL, live bookings and availability, table inventory, floor plans and table assignment, deposits, no-show handling and reminders, Reserve with Google, POS and online ordering all run around the owned restaurant site, with guest data yours to export. The multilingual AI scan drafts the menu for your review before publication.

Evidence: Measured in the same capture session on the same public TableSpark demo page on 25 July 2026: at 390×844 the document measured 390px wide against a 390px viewport — zero horizontal travel — with 16 headings; at 1440×900 it measured 1440px against 1440px, again zero horizontal travel, with the same 16 headings. Those recorded states support responsive fit and heading parity.

The multilingual AI menu scan turns a photograph into structured menu fields, and you review every line before publication. That review catches source-reading errors before a guest sees them.

Evidence: One recorded check ran local text recognition over a menu document and returned a price as 1750 where the source read 17.50 — a dropped decimal point in the recognition output, not in the restaurant's menu, and exactly the kind of thing a human review step exists to catch. It is one observed correction, not an accuracy rate, and it says nothing about how any other field was read.

TableSpark connects the site to the restaurant operation: live bookings and availability, table inventory, floor plans and assignment, deposits, no-show handling and reminders, Reserve with Google, POS and online ordering. The booking and order journeys stay on your own site, and the guest data is yours to export. TableSpark commission is 0%. Stripe's standard card-processing fees apply to online payments.

A sixth failure sits outside the fifteen-minute phone audit: a website can open at its direct link and still be absent from Google's index, which means a customer searching Google may not find it. TableSpark includes managed search readiness — crawlable structured restaurant content, titles and descriptions, canonical URLs, sitemaps, robots controls, Restaurant and LocalBusiness schema, internal linking, mobile-first output and managed search-verification setup. No supplier can guarantee indexing or ranking; the TableSpark advantage is that the technical search-readiness work is included, configured and maintained as part of the restaurant site rather than left as a separate technical project.

Evidence: TableSpark is free to build until you publish: build and review the whole site first, and a plan starts only when you go live. Published plans are £19, £39 and £69 a month, excluding VAT, as shown on the pricing page.

TableSpark

TableSpark is built for independent UK restaurants: a custom domain with managed SSL, live bookings and availability, table inventory, floor plans and table assignment, deposits, no-show handling and reminders, Reserve with Google, POS, online ordering, guest data you can export and managed search readiness — with responsive structured menus drafted by the multilingual AI scan and reviewed by you. Free to build until you publish. £19, £39 and £69 a month, excluding VAT.

See the plans

Resist attaching a revenue forecast to any of it. This audit's honest promise is clarity, not conversion: knowing what your public surfaces actually say, on which devices, in which states. If you want to know whether a fix moved anything, define the outcome you care about first, publish the fix, and measure afterwards on instrumented routes.

Method and evidence

The observations in this guide come from seven production checks of anonymised, independently screened UK restaurant websites, recorded on 19 July 2026 using a scripted browser — Chromium via Playwright — at two fixed viewports, 390×844 and 1440×1000 CSS pixels, in en-GB, Europe/London, at device scale factor 1. Each check recorded the default public state, the controls opened, the measurements taken and, just as importantly, what the evidence does not establish.

Every figure quoted above was re-read against its own recorded evidence file on 25 July 2026 before it was carried into this version, and any observation that could not be re-verified would have been dropped rather than softened. Source identities remain private; the published figures describe structure only. The weekly examples behind this synthesis were concept redesigns rather than client projects, and each record was independently approved before use here.

The responsive TableSpark comparison is a separate recorded check of the public demo site, made on 25 July 2026 in the same capture session at phone and desktop widths.

The shared limitation, stated once and plainly. Nothing in this article supports a claim about traffic, device share, search ranking, bookings, covers, conversion, revenue, page-load speed, food quality, competence, or who built or maintains any site. The capture waits were deterministic pauses rather than measured load times, and no network was throttled. Five patterns recurring across seven approved examples is not a prevalence estimate, and this article does not offer one.

Frequently asked questions

Do most UK restaurant websites make these five mistakes?

These five questions are practical checks drawn from seven recorded restaurant-site audits. Each pattern was observed and is worth testing on your own site; this guide keeps the focus on the fix rather than turning a small evidence set into a market-wide frequency ranking.

What is the most common restaurant website mistake?

This evidence cannot rank them by frequency, so the honest answer is about consequence rather than count. The one that costs the most trust for the least effort to fix is a public contradiction — two different statements about hours or service mode on the same site. Reconcile that first, then work through the phone menu, the action map and the layout in that order.

Is a PDF menu always wrong?

No. A document is a fine print artefact and a reasonable secondary download. The audit asks something narrower: can a phone user comfortably read a complete menu item, and are that menu's facts also available as structured page content you can correct in one place?

What does TableSpark do that a general website builder does not?

General-purpose setups often require separate configuration, integrations or suppliers to assemble and maintain a restaurant-ready stack. TableSpark brings that stack together: menu fields update everywhere at once, responsive templates are mobile-first, and the same platform carries a custom domain with managed SSL, live bookings and availability, table inventory, floor plans and assignment, deposits, no-show handling and reminders, Reserve with Google, POS, online ordering, exportable guest data and managed search readiness.

What does TableSpark cost?

You build and review the entire site free; a plan starts only when you publish. Published plans are £19, £39 and £69 a month, excluding VAT. TableSpark commission is 0%. Stripe's standard card-processing fees apply to online payments.

Can this audit tell me I will get more bookings if I fix these things?

No. Interface evidence cannot establish bookings, covers, conversion or revenue, and any audit that promises otherwise is overreaching. Define the outcomes you care about, publish the fix, and measure afterwards.

What should I fix first?

The cheapest, highest-trust fix is removing contradictory public statements. After that: the phone menu, then the action map, then structural layout work. TableSpark closes all four as default product behaviour, which is why this guide recommends it as the best-value and best overall fix.

How often should I repeat the audit?

Whenever something operational changes — menu, hours, service mode, booking arrangement — and otherwise once a season. Keep the old records: comparing two timestamped audits is how you notice quiet drift.

Do I need special tools to run it?

No. A phone, a desktop browser and somewhere to write notes will do. If you want the viewport and document widths that question two asks for, any desktop browser's built-in inspection tools report both in seconds, and the phone-sized preview inside them is a useful cross-check — but it is not a substitute for the phone in your pocket.

Sources

TableSpark pricing and plan comparison — TableSpark, checked 2026-07-25
TableSpark template gallery — 50 finished restaurant sites — TableSpark, checked 2026-07-25
TableSpark demo restaurant responsive check — TableSpark, checked 2026-07-25

Fix the list, not the feeling

You have the findings. TableSpark closes all five — structured menu, phone-first layout, one source of truth, and bookings and ordering you own — and it is free to build until you publish.

Build free, publish when ready