How to choose a POS system for a restaurant

A POS system stays in a restaurant for years, and the whole operation grows around it. Replacing one is expensive: the menu is re-entered, the team is retrained, and sales history often does not move across. So choose from a checklist, not from a demo.

Start with a question about yourself

Requirements follow from the format, not the other way round:

• Fast food and tea houses — speed and prepayment. A check should close in three taps on one screen.
• Full-service dining — table map, open bills, bill splitting, server shifts.
• Delivery — couriers, addresses, integration with outside sources such as aggregators or a CRM.
• Multiple branches — a shared menu, consolidated reporting, one owner dashboard.

If your venue combines formats, you need all of the above — that is a valid answer too.

The functional checklist

1. Does it work without internet

This is question one. If the system is fully cloud-based, a dropped connection stops the restaurant: no checks can be opened, no orders reach the kitchen. The right architecture is a local server on site, with the cloud used for sync and reporting. Ask it plainly: if the internet is down for three hours, does the room keep working, and does the data upload itself once the link returns?

2. Kitchen routing

Each dish must reach the right station: grill items to the grill, salads to the cold section, drinks to the bar. Can one order split across several printers? Does an added item print as a separate ticket? Does a cancellation reach the kitchen?

3. Shifts and X/Z reports

Shifts should be tied to a register, cash counted at open and close, and the variance recorded. You want both an interim (X) and a final (Z) report.

4. Recipe cards and stock

Are ingredients deducted automatically on sale? Are prep items (cascading recipes) supported? Is the theory-versus-actual gap calculated during inventory? Many systems either lack this block or sell it separately — establish this early.

5. Fiscal compliance

Does the integration with fiscal and tax requirements work, who configures it, and is the queue preserved when the connection drops?

6. Access control

Can roles be configured separately (owner, manager, cashier, server, kitchen)? Does voiding a cooked dish require a manager PIN? Is every void and discount logged with who did it and when?

7. Reporting and owner visibility

Can the owner see daily revenue, average check, voids and till variance without being in the building? Is it available on a phone?

The technical questions nobody asks

1. Who owns the data? Can you export the menu, the guest base and the sales history via CSV or API?
2. What hardware is required? Is there a list of supported printer models? Some systems only run on their own hardware, which doubles the budget.
3. How do updates ship? Automatically, and do they ever land during peak service?
4. Support. In which language and during which hours? Restaurants work in the evening — a nine-to-six support window does not fit.
5. What happens when you open a second site? How does pricing change, and does the menu copy across?

Three-year cost of ownership

Comparing monthly subscription prices is not enough. The full calculation:

TCO = hardware + implementation + (monthly fee × 36) + training + add-on modules

Example: hardware 25M + implementation 5M + subscription 1.2M × 36 = 43.2M + training 3M = 76.2M UZS over three years, roughly 2.1M per month. The system that looked cheaper can end up more expensive once the stock module and a second printer are added — so cost the whole thing.

How to run the test

A demo runs on the vendor's script. Your test must run on yours:

1. Enter 20 real dishes from your own menu, modifiers included.
2. Run it in parallel for two weeks, covering your busiest evenings.
3. Deliberately test three scenarios: pull the internet, switch off a printer, split a bill.
4. Let the servers use it, not you. Time how long training actually takes.
5. At shift close, reconcile the report against hand-counted cash.

Red flags

If any of these show up, slow down and ask for an answer in writing:

• No trial period, or one limited to a vendor-led walkthrough.
• No data export, or it is sold separately. That means you cannot leave tomorrow.
• A hidden price list — a different number for every customer and nothing specific in the contract.
• The feature you need is coming soon. Without a written plan and a date, treat it as absent.
• Support is chat-only and unavailable during the hours the restaurant is busiest.
• Separate charges for every small change. Adding a dish, a printer or a staff member is daily routine and belongs in the subscription.

Where to start

Pick the ten items from the checklist above that matter to you and send the same list to every vendor. Collect the answers in one table. Only then watch the demos — by that point you know what to ask.

One last piece of advice: choose for the restaurant you will have in two years, not the one you have today. Even with a single room now, stock control, recipe cards, multiple branches and delivery will come up later. In systems like VKassa those modules are switched on per branch — off while you do not need them, and enabled later without replacing the whole system.