Skip to content

Solutions · Restaurants

Online ordering for restaurants serving dine-in, delivery and takeaway from one kitchen

  • One menu with lunch, dinner and weekend windows
  • Dine-in, delivery and takeaway in a single order list
  • Table QR ordering where it suits the room
  • No platform commission on orders from your site

Illustrative view.

A Saturday at 7.40pm

Three order types, one pass, twenty minutes

Table 9 scans the code on the table and sends in two starters, three mains and a bottle of water at 7.38. A delivery order for two biryanis and a raita arrives at 7.40 from a family that has eaten with you twice before. At 7.41 a regular rings to say he will collect a paneer tikka on his way home.

On the order screen these show up as what they are: a dine-in order with a table number, a delivery order with an address and a saved phone number, and a pickup. The kitchen accepts each with a realistic time. The delivery is told 40 minutes, the pickup 20, and table 9 gets fired in the normal course order. At 8.15 someone requests a rider for the biryanis, or hands them to your own driver, and marks the paneer tikka ready so the counter knows which bag is whose.

Nothing here is clever. The point is that the delivery order and the pickup came through a page you own, and the family's details are on your order, not on an app's.

Figures are illustrative and chosen to show the arithmetic, not to predict your results.

  • Menus that follow your service periods

  • Every order type in one list

  • Table codes where they make sense

  • Regulars who reorder in under a minute

Table QR for the rooms that want it, waiters for the rest

QR ordering is not a replacement for service. In a casual format, a courtyard, or a busy lunch room it saves a trip for every refill and lets a table of eight order at their own pace. In a dining room where guests expect a conversation about the wine, it can feel wrong.

Because codes are generated per table, you choose. Put them on the terrace tables and the bar counter, leave them off the chef's table. Orders from codes land on the same screen as everything else, tagged with the table number.

  • Codes per table, printed on cards or stickers you control
  • Guests order from the phone's browser, with nothing to install
  • Orders arrive with the table number on the ticket
  • Online payment through your gateway, so the table is settled when it leaves
How dine-in QR ordering works
Illustrative view.

Setting up a restaurant that does all three

  1. 1

    Build the menu by service period

    Create sections the way your kitchen thinks about them: starters, mains, breads, desserts, and a lunch set that only shows between 12 and 3. Add sizes and portions as variants (half or full, for two or for four) and extras as add-ons. The menu builder page goes through the details.

  2. 2

    Decide what you offer and where

    Switch on delivery, takeaway and dine-in as you need them. Draw your delivery area and set the charge, set a pickup lead time the kitchen can keep, and decide which tables get codes.

  3. 3

    Put the order screen where someone will see it

    A tablet at the pass or a screen at the host stand. New orders alert and wait for someone to accept them, so nothing is promised to a customer that the kitchen has not seen. The order management page explains statuses and timing.

  4. 4

    Set prep times you can actually hit

    A delivery told 30 minutes and delivered in 55 will not reorder. Start with longer times on busy nights and tighten them once you have a feel for how the screen runs alongside the floor.

  5. 5

    Point your regulars at the link

    Google Business Profile, Instagram, the WhatsApp reply you send when someone asks for the menu, and a line on the bill. This is the slow part, and the guide to repeat orders is honest about it.

How each order type reaches the kitchen

Order typeHow the customer ordersWhat the kitchen seesHandover
Dine-in via table code
Dine-in via waiter
Delivery
Takeaway

Running three channels from one kitchen without the pass falling apart

Most restaurants that add online ordering do not struggle with the software. They struggle with timing, because the kitchen was designed around tables and now has to promise times to people it cannot see. A few habits make the difference.

Give the online menu the same discipline as the printed one

The ordering page is a menu, and a menu that lists a dish the kitchen cannot make at 9pm is a complaint waiting to happen. Use availability windows for anything tied to a service period, and give whoever runs the pass the authority to mark an item sold out from a phone the moment the last portion goes. A sold-out dish is a small disappointment. A dish that is accepted and then cancelled is a lost customer.

Keep names consistent with the printed menu, too. If the card says “Dal Makhani” and the site says “Black Lentils (Dal Makhani)”, the person on the phone asking about their order and the person at the pass will be talking about different things.

Treat the prep time as a promise

When an order is accepted with a time, that time goes to the customer. On a quiet Tuesday, 25 minutes for delivery is reasonable. On Saturday, with a full room, it is not, and the system does not know that. Someone at the pass has to. The simplest rule is to add ten minutes to whatever feels right on busy nights for the first few weeks, then shorten it once the kitchen is used to seeing delivery tickets alongside table tickets.

Decide who watches the screen

The failure mode is not that orders are missed by the system; it is that the tablet is behind a stack of plates. Put it at eye level where the person expediting can see the alert. In smaller restaurants that person is the owner at the host stand. In larger kitchens it is the pass. Either works, as long as it is one named person per shift.

Use table codes with some judgement

A QR code on every table changes how the room feels. For a casual lunch format or a terrace, that change is welcome: a table of six can order a second round of drinks without flagging anyone down, and the kitchen gets the order written exactly as the guest typed it. For a room that sells itself on service, the codes can go on the bar and the outdoor tables only. The system does not mind either way.

Guests pay online when they order, so the table is settled before they leave. If your floor relies on adding a service charge at the end or splitting a bill four ways, note that those are not things the QR flow handles today, and plan around them.

Move regulars slowly and deliberately

The restaurant’s advantage over any marketplace is that people already know it. That advantage only counts if the link is where those people look: the Google listing, the Instagram bio, the WhatsApp reply when someone asks for the menu, and a line on the bill. The commission calculator is a useful way to work out what moving even a quarter of marketplace volume is worth before you decide how much effort to put in. For most full-service restaurants the answer is “more than the printed flyers cost”.

Keep marketplaces for what they are good at

Listing on a delivery app is a way to be found by people who would otherwise never see you. It is a poor way to serve the people who already come in every fortnight. Run both, be clear with yourself about which is which, and watch the order screen for the first repeat order that arrives through your own page. That is the moment the setup starts paying for itself.

Questions from restaurants running all three channels

Can the ordering page use the same menu as the dining room?

Yes, and most restaurants should. Keep one menu and use availability windows to hide what you do not want ordered online (the tasting menu, say). Prices online can match the room or differ; that is a business decision, not a system limit.

What happens to a delivery order when the kitchen is slammed?

Nothing is auto-accepted. The order waits on the screen until someone accepts it with a prep time. If you are 45 minutes out, say 45 minutes. Customers tolerate a long time far better than a wrong one.

Do dine-in QR orders replace my POS?

No. Table orders arrive on the Tuckly order screen and are keyed into your POS unless your POS is on the integrations list with order push supported. Treat the QR as a way for guests to order and pay, not as a new till.

We have two drivers. Do we also need Porter?

Not necessarily. Assign orders to your drivers through self-delivery and use Porter only when both are out and a far order comes in, where Porter operates. Fulfilment is chosen per order, so you can mix.

How is this different from listing on Swiggy, Zomato, Uber Eats or DoorDash?

Those bring people who have never heard of you and take a percentage of every order, including from the family that has eaten with you for years. Your own site charges no platform commission and keeps the customer's details with you. Most restaurants run both; the comparison page goes through the trade-offs.

One menu, three channels, your name on all of them

Set up the menu, decide where delivery goes and which tables get codes, and start sending regulars to a link you own.

Gateway fees, delivery and taxes are separate. Pricing

More business types

Last reviewed 29 October 2026.

Get started

Create your ordering website

Tell us about your restaurant. We set up your online ordering system and help with your menu and delivery rules. No commission on direct orders.

What do you want to offer?

We reply by email. No spam.