Restaurant Online Ordering: The Complete Guide

Ask a restaurant owner what their "online ordering system" is, and most point at the basket button — the moment a guest taps Order. That button is real, but it is one link in a longer chain: a guest finds the restaurant, sees a menu they can trust, adds something to a basket, pays, gets fed at the time they were promised, and — if the chain worked — comes back without being sold to again. Treating "online ordering" as the button and leaving everything before and after it to chance, or to whichever platform happens to hold the guest, is the single most common mistake this guide exists to correct.

At minimum, a working system needs a current digital menu, a checkout built for how people actually order (mostly on a phone, often in a hurry), a way to take payment, fulfilment logic for pickup, delivery or advance ordering, and some mechanism for winning a first-time guest back a second time. None of that requires exotic technology. What it requires is that every link in the chain agrees with every other link — the price on the menu is the price at checkout, the dish that's sold out disappears everywhere at once, and the delivery time promised at the top of the page is the one the kitchen and the driver are actually working to.

The decision that runs through the whole guide is ownership. A guest can order through a delivery marketplace, or through a channel the restaurant controls — its own website, its own app, a phone call, a countertop kiosk. Both routes can feed the same kitchen. What differs is who ends up owning the guest relationship, the order data, and the margin left over once the order is paid for.

Neither route is wrong on its own. A marketplace is a genuine, working channel for a guest who has never heard of the restaurant and is comparing five options on a map. The problem is not that marketplaces exist; it is restaurants that never build the other route, so every guest — including the one who has ordered ten times already — keeps paying the acquisition cost of a stranger.

This guide follows the chain in the order a restaurant actually experiences it. The next chapter looks at the channels a guest can order through and which guest job each one actually solves. After that comes checkout — the single highest-leverage part of the whole chain — followed by the operational discipline that keeps a delivery or pickup promise once it's made. Then the economics: what a marketplace order really costs once every line item is counted, and how restaurants recover margin without a price war. The guide closes with a practical answer to the question every owner eventually asks — what to build first, and what to leave alone.

"Should we be on the marketplace, or build our own app, or put in a kiosk?" is usually asked as if it had one right answer. It doesn't, because a website, a marketplace listing, an app, a kiosk and a phone line don't compete for the same guest moment — each solves a different job, and a restaurant's actual channel mix should follow the jobs its guests have, not a preference for one technology over another.

The web wins first discovery. A guest searching "best pizza near me" who wants to order in the next four minutes is not going to download an app first. A fast, well-kept website — found by search, shareable as a link, no install required — catches that guest at the exact moment they're deciding. This is also where a marketplace listing genuinely earns its keep: for a guest who has never heard of the restaurant, a marketplace's existing reach can put the restaurant in front of someone the website alone would never have reached. That's the honest case for marketplace presence — visibility for the unfamiliar, not the default checkout path for someone who already knows where they're eating.

A restaurant's own app wins habit. The trade guests make for a download is convenience later: a saved address, a stored payment method, a spot on the home screen, and — used carefully, without turning into noise — a direct notification channel that a website simply cannot offer. That trade only pays off for a guest who orders often enough to want the shortcut, which is exactly why an app is usually the second or third channel a restaurant builds, not the first.

Two more channels round out the set, and both work by capturing a moment that would otherwise be lost.

A self-order kiosk is not, on its economics, a large-chain toy. Two things change the moment a guest orders from a screen instead of a person at the till: the basket tends to grow, because a screen never forgets to offer a relevant add-on the way a rushed staff member might, and the queue tends to shrink, because several guests can order in parallel instead of one at a time. Orders also arrive at the kitchen exactly as entered — no mishearing across a busy counter — and paid on arrival, which means the ticket is ready to make the moment it prints. Whether a kiosk is worth it comes down to one question, not restaurant size: does the queue at your actual peak cost you orders? If guests are walking away rather than waiting, a single countertop kiosk on an independent's own brand — its own photos, its own colours, not a generic rented terminal — usually earns its place. If there's rarely a queue, it's not urgent.

A missed phone call is the quietest kind of lost order, because it tends to happen at exactly the hour a restaurant is busiest and least able to answer it. The phone remains, for many restaurants, the channel most reliably left to voicemail during the rush — and a caller who gets no answer usually doesn't leave a message; they call the next place, or open a marketplace app instead. Answering every call — whether by adding staff capacity at peak or by using a voice system that takes the order in the caller's own language, reads it back to confirm, and drops it into the same kitchen queue as everything else — turns a channel that quietly leaks orders into one that captures them. What matters more than the mechanism is the discipline behind it: a caller with an unusual request, a serious allergy question or a complaint needs to reach a person, not be trapped in a script. Menuella's kiosk and AI phone-ordering features are built around exactly that pattern — capture the standard order automatically, hand off anything that shouldn't be automated — but the underlying decision (is this moment being captured at all, right now?) is what actually matters, whatever tool answers it.

The trap that undoes every channel decision in this chapter is running two menu truths. If the website, the app, the kiosk and a marketplace listing each draw from a different source for price, availability and promotions, they will eventually disagree — a guest sees one price on the app and another on the website, or orders a dish on the kiosk that the website already marked sold out. That isn't a minor inconsistency; it's a guest catching the restaurant in what looks like a lie. One source of truth for menu, price and promotions, shared across however many surfaces a restaurant actually runs, is the quiet precondition behind everything else in this guide.

If a restaurant can improve exactly one part of its ordering chain, it should be checkout. It is the highest-value real estate in the whole system — the moment interest either becomes revenue or doesn't — and it fails in ways that are almost always fixable once they're visible.

Underneath the interface, four things have to stay in agreement. Order state means the basket keeps its prices, modifiers and fulfilment choices intact as a guest moves through the flow — switching from pickup to delivery shouldn't silently empty a basket or lose a chosen time slot. Operational validation means checkout uses the same rules the kitchen is actually working under: whether a dish is still available, whether a delivery address falls inside a working zone, whether the requested time slot still has capacity — checked before payment, not discovered after. Payment state means the system can always say, precisely, where an order stands: payment initiated, authorised, captured, order received, order accepted — so that a guest whose connection drops mid-payment gets told clearly what happened rather than being left to wonder whether they've been charged twice. Fulfilment handoff means a confirmed, paid order reaches the kitchen automatically and unambiguously, with a clear path back to the guest if something in the kitchen changes after the fact — a sold-out ingredient, a printer failure, a fully booked slot. A checkout that gets all four right rarely announces itself; a checkout that gets one wrong shows up immediately as an angry phone call or a cancelled order.

The interface decides whether guests actually reach that architecture. Most orders happen on a phone, frequently one-handed, often with a bag in the other hand and patchy reception. The practical design response is to keep the actions that matter — confirming a time, choosing a tip, placing the order — within easy thumb reach in the lower part of the screen, to ask for one thing at a time rather than a long form all at once, to validate a phone number or a delivery address immediately beside the field rather than only after submission, and to put Apple Pay and Google Pay ahead of manual card entry, since every keyboard a guest has to open is a small chance to lose them. A basket that survives the back button, a dropped connection, or a failed first payment attempt is worth more than almost any other single fix. And when something is processing, say so visibly — "processing payment…" beats a frozen button every time, because the alternative is a guest tapping twice out of uncertainty and creating exactly the duplicate-order risk the architecture above exists to prevent.

Speed, stability and honest availability are also, in a real if indirect way, a visibility signal. A checkout loaded with unnecessary scripts and pop-ups doesn't just feel slow to a guest — it produces the kind of abandoned session that search systems read as a low-quality experience over time. None of that substitutes for substance: an extremely fast checkout sitting on a thin, out-of-date menu page still loses to a competitor with a complete, accurate one. Speed is an amplifier for a page that already has something worth finding, not a replacement for it.

Upselling belongs in this chapter because it happens at checkout, and because the difference between a good add-on and an annoying one is almost entirely about restraint. The mental model worth keeping is a good waiter rather than a pushy salesperson: someone who reads the table, offers one thing that genuinely fits, and drops it the instant the answer is no. In practice that means four things working together. First, the ranking: the strongest single suggestion for a given basket is the one with the best combination of contribution margin and the real likelihood a guest accepts it — drawn from how guests have actually ordered before, not from whichever item is cheapest to push. Second, the guardrails, and these come before margin, not after it: an allergen or dietary filter that overrides every other calculation without exception, a sold-out dish that disappears from suggestions the moment it's marked unavailable rather than at checkout, and a kitchen-load check so a suggestion never lands on a station that's already underwater during the rush. A new dish with no order history yet still needs a sensible starting point — usually its own attributes, like cuisine style or heat level — rather than either random suggestion or no suggestion at all until enough data accumulates. Third, the timing: tightly linked items belong early, while a guest is still actively building the order; a drink or dessert can work after the main choice is made, provided it loads instantly; and the final step before payment — where the guest needs the total, the time and the fees, not a surprise — is rarely the right place to introduce anything new. Fourth, the manner: one suggestion, not a wall of them, dismissed in a single tap that stays dismissed, and never standing between the guest and the confirm button. Done this way, a suggestion reads as a courtesy — "this goes well with that" — rather than a tax on getting to checkout, and the basket grows without spending down the trust the rest of the guide is built on protecting.

Getting a guest to the "place order" button is one problem. Fulfilling what was promised — on time, at the quality the menu photo implied — is a separate one, and it's the one that actually determines whether that guest orders a second time.

Pre-orders move revenue from a guess to a plan. Instead of discovering Friday's demand as tickets arrive, a restaurant that takes planned pickup, office catering, or holiday packages in advance is fulfilling something already paid for. Payment taken at the time of booking reduces no-shows close to zero, and — because the pressure of an immediate decision is gone — a planned order tends to carry a higher basket value than a spontaneous one, as guests are more willing to add a side or a dessert when they're not choosing under time pressure. Three settings keep a pre-order from ambushing the kitchen later: how far ahead a guest may book, how much lead time the kitchen genuinely needs before a large order lands, and the exact cut-off after which no more orders are accepted for that window. The one operational rule that protects all of it: pre-orders have to draw from the same menu and availability as live orders, or a restaurant ends up selling, days in advance, a dish the kitchen can no longer make on the day.

Peak demand is a throughput problem, not a "say no to guests" problem. The instinct when a rush threatens to overwhelm a kitchen is to just take every order and hope — but a ticket printer that never stops isn't a sign of success, it's an early warning. Managing demand well means spreading it rather than refusing it: a cap on how many orders can be in progress at once, after which new guests are guided (not turned away) to the next realistic slot; a pause on new orders during genuine equipment trouble; and a promised pickup or delivery window that honestly lengthens once the kitchen is at capacity, rather than staying fixed and quietly becoming a lie. It also helps to measure actual effort, not order count — a family-sized order ties up a kitchen far longer than a single starter, so counting tickets alone understates real load. A clear lead time and cut-off for large orders, and a prep list built from planned pickup times rather than only from live tickets, is what makes a genuinely busy service feel, from inside the kitchen, closer to boring than chaotic.

Delivery zones should be drawn by drive time, not by a circle on a map. A guest three kilometres away in a straight line can easily be a fifteen-minute drive once a river, a rail crossing or a ring road gets involved — and a zone drawn by distance rather than realistic drive time is the single most common reason delivery food arrives cold at the edge of a service area. Fees are worth tiering by distance too, so a long trip doesn't quietly eat the margin a nearby regular's order should be carrying. A delivery radius isn't fixed forever: if a new bestseller pushes prep time up and strains the kitchen, temporarily shrinking the radius protects the promise for everyone still inside it, rather than letting the promise fail for everyone. And a cluster of "cold food" complaints from one particular neighbourhood, even when the map says the time should be fine, is usually pointing at a missing variable — difficult parking, a long walk-up, a gated entrance — worth a specific buffer rather than a shrug.

Running delivery in-house adds a genuine operational job: dispatch. A delivery time that's tied to real kitchen load, rather than a fixed number chosen to look good on the ordering page, is the difference between a promise that holds and a Friday night spent fielding "where is my food" calls. Assigning a run for the best chance of an on-time, hot delivery — not simply to whichever driver happens to be free — and setting a firm limit on how many orders get batched into one trip when the dishes are temperature-sensitive both protect the thing the guest actually notices, which is the food's condition at the door, not the routing logic behind it. What actually separates a delivery operation that scales from one that burns its own reviews is less the easy case and more the backup plan: a clear, fast route through a missing driver, a wrong address, or a dish that has to be remade, plus the ability for a manager to pause a zone or extend delivery times in real time when something is genuinely wrong — resolved in minutes rather than escalating into a pattern of one-star reviews.

The delivery time itself deserves particular care, because guests remember one number and whether it was true. A sound estimate combines two different kinds of uncertainty — kitchen load, which drives prep time, and road conditions, which drive the drive itself — and it should update automatically once the kitchen actually falls behind, rather than sitting on a number that quietly stops being true. Pickup and delivery should be calculated separately, since one depends almost entirely on the kitchen and the other adds the much larger variability of the road; forcing both through one calculation guarantees one of them is wrong. The instinct to advertise the shortest possible number is usually the wrong one: a small, honest buffer that's reliably kept beats a heroic number that fails under real load, and the number worth actually measuring is not the average delivery time but the promise-hit-rate — how often the food arrived at or before the time that was promised. When a delay is likely, a short, honest reason — high demand, a driver already assigned, a dish being remade — helps more than silence, provided the reason support gives on the phone matches what the order page says; guests notice the mismatch, not the delay itself. And because nobody is on time every single time, what happens when a delivery runs late matters more than never being late: a proactive update, a small credit, or another visible gesture of taking responsibility tends to build more loyalty than a smooth evening nobody notices — provided that whole conversation happens on the restaurant's own channel, so the trust it builds accrues to the restaurant rather than to whichever app happened to be carrying the message. Menuella's delivery tooling calculates a promise this way — combining prep and road conditions, still leaving a manager able to extend times by hand with a recorded reason — but the underlying discipline (a buffer, a hit-rate worth measuring, a channel a restaurant actually owns) is what makes any delivery promise trustworthy, independent of which system runs it.

The number printed on a marketplace's pricing page is the headline cost of an order, not the all-in cost — and restaurants that plan around the headline number are almost always leaving more margin on the table than they realise.

A marketplace contract usually contains several cost lines beyond the advertised commission. Base commission is the largest and most visible one, typically somewhere in the 20–35% range depending on tier. Underneath it sit mandatory discounts a restaurant may be required to offer to stay visible in the platform's own listings; paid placement, an additional cost on top of commission to appear prominently; and refund or chargeback exposure, where platform policy can leave a restaurant absorbing some disputed-payment costs. None of that makes marketplaces villains — they provide real technology, real reach, and a real service — but it does mean the advertised percentage understates what an order actually costs by the time it's settled.

Put one order through both channels and the gap stops being abstract. This is a labelled, illustrative example — a restaurant should recalculate it with its own contract terms, not treat these exact figures as universal — but the shape of the result holds broadly. A €30 order through a marketplace, with a 30% commission, a mandatory 10% discount, and roughly €2 of refund exposure plus €1.50 of promotional advertising allocation in a typical week, nets the restaurant about €14.50. The same €30 order taken directly on the restaurant's own site, carrying only a roughly 2.5% payment-processing fee, nets about €29.25. The gap on that single order — close to €15 — is the whole argument in one line: same guest, same kitchen, same packaging, meaningfully different outcome depending entirely on which channel the order travelled through.

The case for a marketplace weakens specifically for guests the restaurant has already won. Visibility genuinely earns its cost the first time a stranger discovers a restaurant through it. It's a much weaker trade the twentieth time the same guest orders, because at that point the restaurant is paying a full acquisition-style commission for a habit it already built. That distinction — new guest versus repeat guest — is the whole basis for a margin-recovery plan, because it means the answer isn't "leave the marketplace," it's "stop paying twice for a guest who already knows the way to the restaurant directly."

Margin recovery works by targeting regulars with subtle incentives, not by declaring war on the marketplace. The guests worth actively moving are the ones who've already ordered several times in a defined recent window — a one-time visitor is exactly the kind of guest a marketplace's reach is genuinely useful for, and chasing them toward a direct channel isn't where the leverage is. Rather than an open price difference between channels, which is expensive and risks looking like a bait-and-switch, the more durable lever is a subtle direct-only benefit: a bundle, a side available only through the restaurant's own ordering page, or an earlier pickup slot — something that makes the direct channel noticeably better without publicly undercutting the marketplace price. That only works, though, if fulfilment stays fair: if marketplace tickets consistently get priority in the kitchen during a rush, guests learn fast that ordering direct means a slower table, and the whole recovery effort undoes itself.

A staged approach tends to work better than an abrupt one. A practical, commonly used sequence: first stabilise the restaurant's own checkout so it's genuinely fast and reliable, then add a loyalty incentive that specifically rewards direct orders, then gradually limit how much of the mandatory-discount program a restaurant participates in on the marketplace, then shift some advertising spend from platform placement toward the restaurant's own visibility, watching direct share and average margin weekly the whole way through — and slowing down if support complaints start rising, since that's a sign operations are being asked to move faster than they can absorb. Many restaurants aim, over roughly a year, toward something in the neighbourhood of an even split between direct and marketplace volume, though the realistic target varies meaningfully by concept — a delivery-only kitchen with no dine-in trade is structurally more marketplace-dependent than a restaurant with a strong walk-in base, and the achievable pace depends on local competition as much as on anything the restaurant does internally. Treat any specific percentage, including the one just given, as a starting point to recalculate against a restaurant's own numbers rather than a target to hit on principle.

Everything in this guide is genuinely useful eventually, but almost no restaurant should try to build all of it at once. The question that actually matters is sequencing: what to get right first, what to add once the foundation holds, and — just as importantly — which pieces of this guide can honestly wait, or don't apply to a particular restaurant at all.

The build order that works for most restaurants runs in three phases. Phase one is owning the menu: a current, accurate, fast digital menu on the restaurant's own domain, because every later phase — checkout, delivery, loyalty — depends on that menu being the single source of truth everything else reads from. Phase two is owning checkout: moving order completion onto the restaurant's own mobile-optimised flow, because this is specifically where marketplace margin gets recovered and where the checkout chapter of this guide pays for itself fastest. Phase three is owning the regulars: loyalty, win-back messaging, and — once there's a real base of repeat guests to justify it — the habit-forming channels like an app or a kiosk that only earn their cost against genuine frequency. Trying to build phase three before phase one is solid is the most common reason a promising channel investment underperforms; an app with nobody yet ordering regularly enough to open it isn't a channel problem, it's a sequencing problem.

Not every channel in this guide is worth building for every restaurant, and venue type is the honest reason why. A fine-dining restaurant with modest online-ordering volume typically gets more value from a fast, well-kept website and solid reservations handling than from a countertop kiosk it will rarely need. A delivery-only kitchen with no dine-in trade is, by its nature, more structurally dependent on marketplace reach than a restaurant with a strong walk-in base, and should weigh the real operational cost of running its own delivery — zones, dispatch, backup plans for what goes wrong — honestly against what it would actually recover before committing to it. A pop-up, a seasonal stand, or any concept with genuinely low repeat-visit potential is usually better served staying web-first rather than building an app that needs a returning guest base to justify its download; once a restaurant has a real base of regulars, that calculation flips and the app's home-screen habit becomes worth the investment. A high-peak, counter-service concept — a busy lunch spot, a food-truck window with a line out the door at midday — is the classic case where a kiosk earns its place fastest, precisely because the two behaviours a kiosk changes (bigger basket, shorter queue) matter most exactly when a queue is actually forming.

Which marketplace matters, and how much of the market it commands, genuinely differs by country — this guide deliberately doesn't pretend otherwise. Lieferando is the reference marketplace in Germany; Uber Eats and Deliveroo are widely present across much of Europe; Glovo and Just Eat carry particular weight in Spain and Italy; Yemeksepeti and newer challengers lead in Türkiye. The achievable direct-order share, the going commission rates, and even which subtle incentive actually moves a guest also vary by local competition and by concept, not just by country. Every specific number in this guide — the €30 example, the roughly-half-direct target many restaurants aim for — is a labelled illustration meant to be recalculated with a restaurant's own contract and its own guests, not a universal figure to chase for its own sake.

A short, practical way to know when a particular channel is actually worth building right now: a queue that's visibly costing orders at peak is the signal for a kiosk; a phone that rings out unanswered during the busiest hour is the signal for answered or automated phone ordering; a marketplace bill that keeps climbing specifically on guests who've clearly ordered many times before is the signal to start a margin-recovery plan; and a delivery promise that fails on a predictable schedule, most often Friday evenings, is the signal to fix zones, dispatch and ETA discipline before adding any new channel at all. Building in that order — solving the problem that's visibly costing money right now, on top of a menu and a checkout that already work — tends to beat building everything this guide describes at once.