Ordering at the table from an app, step by step

Ordering at the table from an app takes six steps: the guest scans the code on the table, browses the menu, fills a cart, sends the order, the kitchen prepares it, and finally the guest pays. It sounds simple, but each step raises a question you need to answer before you draw the first screen. Here are the steps, with the questions we ask.

1. Getting in: the code on the table

The QR code on the table doesn't just lead to the menu. It leads to the menu for table 7. The table number lives in the link, so the guest never has to type it and the server knows where the order goes.

The first big decision: an app from the store, or a web app that opens straight in the browser. For a guest who's staying an hour, searching for and installing an app just to order a lemonade is a long detour. A web app starts from the camera, on the first scan. A store app makes sense if you have regulars and want accounts, loyalty points or notifications. We compared the two in our article on web apps versus store apps.

The second decision: what happens if someone photographs the code and orders from home. Usually it's enough to have a server confirm the first order from each table.

2. The menu

On a phone, people browse the menu with their thumb, so design it for the thumb:

• categories at the top that stay visible as you scroll;
• one good photo per dish, not ten;
• allergens and portion size next to each dish, so guests don't have to call the server over for every question;
• sold-out dishes show as unavailable instead of vanishing without explanation.

"Add to cart" buttons need to be easy to hit. The WCAG 2.1 accessibility standard recommends, at its strictest level, targets of at least 44 by 44 CSS pixels. That's a good rule for everyone, including people with perfect eyesight holding a phone in one hand and a glass in the other.

3. The cart and sending the order

The cart shows what was picked, how many, and a short notes field ("no onion," "sauce on the side"). The send button says exactly what it does: "Send order to the kitchen."

Don't ask for an account, and don't ask for data you don't need. For an order at the table you need the table and what was ordered. The GDPR requires personal data to be limited to what's necessary for the purpose you collect it for, and a sign-up form standing between a guest and their first beer is also a place where people give up.

4. Kitchen, bar and floor

The order gets split: drinks to the bar, food to the kitchen. Each station sees it on a screen or a ticket printer, with the table and the time.

This is where the app either helps the staff or gets in their way. Three statuses are enough: received, in progress, ready. The guest sees the same statuses on their phone and stops asking "is it coming?" The server sees what's ready to take out and to which table. When the kitchen marks a dish as sold out, it disappears from everyone's menu immediately.

5. Payment

Payment is where a bad flow hurts most: the guest wants to leave and has no patience left. You have two options, and you usually keep both:

• paying from the phone, by card or with the phone's digital wallet;
• paying the usual way, with the server, via a "Bring the check" button.

On the web, the browser's Payment Request API lets people pick a payment method they've already saved, without filling in a card form. It only works on secure (HTTPS) pages. In the European Union, electronic payments require strong customer authentication under the PSD2 directive: for example, a fingerprint or PIN plus the phone itself. Digital wallets keep that step short: a tap and a fingerprint.

Don't forget split checks. At a table of four friends, someone will ask whether each person can pay for what they ordered.

6. When something goes wrong

You see a good flow when there's a problem:

• weak signal inside the restaurant: the order isn't lost, it waits and goes out when the connection returns, and the guest can see that;
• a dish sells out in the meantime: the guest finds out before paying, not after;
• the order is wrong: the server can fix it from their own app without starting over.

What to prepare before the first screen

A spreadsheet with every dish, its price, allergens and portion size, the number of tables, who receives which orders, and how people pay in the restaurant today. With that in hand, the first prototype comes together quickly. If you want to start a table-ordering app or a digital menu, see what our app studio does and our digital menus.