You have probably seen the gap it closes. An order gets written on a pad at the table, keyed in again at the POS, and somewhere in between a modifier changes or a table waits for a server who is queueing behind two others. Tableside ordering closes that gap by putting the order into the system where the guest is sitting. Your server can enter it on a handheld device, or the guest can enter it themselves from a QR code on the table, a tablet, or a kiosk by the counter. Picking the device is the quick part of that decision. What comes with it is table numbering, payment, tips, and a menu that has to answer questions with nobody standing there to answer them.
Who Holds the Device
A server with a handheld tablet is doing the job they always did. The difference is that the order reaches the kitchen while they are still at the table, and nobody re-keys it later. Specials, the second glass, the timing of when an order goes in: all of that stays with your team.
Hand the device to the guest and the work splits. The guest reads, decides and sends; your team carries, checks in and handles everything a screen cannot. Plenty of venues run both at once, a code on the terrace and servers with tablets inside, and nothing in the setup stops you.
The tablet that stays on the table is the one with daily upkeep attached: charging, a wipe between covers, and a layout that has to be readable at arm's length across a table. That is why tablet menu layout matters more here than on a phone the guest is already holding.
What the Menu Has to Say on Its Own
When the guest orders from a screen, the menu answers the questions your server used to answer. Anything it leaves out comes back as a raised hand, or as a dish nobody orders.
So the item record carries more than a name and a price:
- A photo of the dish as you actually plate it.
- A description that names what is in it, since nobody is standing there to say.
- Price options for the sizes and portions you sell.
- Modifiers for the extras people always ask for: no onions, oat milk, extra shot.
- Allergen and diet labels.
- Availability windows, so the lunch plate stops appearing at 9 pm.
On the guest's side that becomes the item page they tap into: the variants they choose from, the allergen icons, a calorie badge, and the ratings other guests left on that dish. Coffee bars get a field most menus never have, caffeine in milligrams per variant, which is the sort of thing guests ask a barista and never expect a menu to answer.
Photos are where this gets expensive. Enhancing or generating them with AI runs on credits rather than being unlimited, so a hundred-item menu is a budget question. Do the ten dishes that carry your margin first and let the rest wait.
Language matters more here than on a printed menu, because there is no server to bridge it. The guest picks a language on the welcome screen before the menu loads, and how many you can publish depends on your plan. Check yours before you promise a tourist menu in four languages.
Attaching the Order to the Right Table
A QR code can carry the table with it. Print one per table and the order arrives already attached to table 12. Use a single code for the whole venue and that information has to be collected another way, either from the guest on screen or by your team at the pass.
Tables are grouped into areas, so the terrace, the mezzanine and the garden can be numbered separately and laid out on a floor plan. The per-table codes are generated from the same screen where you build those tables, which is worth knowing before you send a section to the printer twice.
Paying Without Leaving the Table
Ordering at the table and then queueing for the check leaves half the wait in place. Card and cash still run through the POS. Online payment covers Apple Pay, Google Pay and cards, and Fast Checkout adds splitting the bill, at the moment through Stripe and Myfatoorah.
Tips, a minimum order value and age verification for alcohol sit with the ordering settings. A cover or service charge is set up with your tables instead, under Operations, next to staff and the service requests guests can send.
Which payment provider you can actually use depends on where you operate. Iyzipay and MOKA come up for venues in Turkey, Myfatoorah and STC Pay across the Gulf, Stripe and Square in most markets. If that side is not settled yet, what QR payment changes at the table goes through it in more detail.
Where the Waiting Moves
Sending orders faster does not make the kitchen faster. If your pass is already at its limit at 8 pm on a Saturday, self-ordering moves the wait: the table stops waiting for a server and starts waiting for the kitchen. Worth doing in most rooms, and worth knowing before you read the first week as a failure.
Decide who paces the courses. When a guest sends starters and mains in one submission, the kitchen sees them on a single ticket, and the pacing your servers used to do by holding an order back becomes a kitchen call.
Not every table wants this. A code on a dim table is harder to scan than the same code in daylight, and a table of eight usually ends up with one person ordering for everyone. Keep a way to call a server open, which is what the service requests a guest can send from the menu are for. The guests who would rather not use the code will use it, and so will everyone who wants more water.
How Do You Know It Paid Off?
Pick a stretch long enough to include ordinary weekdays and a full weekend, then compare one part of the room to itself. A terrace that got codes in June, held against a dining room that did not, tells you more than this month against last month.
Orders and average ticket say whether the room is turning and spending. Item views set next to orders say something else: which dishes get opened and then skipped. That is usually a photo or a description problem. Reports compare one date range against another, though how much history you can hold it against depends on your plan, so check that before you plan a year-on-year read.
Your own uplift is not a number we can quote you, and neither can a case study from someone else's dining room.
Menu First, Then Tables, Then Codes
The order you work in decides how much of this you do twice. Codes printed for a menu that still has three items without photos get scanned anyway.
1. Finish the menu data. Photos, descriptions, price options, modifiers, allergen labels and availability windows. Everything the guest cannot ask about has to be on the item.
2. Build your tables and areas. Terrace, mezzanine and garden are separate areas under Settings > Operations, laid out on a floor plan, and the per-table codes come out of that same screen.
3. Decide what the code does. Under Settings > QR Codes, Display mode shows the menu and takes no orders, Ordering mode takes them, and dine-in codes are generated either one per table or as a single code for the venue.
4. Turn on the channel and its rules. Dine-In QR, Tablet, and Delivery & Pick-Up are switched on separately in Orders > Ordering Settings, along with payment methods, tips, minimum order value, age verification and cancellation rules.
5. Set the mode, if you run tablets. Full Service for a server carrying the device, Table Top for one that stays on the table, Kiosk for guests ordering on their feet. The same screen decides whether an order is submitted as the guest or as the waiter, which matters when both happen at the same table.
6. Check the Marketplace against the till you already run. It lists POS integrations, Foodics, Simpra, Clover and Revel among them, and the payment providers above. The list changes, so look at yours rather than at a number in an article, and if your POS is not there, decide early how orders will reach it.
If you also sell off-premise, delivery and pickup are configured from the same ordering settings, and our guide to running online ordering through your own channel covers what changes once the guest is not in the room.
To see this against your own floor plan, table numbering and payment setup, request a FineDine demo and walk through your busiest service on it.
| Setup | Who enters the order | What the guest needs | What you set up first |
|---|---|---|---|
| Waiter with a handheld device | Your server, at the table | Nothing | Staff accounts and a device per section |
| Tablet that stays on the table | The guest, on your device | Nothing | Charging, cleaning between covers, a readable layout |
| QR code at the table | The guest, on their own phone | A phone and a connection | One code per table, or one for the venue |
| Kiosk near the counter | The guest, standing at the screen | Nothing | Floor space and a payment method on the device |
Frequently Asked Questions
- Is tableside ordering the same thing as a mobile POS?
- A mobile POS is the staff-side half of it: your server keys the order into a handheld device at the table. Tableside ordering also covers the setups where the guest enters the order themselves, so a mobile POS is one way of doing it rather than the whole category.
- Do guests have to download an app to order?
- No. The code opens the menu in the phone's browser, and a tablet or kiosk is your device with the menu already on it. A guest can create an account to keep favorites or leave a rating, but ordering does not require one.
- What happens if the connection at the table is weak?
- Guest-entered ordering needs a working connection on the guest's phone, so basements, thick-walled dining rooms and terraces at the edge of coverage are where it fails first. Guest wifi solves most of it. Where it cannot be solved, put a staff device on that section instead.
- Does the kitchen see the order directly?
- Orders land on the Orders screen, which most venues keep open on a tablet at the pass. If your kitchen works from printed tickets, a receipt printer integration is listed in the Marketplace as a paid add-on.
- How do tips work when the guest pays from their own phone?
- Tip collection is part of the ordering settings rather than a separate product, so it applies to the payment the guest makes at the table. Cash tips carry on as before, and how your team wants the two split is worth settling before you switch it on.
