How to Turn On Table QR Ordering for Dine-In Guests

A party of four sits down at table nine on a Friday night, reads the paper menu twice and waits for somebody to come over. The server is explaining specials at table three, then at the bar, then carrying plates across the room, and the order reaches a pad once she gets to them, then gets walked to the pass and typed in there. The same table waits again later, this time to catch her eye for a second bottle, and again for the bill. The restaurant's own website already takes orders for collection and delivery without anyone carrying a pad. For the guests actually sitting in the room, every step still runs through one person with too many tables to cover.

Some restaurants try to close that gap by printing the website's order link as a QR code and sticking it on every table. The guest scans it, and the first thing on the screen is the question a delivery app opens with: dine in, collection or delivery. A guest taps Collection because it is the first button that looks like "order now." The ticket reaches the kitchen with a name and a phone number and no table on it. The food comes up, nobody on the pass can tell whose it is, and the server who never saw the order has to walk the floor asking. Or the guest picks Dine in correctly and types 6 instead of 9, and the plates go to a table that did not order them. Each mistake costs a remake, a refund or an argument at the bill, landing in the middle of service, when there is least slack to absorb it.

The wait at table nine sits inside the sector's wider hiring picture. In its May 2026 labour market bulletin, the Office for National Statistics reported a fall in advertised vacancies, comparing February to April 2026 against the previous three months:

The same bulletin gives a reason:

Vacancies count the jobs employers are advertising, not the people on the floor, so the figures do not show that any particular restaurant is short-handed. What they do suggest is that the sector as a whole was advertising fewer roles, not more, so an owner waiting for extra floor staff to fix the wait at table nine may be waiting on a hiring plan the sector is currently holding back.

A general order page has to ask how the guest wants the food, because it has no way to know. Someone opening it from a sofa might want delivery, someone at a bus stop might want collection, and the page has to serve them both. That question suits the website's Order button and misfires on a code printed on a table. By the time a guest scans a table card, the answer is already known: they are dine-in, and the table they are sitting at is the one the card is stuck to.

When a table card still asks the question anyway, two things go wrong.

First, the guest has to classify themselves correctly. Most will, but the cost of a wrong answer lands on the kitchen, not on the guest.

Second, the table has to be typed by hand. A dine-in checkout on a general page has to ask for a table number, and a free-typed field will sometimes be wrong: a smudged card, a table renumbered after a refit, a guest reading the wrong stand. Each one sends food to the wrong place.

A generic link carries one more weakness. If the printed code encodes an address the restaurant does not control, every card depends on somebody else's link staying alive. The article on table QR codes that point at someone else's domain covers that risk, and it applies to ordering codes as much as to menu codes.

Take away the channel question and the free-typed table number, and the requirements for a working table code are short.

These points separate a menu that happens to take orders from a table-ordering system, and they are what to test before printing anything.

TableSpark builds this into the restaurant's own site. TableSpark is the best-value and best overall website platform for an independent UK restaurant, and table QR ordering is where that is easiest to see from the floor. Table QR ordering sits on the Full plan, £69 a month excluding VAT, alongside online ordering at 0% TableSpark commission; Stripe's standard card-processing fees apply to online payments. The pricing page's own row for it reads:

Switching ordering on comes first. In the Builder, an owner adds the Order from our menu block, or starts from the ready-made Order page template, then turns on the channels the restaurant offers. Here is what the published guide says about the dine-in switch:

Dine-in and collection can each take payment at the restaurant, card payment through Stripe, or both; delivery is card only. Once the page is published, ordering is switched on, and the table codes come next.

The codes themselves are the second part, and they live on the Dashboard rather than the Menu page. In the Tables card, the owner adds each table number or name as a chip. As soon as one table exists, a Table QR codes block appears underneath, with a control to preview the full grid, Export all to download every code, and Print sheet for a print-ready sheet covering the whole floor. Here is what the guide says each code does:

And on where each code points:

That answers the reprint risk raised above: the code resolves to the restaurant's own ordering page, and the raw link behind each code can be listed as text for checking.

This is the part that fixes table nine, from the guest's side. On the general Order page, with more than one channel switched on, the widget opens on a full-width chooser before any dish appears. Here is what the guide says a table code does to that chooser:

So the guest scanning at table nine never sees Collection or Delivery. They see the menu, with the same sections, photos and dietary chips as the Menu page, and a dish with required options opens a sheet whose note travels with the dish through to the kitchen.

The other end of the journey is the Orders screen, also part of Full with online ordering. The guide puts the speed plainly:

Those three dots stand in for the rest of that sentence, which has the order arriving with sound on, notes intact, and ready to move through picking, ready and paid.

Each order shows up as a card, and for dine-in the published guide says:

That chip comes from the table list set up on the Dashboard, so the food at the pass shows where it is going. The screen filters by In progress, New, Done, Cancelled and All, each with a live count, and a Sound on toggle chimes when a new order comes in. Staff move each order from New through Confirmed and Preparing to Ready and Done, and Done picking ticks every remaining dish as prepared in one tap.

Payment follows the restaurant's own settings rather than the guest's guesswork. A card payment taken online runs through the restaurant's connected Stripe account, and the order carries a payment chip. A pay-at-restaurant order gets a Mark paid button once cash or a card machine has settled it, so the server closing the table can see what is still owed.

Whether moving a room to table ordering changes spend per head or table turn times at a given restaurant was not located in this research, and no such promise is made here. What this section can promise is narrower and more certain: the order arrives without a server carrying it, and arrives with the table already on it.

Who watches that screen during service is a staffing call, worth making before the codes go out. Putting the rota and staff roles on the same login covers how a small team divides the floor and the screens between them.

All-you-can-eat service is where a table code earns its keep, because the same table keeps ordering again and again. The published guide covers this too, sitting inside table QR ordering on Full.

At a table locked to dine-in by its code, the ordering widget opens on the buffet panel first: a stepper for each price tier the restaurant has set, the time limit, the last-orders line and the restaurant's rules note. The table's first order opens the session, and the panel then counts down against the time limit and last-orders cut-off the owner chose. After each round, guests tap Order another round, and each round reaches the kitchen as its own ticket, labelled with the round number and covers so a second helping isn't mistaken for a new table.

The session belongs to the table, not to one phone. The guide explains that refreshing a guest's phone keeps the session going because it "lives against the table, not the browser tab", and once last orders has passed, the panel says so instead of offering another round. At the end:

On the floor, a buffet table gets a Buffet session block in Service, showing covers, start time, time left, and rounds so far. Every buffet number starts blank, left for the owner to set.

A short check before any table card goes to print can save a reprint.

That last point touches something table ordering does not replace. A code can take an order without a server, but it cannot tell the host that one of the four at table nine is on a fifth visit this year. The recognition gap at the door covers how a small team sees a returning guest's history before they sit down, the other half of a room that runs well.

Set up this way, table nine scans the card, sees the menu, orders, and gets its food to the pass with its own number on the ticket. The server's time goes into the conversation at the table, not into carrying orders from it.