Restaurant management system: what it includes, and why it isn't one product

Ask ten people what a restaurant management system is and you will get ten answers. A till. A kitchen screen. A table plan. A stock system. A rota. Something that tells you food cost. All of those are real answers, and that is precisely the problem: "restaurant management system" is not one product, and treating it as one is the reason most restaurant software projects — bought or built — end up half-used.

This page is the counted version. We went through 59 real restaurant systems and tallied what each one actually ships, so you can see which capabilities are load-bearing and which are optional. Then the venue shapes that change the answer, the three design decisions that decide whether the thing survives a Friday service, and how to scope a build that finishes.

Eight venues, eight different products

Before any feature list, the shape question. These are not variations on a theme — they have different mandatory modules and different failure modes:

Counter-service cafe. Order and pay at once, no table state. The simplest real system, and the one most builds should aim at first.
Full-service dine-in. Tables carry an open bill across a whole meal. Adds a floor plan, course firing, transfers between tables, and split bills. Roughly doubles the work of counter service.
Quick service. Speed is the product. Order throughput, screen taps per order, and a kitchen that keeps up.
Bar. Tabs held against a person rather than a table, rounds, and a drink that is poured before it is paid for.
Pizza and takeaway. Addresses, promised times, and a queue that is time-ordered rather than table-ordered.
Cloud kitchen. No customers at all — orders arrive from delivery platforms, and the whole product is a queue and a dispatch record.
QR table ordering. Guests order from their phones, which means a public ordering surface with its own security concerns, sitting on top of the same order records.
Multi-location chain. Everything above, plus the requirement that one site cannot see another's numbers, and that head office can see all of them.

If you take one thing from this page: pick the shape before the features. A specification that does not name the venue shape silently averages all eight, and the average is a product-CRUD app with a cart bolted on.

The counted core

Ranked by how many of the 59 systems ship each capability:

Capability	Systems	Share
Menu categories and items	44	75%
POS order entry	41	69%
Receipts and kitchen order tickets	35	59%
Service modes — counter, dine-in, takeaway, delivery, phone, QR	34	58%
Reports dashboard	34	58%
Payments	33	56%
Kitchen display system	31	53%
Order statuses	30	51%
Modifier groups	28	47%

Below that line sit the capabilities that belong to particular venue shapes rather than to restaurants generally: a visual floor plan in 27, QR ordering in 20, recipe and bill-of-materials costing in 17, phone orders in 8.

That distribution is the useful finding. Only two capabilities appear in more than 70% of systems, which tells you how much of this market is genuinely optional — and how badly wrong a build goes when it treats a floor plan or a KDS as a default rather than a decision.

What each one has to actually do

A feature list is worth very little without the difference between the real version and the decorative one. Each of these is a test you can run in a demo.

Menu categories and items — 44 of 59. The decorative version is a product table. The real version has a separate kitchen name from the customer-facing name, a sold-out toggle that takes effect on every ordering surface at once, and availability that can differ by service mode. Test: mark a dish sold out and check the QR menu, the till and the kitchen screen.

POS order entry — 41 of 59. The decorative version is a form. The real version is a grid built for a thumb during a rush: search, quantity, notes, discounts, and no dialog between the tap and the order. Test: ring in a six-item order and count the taps.

Receipts and kitchen order tickets — 35 of 59. These are two different documents and a surprising number of builds produce only one. A KOT goes to a station, carries modifiers and course, and marks voids so the kitchen knows what to bin. Test: void an item after it has fired and see what the kitchen is told.

Service modes — 34 of 59. Not a dropdown. Each mode changes what is required: a delivery order needs an address, a dine-in order needs a table, a phone order needs a promised time. Test: switch mode mid-order and see whether the required fields change.

Reports dashboard — 34 of 59. The decorative version is a counter incremented as things happen. The real version derives every figure from order records at read time. Test: refund an order and watch whether today's takings move. Then reproduce one number by hand from the order list.

Payments — 33 of 59. Manually recording a payment is a legitimate first version and far more honest than a fake integration. What matters is that a payment is an event with a method, an amount and a time — not a status flag on the bill. Test: split a bill across cash and card and look at what was stored.

Kitchen display system — 31 of 59. The decorative version is an admin table filtered to "new". The real version has station lanes, elapsed timers, bump and recall, and an expo view. Test: bump a ticket and then recall it. If recall does not exist, it is a list, not a KDS.

Order statuses — 30 of 59. New, fired, preparing, ready, served, closed, cancelled, refunded. The decorative version is a text field. The real version refuses invalid transitions. Test: try to refund something that was never paid for.

Modifier groups — 28 of 59. Required modifiers, optional add-ons, size and spice. The decorative version is a notes box. The real version blocks add-to-cart until a required modifier is chosen — because "steak, no temperature specified" is a ticket the kitchen cannot cook. Test: try to add a dish with a required choice without choosing.

What a restaurant management system is not

Half of the disappointment in this category comes from expecting one system to be five. These are adjacent products, and every one of them gets conflated with "restaurant management system" in sales conversations:

Accounting. Your POS produces sales figures; it is not a ledger. It should export cleanly to one. A system that tries to be both usually does neither, and the tell is a chart of accounts appearing in a till.
Payroll and rotas. Clock-in often lives in the POS, because staff are already standing at it, and that is reasonable. Actual scheduling, holiday and pay are a different product with different buyers and different law attached.
Reservations. Genuinely separate, and usually better bought than built — the value of a booking system is largely in the diner-facing network, which you cannot build. What matters is that a reservation can become a table with an open bill without anyone retyping it.
Delivery aggregators. Orders arriving from third-party platforms are an integration, not a feature. The honest first version is a tablet on the counter and someone keying it in, and every operator knows it.
Purchasing and supplier management. Deducting stock as you sell is inventory. Ordering more of it, receiving it against a delivery note, and reconciling an invoice is a purchasing system — much larger, and a common source of a project that never finishes.

None of those is unreasonable to want. The failure is wanting them all in first delivery, which is how a system that could have been running in a month is still half-built after six.

The useful question when someone proposes a module: does this change what happens on the pass during service? If yes, it belongs in the core. If no, it can wait, and waiting costs you nothing.

Who uses it, and why that changes the design

A restaurant system has four distinct users and they want opposite things, which is why so many of them feel wrong to somebody.

The cashier or server wants speed and nothing else. Every dialog, confirmation and dropdown is a tax paid hundreds of times a shift. Design for the thumb of someone who is being watched by a queue.

The kitchen wants clarity and permanence. A ticket that changes under them is worse than no system. This is why bump-and-recall matters and why a void after firing has to be announced rather than silently removed.

The manager wants control and exception handling: who authorised that discount, why is the drawer short, which server is comping the most. Almost all of this is reporting on events the system already recorded — provided it recorded them as events.

The owner wants three numbers and does not want to learn the system to get them. Takings, labour and food cost. If getting those requires opening four screens, they will ask the manager instead and the reporting module was a waste.

Naming which of the four must love the first version is the single most useful scoping decision available, because it settles a dozen interface arguments before they happen. A build that tries to delight all four delights none.

Three decisions that quietly decide whether it works

These are not features. They are design decisions that never appear on a requirements list and determine whether the system survives service.

1 · When stock is deducted

If selling a dish is supposed to reduce its ingredients, when does that happen? At payment time is the intuitive answer and it is usually wrong: a kitchen has already used the ingredients by the time the bill is settled, and in a dine-in venue that can be an hour later. Deduct at fire time and your stock reflects the kitchen; deduct at payment and it reflects the accounts. Both are defensible, and the failure is not choosing — because then a void, a comp and a refund each do something different and nobody can explain the variance.

2 · What happens at shift close

Cash drawer close is where real operational disputes happen. The decorative version is a browser confirmation dialog. The real version is a structured review: expected versus counted, per payment method, with the variance recorded and attributed. That record is the thing you look at when a drawer is repeatedly short, and it does not exist if closing a shift is a button that says OK.

3 · Whether a manager approval actually checks the manager

Discounts, voids, refunds and price overrides usually require authorisation. The decorative version prompts for a PIN and accepts any valid one. The real version checks the role. This sounds obvious and it is one of the most common misses — a cashier password that authorises a manager discount defeats the entire control. Test: enter a valid cashier credential at a manager prompt.

What we found when four models built one

We handed a single advanced full-service specification — sixteen selected features, POS through multi-location — to four coding models, and scored them by driving all sixteen lifecycles end-to-end in a browser rather than by reading their completion documents. That distinction turned out to matter more than anything else about the exercise.

All four produced working restaurant systems. The differences:

The strongest build drove every one of the sixteen lifecycles without breaking: selling a dish depleted its ingredients and moved the food cost as it happened, courses fired to the kitchen in order, tables cleared correctly when parties split, and a valid cashier password would not authorise a manager discount. Its only loose ends were ones it flagged itself.
One had the best multi-location isolation — a branch manager provably could not see another branch's sales, refused on the server — but you could not create modifier groups inside the app, and refunding a settled bill reopened it instead of leaving it closed.
One had the tightest financial controls: nothing could be rung up unless the till was open for the day, past days locked so numbers could not be quietly altered. At audit it could only sign people in through its own hosting platform, so it could not be moved anywhere else.
One shipped the widest surface — eighteen staff screens including rotas, catering, kiosk and delivery-app orders — and several of them broke: the receipt page went blank after a sale, staff could not clock in, and group bills were double-counted.

Notice that none of those failures is a missing feature. Breadth was not the differentiator; whether the lifecycles actually completed was. Recipe depletion on sale — a single behaviour, four words long in a specification — separated a working kitchen from a convincing one.

The full ranking, with the systems running live, is on the build-off board.

Scoping a build that finishes

If you are commissioning or building one, this is the shape of a specification that gets finished.

Name the venue shape. One of the eight above. Write down which of the other seven you are explicitly not building.
Basic first delivery is the order loop: menu with modifiers and a sold-out toggle, POS entry, order statuses, receipts and kitchen tickets, payments recorded, shift open and close, and a reports dashboard derived from orders.
Every branch family is an explicit yes or no — floor plan, split bill, KDS, QR ordering, phone and delivery queues, reservations, recipe costing, integrated payments, hardware, offline, multi-register, multi-location, loyalty. A branch that is neither selected nor refused is a branch that arrives half-built.
State the three decisions above in writing: deduction timing, shift-close review, and role-checked approvals.
Reports derive from order records. No stored counters.
Acceptance is driving the lifecycle, not a screenshot. Ring it in, fire it, bump it, serve it, split it, settle it, refund it — and check the stock and the report after each.

The single most valuable line in that list is the third. Scope drift in restaurant software is not gradual; it arrives all at once when a branch family nobody decided about turns up as a menu item that leads to a half-finished screen.

If your question is about the architecture rather than the scope, cloud-based restaurant POS covers what "cloud" actually buys you and what happens when the connection drops mid-service. Free restaurant POS software covers where the free and cheap tiers stop, and what a kitchen needs that a retail till does not.

And if you are pointing a coding agent at this, the Restaurant Management planner is the specification we hand ours — the venue shape locked first, every branch family gated explicitly, and the deduction-timing and approval decisions made before a line of code.