Five Restaurant Setups and What RestioX Changes in Each
Composite scenarios, not customer stories. Each one describes an operation you will recognise, the problem it keeps running into, the parts of RestioX that address it, and what actually changes on the floor afterwards.
Operating scenarios, each built from setups that recur across the industry
Feature areas the five scenarios draw on, every one with its own detailed page
Named restaurants, borrowed logos or audited before-and-after figures
Form for describing your own floor and getting an answer about it specifically
These are scenarios, not customers
Every study below is a composite. The operations are drawn from patterns that recur across the industry — branch counts, cover counts, service shapes, channel mixes — and not from any one restaurant’s trading records. No business is named, no logo is borrowed, and no percentage on this page is presented as a measured result from a real site.
What is real is the product. Every capability described here exists in RestioX today and links to the page that documents it, so you can check the mechanism instead of taking a story on trust. Where a number appears it is a setting, a default or a count of what ships, and it says which.
Invented customer evidence is the easiest thing in the world to write and the hardest thing to defend. We would rather show you the machinery and let you decide whether it fits your floor.
A three-branch casual-dining group
- 3 branches
- One brand, one menu family
- Dine-in and own-site ordering
Three sites within an hour of each other, one owner, one brand, and three menus that stopped being the same menu about eighteen months ago. A price rise agreed on Monday reaches the second branch on Thursday and the third whenever somebody remembers. Consolidated trading is a spreadsheet a manager builds by exporting each branch in turn.
The quieter problem runs the other way. On most till systems every manager can see every branch’s takings, staff list and customer records, because the software was never built to keep them apart in the first place.
What changes on the floor
- A price or menu change is made once and pushed to the branches you choose, on a schedule you set rather than by phone
- Sales and tax reports run across all three branches in one pass, so Monday morning stops being an export-and-paste exercise
- Records are branch-scoped by default: a branch manager sees their own floor, and only a role you grant explicitly sees everything
- The audit log names the person, the action and the minute, so a disputed void or discount has an answer instead of an argument
What is switched on
- Multi-branch and franchise Branch-scoped records, menu and scheduled price pushes, all-branches sales and tax reporting, white-label subdomains per franchisee.
- Sales reports Live revenue and covers, item-level margin, hour-by-hour peaks, and a discount and void log naming who authorised each one.
- Staff and permissions Roles built per action rather than per job title, rosters and attendance, and an audit trail behind every sensitive change.
- Menu management Categories, modifier groups, allergen tags and scheduled switchovers, with a one-click 86 that clears a dish from every channel.
A group this size typically runs one consolidated report a day and a handful of scheduled pushes a month. We are not going to tell you it saved a named owner eleven hours a week, because nobody measured a named owner’s week.
A single-site ghost kitchen on two marketplaces
- Zero covers, fully off-premise
- 2 marketplaces plus a direct link
- 1 kitchen, 1 ticket printer
No dining room, no counter, no walk-ins. Everything arrives from two delivery marketplaces plus a small trickle from the kitchen’s own ordering link. There are two tablets on the wall, each with its own alert sound, its own status wording, and its own copy of the menu that has to be edited separately when the fryer goes down.
So somebody retypes marketplace orders into the till, because that is the only way stock deductions and the day’s reporting come out right. The retyping is where the wrong address and the missing modifier come from, and it happens fastest exactly when the kitchen is busiest.
What changes in the kitchen
- Marketplace orders land in the same order list as your own, fire the same kitchen ticket and deduct the same stock — nothing is keyed twice
- Order status is pushed back in each platform’s own vocabulary, so the courier and the guest see the truth without a second screen
- The menu is pushed out to a connected platform, or imported from one, and items are mapped line by line instead of matched by hope
- An 86 is a single action: the item disappears from your own link and from the connected platforms at the same moment
- Every inbound webhook is signature-verified, and a connection health view reports sync success rates instead of failing quietly
- Online ordering and marketplaces A commission-free ordering page of your own, plus two-way sync with Uber Eats, Wolt, Bolt Food, Talabat and Grab in one order list.
- Order management One board for every channel, prep-time countdowns, mid-preparation edits, and an alert when a ticket runs past its promised time.
- Kitchen orders and KOT Tickets at the pass or on a kitchen display, routed per station, with timers that turn amber then red and every modifier shown.
- Inventory and waste Stock falls as dishes sell, par levels raise low-stock alerts, and a draft purchase order can be waiting for you in the morning.
Two-way sync is only ever as good as the connection behind it. A platform that is down is still down, which is why the connection health view exists and why failures surface as alerts rather than as a quiet gap in the day’s orders.
A four-till QSR at lunch peak
- 4 tills
- 1 self-order kiosk in the lobby
- 90-minute peak
Ninety minutes decide the day. Four tills, a queue that reaches the door by ten past twelve, a shift change in the middle of it, and four cash drawers that all have to balance at close. None of this is a technology problem until the counter starts moving slower than the fryer.
Two things usually break first. The till becomes the bottleneck rather than the kitchen, and the cash story falls apart because a drawer changed hands mid-service without being counted.
A lunch service, minute by minute
-
11:40
Four sessions, four declared floats
Each register opens its own session with a counted opening float against a named cashier. From that point every note in and out belongs to a session rather than to the day in general.
-
12:05
The kiosk takes the overflow
Guests who already know what they want build the order at the lobby terminal with your real variations and modifiers, pay at the screen and take an order number. The counter keeps the guests who need to ask a question.
-
12:20
The line drops and the tills keep selling
Offline mode keeps orders being taken on the POS and syncs them when connectivity returns, so a failing router does not become a closed sign in the middle of the rush.
-
12:35
Tickets route themselves
Fryer, grill and drinks each get their own station tickets with timers that turn amber before anybody has to walk over and ask where an order went.
-
13:10
A drawer changes hands properly
The outgoing cashier closes their session and counts the drawer note by note. Expected against actual is held per session, per cashier and per register, so a shortage has a name and a window around it.
-
14:00
The peak is already reported
Hour-by-hour sales, item mix and the discount and void log are there without anyone assembling them, which is what makes next week’s staffing an informed decision rather than a guess.
- Self-ordering kiosk A lobby terminal where guests pick an order type, build the dish with your real variations, pay at the screen and take an order number.
- Restaurant POS A touch till with several tabs open at once, bills split by seat or by item, and an offline mode that keeps selling and syncs later.
- Cash register and drawer control Sessions with a declared float, a note-by-note count, X and Z reports, and expected against actual per cashier and per register.
- Sales reports Hour-by-hour peaks, item mix, per-cashier performance and a discount and void log that names who authorised each one.
A four-till site typically opens four register sessions a day and closes each one with an X and a Z report. That is a description of how the software gets used, not a claim about anybody’s queue times.
None of these is exactly your restaurant
The five above are deliberately typical, which means every one of them is wrong about something on your floor. The useful conversation starts precisely where they stop being accurate about you.
A sixty-cover fine-dining room
- 60 covers
- 1 to 2 turns a night
- Table-side ordering on a phone
One sitting on a weeknight, two at the weekend, and a no-show that takes an entire table out of a service you cannot refill at eight o’clock. The margin here is not in volume. It is in the table being occupied and the meal being right.
Detail is the whole job. An allergy noted when the booking was made has to survive the walk from the host stand to the pass. A wine list that changes weekly has to be current on the floor, not in a printout from Tuesday. And the bill is going to be split by seat, at the table, by somebody holding a phone.
What changes across the service
- Bookings arrive from a widget on your own site into a floor plan showing what is reserved, seated or turning
- Reminders go out before the sitting and the waitlist is digital, rather than a name written on a pad by the door
- Allergy notes and modifiers captured once at the source appear on the kitchen ticket, instead of in a conversation
- Scheduled menu switchovers put the current list in front of the guest without a reprint or a sticker
- Bills split by seat or by item print with a full tax breakdown, or go out digitally by WhatsApp, SMS or email
Seated
Rsv'd
Turning
Seated
Free
Rsv'd
Seated
Free
- Table reservations A booking widget, a visual floor plan of reserved, seated and turning tables, a digital waitlist and reminders before the sitting.
- Staff mobile app A phone app installed straight from the browser: order at the table, clock in, and take a refund behind a manager PIN.
- Bill printing Branded itemised receipts with a full tax breakdown, split-bill printing, one-tap reprints and digital copies by WhatsApp, SMS or email.
- Kitchen orders and KOT Every modifier, allergy note and special request carried onto the ticket at the right station, with timers running from the moment it fires.
We will not publish a no-show percentage. Reminders before a sitting are a mechanism restaurants use to reduce no-shows, and whether they work on your book depends on your guests, your lead times and your city — not on a number we made up.
A café chain running a stamp-card programme
- 4 sites
- Morning trade, mostly repeat
- Paper card being replaced
Four sites, a morning trade that is almost entirely repeat business, and a paper loyalty card that gets forgotten, laundered, and occasionally stamped twice by a kind barista. The programme works well enough that nobody wants to stop it and badly enough that nobody can say what it costs.
The deeper gap is that the chain cannot name its own regulars. Spend goes through the till as anonymous transactions, so there is no way to notice that a Tuesday-morning regular has not been in for five weeks, let alone to do anything about it while they are still winnable.
What changes at the counter
- The stamp card is digital and lives in Apple Wallet or Google Wallet, so it cannot be lost, forgotten or double-stamped
- Points earn on the net subtotal — after discounts, before tax and delivery — so a promotion never quietly pays out at full-price rates
- One programme is shared by the till and the ordering page across all four sites, instead of a second system nobody reconciles
- Segments group guests by real behaviour, and churn prediction flags the regulars who have quietly stopped coming
- Campaign multipliers such as double points on a quiet Tuesday are scheduled ahead and applied at checkout without a cashier keying anything
Typical starting settings
- 10 Stamps on a classic buy-ten-get-one card — the threshold is yours to set
- 3 Tiers most operators begin with, each carrying its own points multiplier
- 2 Phone wallets the digital card lives in: Apple Wallet and Google Wallet
- 1 Programme shared by every branch, the POS and the online ordering page
Every figure above is a configuration value you choose in the admin. None of them is a result measured at a café. Treat any vendor number that does not tell you which of the two it is with a great deal of suspicion.
What all five setups have in common
Different floors, different problems, the same handful of mechanisms doing the work underneath. If you recognised yourself in more than one scenario, this is the part that carries across all of them.
-
One order list, whatever the channel
Counter, table QR, kiosk, your own ordering page and the delivery marketplaces all land on the same board and fire the same kitchen ticket.
-
Records are branch-scoped by default
A branch sees its own floor unless a role explicitly grants more. Reporting across branches is a permission you hand out, not an accident of the database.
-
The money has a guard in front of it
Refunds, voids and discounts sit behind a manager PIN and land in an audit log naming the person, the action and the minute it happened.
-
Stock moves without being told
A sold dish deducts its recipe ingredients, a par level raises the alert, and the draft purchase order is waiting rather than being remembered.
-
It keeps selling when the line drops
Offline mode on the POS carries orders through a connectivity gap and syncs them the moment the connection comes back.
-
The same data feeds the AI tools
Menu engineering, profit-leak analysis and the daily brief read your own order lines and costs, so they answer about your restaurant rather than a benchmark.
What this page claims, and what it does not
Buyers in this category get shown a lot of proof that cannot be checked. Here is exactly what kind of statement each part of this page is making, so you know what to weigh it against.
| Kind of claim | On this page | Where it does or does not exist |
|---|---|---|
| Named restaurants with published trading figures | No | Nowhere on this site. We do not publish a customer’s numbers, with or without their name attached. |
| Borrowed customer logos | No | Nowhere. A logo wall proves that a logo exists, not that the software worked for the business behind it. |
| Before-and-after percentages presented as results | No | Nowhere. Nobody has audited a RestioX customer’s books, so nobody here is in a position to publish the difference. |
| Quotes from operators, with a name and a role | Not here | Published separately on the reviews page, in the words they were given, and not blended into the studies above. See the reviews page |
| Product behaviour, described mechanism by mechanism | Yes | Throughout. Every capability named in a scenario links to the feature page that documents it in detail. |
| Settings, defaults and typical configuration values | Labelled | Used sparingly and always marked as a value you choose, never as a result you are being promised. |
| Composite operating scenarios | Yes | All five of them, and the note at the top of this page says so before you read a single one. |
The quotes we do have are on the reviews page
Scenarios explain the machinery. If you would rather read what operators said in their own words, with a name and a role attached, that is published on its own page and kept separate from the studies above.
None of these is exactly your restaurant
The five above are deliberately typical, which means every one of them is wrong about something on your floor. The useful conversation starts precisely where they stop being accurate about you.
Send us the shape of your operation and we will tell you which parts of RestioX apply, which parts you would not bother switching on, and where the setup would be awkward. If something does not fit, it is faster for both of us to hear that early.
Worth putting in the message
- Covers or transactions on a normal day, and what a peak actually looks like
- How many sites, and whether they share a menu, a brand or just an owner
- Which channels you sell through, including any delivery marketplaces
- How many tills, kitchen screens, printers and drawers are in play
- What you run today, and the one thing about it you would fix first
Why it is written the way it is
Because we do not have permission to publish anybody’s trading figures, and a case study without figures is a testimonial with extra formatting. Naming a business also means publishing details about its costs, its volumes and sometimes its staff, and that is the operator’s decision to make rather than ours. When a customer wants their story told and is happy for the numbers to be checked, we will publish it as a real case study and label it as one.
The configuration values are real in the sense that they are settings you can actually set: ten stamps on a card, three tiers, four register sessions for four tills. Nothing on this page is a measured result from a live restaurant, and wherever a figure could be mistaken for one, the note beside it says it is not. Counts of what ships with the product, such as the number of feature areas or supported marketplaces, are exact.
Ask on the contact form and we will look into it. We will not hand out a customer’s details without asking them first, so whether an introduction happens depends on an operator being willing — which is the same reason this page is written the way it is rather than filled with names.
Read the one whose problem sounds like yours rather than the one whose cover count matches. A twelve-seat bakery and a sixty-cover dining room have almost nothing in common on paper and very nearly the same problem getting an allergen note from the booking to the pass. The mechanisms travel further than the archetypes do.
No. Each scenario lists the capabilities that address its particular problem, not a bundle you have to buy together. Features are switched on per restaurant, and plenty of sites run the till, the kitchen tickets and the reports for a year before they turn on loyalty or connect a marketplace.
If you are running RestioX and you want your operation written up, tell us on the contact form. It would be published only with your approval on the wording, and anything presented as a result would have to be a figure you can see in your own reports rather than one we estimated for you.
Start from the setup you actually have
Open a trial and load your own menu, or send us the shape of your operation and we will tell you where RestioX fits and, just as usefully, where it does not.