Scan to order: the flow that actually works

Scan to order sounds simple: the guest scans a code at the table, picks their food and drinks on their phone, and the order goes straight to the kitchen. When it works, guests order when they are ready, servers spend less time taking orders and more time looking after tables, and the kitchen receives orders exactly as the guest chose them.

When it does not work, guests get stuck. They are asked to create an account before they can see the menu. They cannot find the drinks. They add a dish, cannot tell whether it has been ordered and order it again. They wave for a server anyway. Most of these problems come from the same cause: the steps of the flow are in an order that suits the system rather than the guest.

This guide sets out the scan to order flow guests expect, step by step, the one step most setups put in the wrong place, and how to keep orders accurate from the phone to the plate. Every figure in it is an example.

Guests bring an expectation to scan to order, shaped by every app and website they use. They expect to see what is on offer first, choose what they want, review it and then confirm. Asking them to do something before they have seen anything, or to commit before they have reviewed their order, feels wrong.

In a restaurant, that expectation becomes a simple sequence:

Each step should take the guest closer to food, never further from it.

The first step is the scan itself, and it has two jobs: open the menu quickly, and know which table the guest is at. A QR code is only a link a phone camera can read, so everything depends on where that link leads. A code that opens the venue's home page, a list of venues or a page asking the guest to pick their table adds a step before anything useful happens.

Use a code for each table, linked to that table, so the menu opens already knowing where the guest is sitting. Show the table's name or number at the top, so the guest knows the order will reach them, and, if the venue likes, the name of the server looking after the table.

Make the menu fast. Our guide to a digital menu that loads before the drinks do covers speed, and our guide to the table QR code: sticker, stand or menu card covers placing the code so guests find it.

The second step is browsing, and it is where many setups go wrong first. Guests should be able to look at the whole menu, every section and every dish, without signing in, creating an account or giving any details. Browsing is how guests decide whether and what to order; putting a barrier in front of it loses guests before they have chosen anything.

Help them find things. Section tabs at the top, a search box and filters for dietary needs let guests move around quickly. Photographs, short descriptions and clear prices help them decide.

Let guests browse at their own pace. Some will look for a minute and order at once; others will look, chat, look again and order ten minutes later. A menu that times out, resets or loses their place frustrates both.

The third step is choosing dishes. When a guest opens a dish, they should see everything they need to decide: the description, the price, the photograph, and any options, such as sizes, extras or required choices.

Options are where order accuracy is won or lost. A required choice, such as a steak's cooking point, should be impossible to skip, so the kitchen never receives an incomplete order. Optional extras should be clearly optional, with their prices shown as they are chosen. A notes field lets guests mention anything the options do not cover.

Keep the options to what the kitchen can deliver. Our guide to modifiers: letting guests change a dish, safely covers which changes to allow and how to set them up so they reach the kitchen clearly.

The fourth step is reviewing the order and sending it. Before anything goes to the kitchen, the guest should see the whole order in one place: every dish, its options and notes, the quantities and the total, with an easy way to change or remove anything.

This is the moment for anything that must be confirmed. If guests have allergies, the flow should ask them to confirm they have checked the allergen information, and give them a way to tell the kitchen. If the venue needs a name or contact details to deliver the order to the right guest, this is the place to ask, after the guest has chosen, not before.

Make the send button unmistakable, and make it clear what happens when it is pressed. "Send to the kitchen" says exactly what the guest is doing.

The step most scan to order setups put in the wrong place is asking for the guest's details. Many ask for a name, a phone number or an account before the guest can see the menu, or before they can add a single dish. Guests who only wanted to look, or who are not yet sure what they want, leave at that point, and many never come back to it.

Move it to the end. Let guests browse and choose freely, and ask for what the order needs only when they are ready to send it, once they have already decided to order. At that point, giving a name and a phone number feels like a reasonable part of ordering, not a toll at the door.

The same principle applies to payment in table service. Asking guests to pay before they can order a first round, in a restaurant where they will order several times, turns a relaxed meal into a series of transactions.

Once the order is sent, guests want to know it has arrived. A clear confirmation, "Your order has been sent to the kitchen", and a simple status, such as "in preparation", reassure them. Without it, guests wonder whether the order went through, ask a server or order again.

Show the guest what they have ordered so far, especially when they order in rounds. A guest adding a second round of drinks should be able to see the first round, so they do not order something twice by mistake.

If the kitchen cannot make something, say so quickly and clearly. An order that is declined, with a reason and the dishes returned to the guest's basket, is far better than a dish that silently never arrives.

In a sit-down meal, guests rarely order everything at once. They order drinks, then starters and mains, then perhaps more drinks, then dessert. Scan to order should support that naturally: each round sent when the guest is ready, all of them joining the same table's bill.

Make reordering easy. A guest who wants another of the same drink should find it quickly, ideally from what they have already ordered. Keep the basket separate from what has been sent, so guests always know which items are on their way and which are still waiting for them to press send.

Coursing matters too. If guests order starters and mains together, the kitchen needs to know whether to send the mains with the starters or hold them. Servers can still manage the pace of the meal, holding mains until the table is ready, even when guests placed the order themselves.

Scan to order changes the server's role, but it does not remove it. Servers still greet the table, explain how ordering works, recommend dishes, check that orders are right, bring food, manage the pace of the meal and look after guests who prefer to order in person.

The best setups make servers more effective, not invisible. A server who sees that a table has ordered by phone can bring the drinks, check the order and offer anything the guests may have missed. A server who sees that a table has not ordered after ten minutes can go and help.

Never force guests to order by phone. Some guests prefer to talk to someone, some do not want to use their phone, and some simply want advice. Scan to order should always be an option alongside a server, not a replacement for one.

One of the main benefits of scan to order is order accuracy. The guest chooses every dish and option themselves, so there is no mishearing, no misreading of a server's shorthand and no forgotten request. The kitchen receives exactly what the guest chose.

That benefit holds only if the order reaches the kitchen in the right form. Every option and note must appear on the kitchen ticket, under the dish it belongs to, with removals and allergy information easy to spot. Guest orders and server orders should look the same at the station, so cooks read one system.

Check the order at the pass as usual. A guest-placed order is not immune to mistakes in the kitchen, and the pass check catches them before they reach the table.

When guests order from their phones, there is no server at the moment of ordering to ask about allergies. The flow has to do that job, and it has to do it reliably.

Show each dish's allergen information clearly, with filters that let guests hide dishes containing allergens they avoid. Before the order is sent, ask guests to confirm they have checked the allergen information, and give them a way to tell the kitchen about an allergy, such as a note on the dish or the order.

Make sure allergy information reaches the kitchen prominently. Where the guest is known to the venue, their recorded allergies should appear at the top of the ticket. And train servers to ask about allergies when they visit the table, as a second check, especially for guests ordering for others.

In table service, payment usually belongs at the end of the meal, as it always has. Guests order in rounds, then pay once, by whatever method the venue offers: a card machine at the table, paying by QR code from their phone, or at the counter.

Where paying by QR code is offered, it should be the final step of the same flow: the guest opens the same menu, sees the bill and pays. Our guide to paying by QR code at the end of the meal covers what has to be true for that to work first time.

In counter-service venues, where guests order and pay before they sit, payment at the point of ordering makes sense. The principle is the same in both: payment belongs where guests expect it, not where it is most convenient for the system.

Scan to order needs the table to be ready for orders. A guest who scans at a table that has not been opened, or who sits at a table reserved for someone else, should not be able to send an order the kitchen will cook for the wrong party.

Most systems handle this by requiring the table to be seated first: the host or server seats the party, and the table becomes open for orders. If a guest tries to order before that, a clear message, such as asking them to wait for a member of the team, avoids confusion.

This is another reason servers remain essential. Greeting the table, seating it properly and explaining how ordering works is what makes the flow start smoothly.

Test the whole flow yourself, as a guest, at a real table during a real service. Scan the code, browse, choose a dish with options, add a note, send the order, watch it reach the kitchen, order a second round and ask for the bill. Note every moment of confusion.

Then watch real guests use it, without helping them. Where do they hesitate? What do they ask the server? Do they find the drinks? Do they know their order has been sent? Ask a few guests directly what they found easy and what they found confusing.

Look at the numbers too. How many guests open the menu, how many add dishes, how many send an order? A large fall at one step shows where the flow is losing guests.

Once scan to order is running, measure it regularly. The share of tables that order by phone, the time from seating to first order, the number of orders declined or corrected, and the questions servers are asked all show how well the flow works.

Compare orders placed by phone with orders placed by servers on accuracy: how often each leads to a remake or a correction. Scan to order should be at least as accurate, and usually more so; if it is not, look at how options and notes reach the kitchen.

Our guide to online ordering conversion: fixing the checkout covers the step-by-step measurement in more detail, and our guide to QR ordering, where the table orders and the kitchen cooks covers the kitchen side.

An invented brasserie launches scan to order with a flow that asks guests to enter their name, phone number and email before they can see the menu. Many guests scan, see the form and ask a server for a paper menu instead. Those who do order sometimes order drinks twice, because the screen does not show what has already been sent.

The brasserie changes the flow. Guests now browse freely and are asked for their details only when they send their first order. A clear confirmation shows that the order has reached the kitchen, and a list shows everything ordered so far. Required choices, such as cooking points, are enforced, and guests confirm they have checked allergens before sending.

Within a month, many more tables order by phone, duplicate orders almost disappear, and servers spend less time taking orders and more time recommending dishes and checking on tables.

In servearound, each table's code opens the menu for that table, showing its name and, if the venue chooses, the server looking after it. Guests browse freely, with category tabs, search and filters for dietary needs and allergens; dishes show their variants and add-ons, with required choices enforced, and a note for the kitchen. Before an order is sent, guests confirm they have reviewed the allergen and dietary information and give their name, phone and email, which attaches the order to their guest profile so the team can find them.

Orders can be sent only once the table is seated. They reach each station's board on the kitchen screen like any other, the guest sees that the order is in preparation, and declined orders come back to the guest's basket. Guests can call a server or request the bill from the same menu; paying from the phone is not available, because servearound does not process card payments yet. See the menus module and Order Fulfillment.

Guests scan a code at the table, browse the menu on their phone, choose dishes and options, and send the order straight to the kitchen.

Scan, browse, choose, review and send, follow the order, and pay at the end, so each step brings the guest closer to their food.

By asking for details or an account before guests can browse. Ask for what the order needs only when the guest is ready to send it.

Enforce required choices, show options and prices clearly, give a notes field, and make sure every option reaches the kitchen ticket under its dish.

Show allergens clearly, offer filters, ask guests to confirm before sending, give them a way to tell the kitchen, and have servers check at the table.

In table service, usually at the end, as before. In counter service, paying at the point of ordering makes sense.

Greet and seat the table, explain ordering, recommend, check orders, bring food, manage the pace and look after guests who prefer to order in person.

In rounds, each joining the same bill, with what has already been sent shown separately from what is waiting in the basket.

Test it yourself, watch guests use it, and measure how many open the menu, add dishes and send orders, and how accurate those orders are.

Scan to order works when its steps follow the order guests expect: scan a code that opens the table's own menu, browse with no barrier, choose dishes with clear options and required choices, review and send with allergens confirmed, see that the order has arrived, and pay at the end. The step most setups misplace is asking for details or an account before guests can see anything; move it to the moment of sending.

Keep order accuracy high by enforcing required choices and getting every option onto the kitchen ticket, support ordering in rounds, keep servers at the heart of the service, and never force guests to order by phone. Test the flow at a real table, watch guests use it and measure each step, so the flow keeps getting easier.