Solutions · Restaurants
Online ordering for restaurants serving dine-in, delivery and takeaway from one kitchen
A restaurant on a Saturday night is three businesses sharing one pass. Tuckly puts the table orders, the delivery orders and the bags waiting at the counter on one screen, fed by one menu, in an online ordering system that carries your name rather than a marketplace's.
- 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
Orders · Today
Accepting ordersNew 2
Delivery
Rider to assign
$24
Pickup
Ready by 13:15
$8.50
Preparing 2
Dine-in · Table 6
Scanned QR 12:48
$33
Delivery
Own rider · Sam
$16
On the way 1
Delivery
Picked up 12:40
$41
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
Lunch thalis until 3, the full card from 7, the brunch section on weekends only. Set the windows once and the ordering page changes on its own.
-
Every order type in one list
Dine-in, delivery and takeaway orders arrive on the same screen with a status, a prep time and the customer's contact details, so the pass has one place to look.
-
Table codes where they make sense
QR ordering per table, so the terrace can order from a code while the private dining room keeps its waiter. See QR code ordering.
-
Regulars who reorder in under a minute
Saved address and phone number mean the family from table 9 can order the same thing on Tuesday without typing anything twice.
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
Scan to order
Menu, order and pay from your phone
Table 6
Opens the restaurant's own website. No app to install.
Setting up a restaurant that does all three
The order matters less than being honest about timings at step four. Everything else is an afternoon's work.
- 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
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
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
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
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
A plain account of what goes through Tuckly and what stays on your existing process.
| Order type | How the customer orders | What the kitchen sees | Handover |
|---|---|---|---|
| Dine-in via table code | Scans the QR, orders and pays on their phone | Order with table number on the screen | Served to the table as usual |
| Dine-in via waiter | Tells the server | Your POS, as today; this does not pass through Tuckly | Served to the table |
| Delivery | Orders on your site, enters address, pays online | Order with address, phone and notes; prep time set on accept | Porter rider where available, or your own driver |
| Takeaway | Orders on your site, picks a collection time, pays online | Order marked pickup with the ready time | Marked ready; customer collects at the counter |
Porter availability depends on the city. The delivery management page states which parts of the Porter workflow are live and which are still being validated.
The parts a full-service restaurant uses most
-
Menu builder
Service windows, variants, add-ons, photos and a sold-out switch from the pass.
-
Order management
One screen, every order type, with statuses the kitchen moves and contact details when you need them.
-
Delivery management
Porter where it operates, your own drivers, and pickup as a fallback when neither suits.
-
Takeaway and pickup
Collection orders with ready times, so the phone stops ringing during service.
-
Restaurant website builder
Your menu, hours, location and ordering on one site, or an ordering page linked from the site you have.
-
Pricing
No commission on direct orders. What you do pay, listed plainly.
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.