Specifying a Restaurant POS System: Decisions to Make Before You Buy
Restaurant software is easy to demo and hard to live with. The decisions that cause trouble six months after launch are rarely about features — they are about how the menu is structured, how branches share stock, and which hardware is already bolted to the counter.
A restaurant group reaches the point where the till, the kitchen and the delivery platforms stop agreeing with each other. Usually the trigger is a second branch, or the first month where the stock count and the sales report cannot be reconciled. At that point a POS selection starts, and most of the selection process is spent comparing feature lists that all look similar.
Start from the service flow, not the feature list
Two restaurants with identical menus can need very different systems. A 40-seat dine-in room with one service period needs table state tracking and quick course firing. A takeaway-led site needs order throttling, promise times and a queue that the kitchen can read at a glance. A group with central prep needs recipes and yield at the branch level, not just sales totals.
Writing the flow down — who touches the order, in what order, and where it can wait — produces a shorter and far more useful requirement list than any comparison chart.
The five decisions that are expensive to reverse
One: how the menu is modelled
If modifiers are stored as free text, you cannot report on them, price them differently across channels, or map them to inventory. If they are stored as structured choices with their own prices and stock effect, every later question becomes a query instead of a manual count. This is the single decision most likely to be regretted, because it is invisible until the first menu change.
Two: whether branches share or own their data
A shared menu with branch-level price and availability overrides is not the same as each branch maintaining its own copy. The first makes a group-wide price change a five-minute job; the second makes it a project. Decide which one you are, and check that the system can do it before you see a demo of the ordering screen.
Three: which channel owns the order
Delivery platform orders, in-store orders and phone orders usually arrive through different pipes. If the POS treats platform orders as a separate stream, stock is deducted twice or not at all, and the kitchen sees two tickets for one order. Decide that every order, regardless of origin, becomes the same record with a channel attribute — and verify the platform integration actually writes into that record.
Four: how stock is counted
Recipe-level depletion, batch tracking and wastage logging are three different capabilities that vendors often describe with the same words. A kitchen that preps in batches needs yield and shelf life; a bar needs bottle-level pour tracking. Ask for a concrete example of a stock movement in the system and trace it through to the report.
Five: who owns the data at the end
Sales history, customer records and menu definitions are business assets. Confirm that they can be exported in a usable structure, not just viewed in a dashboard, and that the export includes the fields you would need to rebuild elsewhere.
Hardware: check before you commit
The most common cause of a delayed restaurant rollout is not software. It is a receipt printer that only speaks a proprietary protocol, a cash drawer wired to the printer rather than the terminal, or a kitchen printer on a network segment the POS cannot reach.
- List every device already installed, with model numbers, before scoping.
- Confirm which devices the target platform supports natively and which need a middleware layer.
- Test the kitchen printer under load: one order prints fine, thirty concurrent tickets is the real test.
- Check the network: a Wi-Fi dead spot behind the bar becomes an "unstable system" complaint in week two.
- Decide what happens when the internet drops — local queueing, offline mode, or a documented manual fallback.
What a menu migration actually involves
Importing a menu sounds like a data entry task and behaves like a design task. Menus arrive as PDFs with inconsistent naming, prices that differ between channels, and dishes that exist only as a modifier of another dish. A realistic migration has four steps: normalise the menu into categories and items, separate items from modifier groups, map channel-specific pricing, and reconcile the first week of sales against the old system.
Budget for the reconciliation. It is the step that catches the price that was never migrated properly and the modifier that doubled the cost of a set menu.
A staged scope that holds
- Stage one: ordering, kitchen tickets, payment and the daily close. Nothing else.
- Stage two: stock movements and recipe-level depletion, once the sales data is trustworthy.
- Stage three: multi-branch consolidation, central pricing and group reporting.
- Stage four: delivery platform integration and customer records.
Trying to launch all four at once is the most reliable way to have none of them working in the first month. Each stage produces a stable base for the next, and each has a clear acceptance test that does not depend on the following stage.
Questions we are asked
Can we keep our existing printers and cash drawer?
Usually, if they are standard ESC/POS devices. The check happens during the requirement phase: model numbers are listed, compatibility is confirmed against the target platform, and anything that needs replacing is identified before the quote is finalised rather than after the hardware arrives.
How long does a typical restaurant rollout take?
It depends on the number of branches and whether delivery platforms are in scope. A single site with a structured menu and existing hardware is a short build; a group with central pricing, four branches and platform integration is a staged project. We agree the milestone list and the acceptance item for each before work starts.
What happens to our sales history from the old system?
It is exported and kept, and a summary is imported where the new structure can hold it. Historical detail rarely maps cleanly onto a new menu model, so the practical approach is to preserve the old export intact and reconcile the first week of trading against it.
