Choosing restaurant software without a demo haze

Choosing restaurant software usually starts with a demo, and demos are designed to impress. A friendly salesperson shows a polished screen, a perfect menu, a tidy floor plan and a dashboard full of charts. Every feature looks useful. By the end of the hour, the owner has seen fifty things the software can do and asked about none of the things that actually happen on a Saturday night. The haze lifts a few weeks after signing, when the team finds out what the software is like in a rush.

There is a better way. Instead of watching the supplier's demo, build your own: a short scoring sheet made from the real moments of your own shifts, the busy Saturday, the quiet Tuesday, the Sunday cash-up, and ask every supplier to show those moments. Add three must haves that no amount of features can replace, and a clear view of the full cost. The choice becomes far clearer, and the features you will never open stop distracting you.

This guide sets out how to build the scoring sheet, the three must haves, the POS demo questions worth asking, how to read software subscriptions and their full cost, and how to check whether the software will pay for itself. It ends with the features most venues never open, and a worked example.

A demo is a performance. The supplier has practised it, uses perfect data, and shows the features that look best. They choose the order, the pace and the examples. None of that is dishonest, but it is not your venue. Your menu has modifiers they did not show; your floor plan has odd tables; your Saturday has forty covers arriving in twenty minutes.

The haze comes from seeing many impressive features in a short time. It is natural to assume that more features means better software. But a venue uses a small number of features many times a day, and the speed and reliability of those few matter far more than the number of others.

Before any demo, write down what happens in your venue on three kinds of shift: the busiest service of the week, a quiet service, and the end-of-day and end-of-week jobs. For each, list the moments where software is used: a booking is made, a walk-in arrives, an order is taken, an allergy is noted, a course is fired, a dish runs out, a bill is split, the day is cashed up.

These moments are what the software must handle. They become the scoring sheet.

The busiest shift is the most important test. List the moments that make it hard: a full book with walk-ins waiting, tables arriving at once, orders with changes and allergies, the kitchen falling behind, a large table that wants to split the bill six ways, a dish that runs out at 20:30.

Software that handles these moments quickly and clearly will handle the rest. Software that slows any of them down will cost you on every busy night.

The quiet shift tests different things: how easily a manager can change the menu, add a special, update opening hours or check the bookings for the week ahead. The back office tests the end-of-day cash-up, the weekly reports, and the jobs a manager does on a Monday morning.

List these moments too. They are less dramatic, but they happen every day, and software that makes them slow adds up to hours each week.

Turn the moments into a scoring sheet: a simple list of twenty or so moments, each with a score from one to five for how well the software handles it. Weight the busy shift moments more heavily than the rest, because they matter most.

Give the sheet to every supplier before the demo and ask them to show those moments, in that order, using your menu and floor plan if possible. Score each one as you watch. Afterwards, add up the scores and compare.

The most useful thing you can do in a demo is ask to use the software yourself, or have a member of your team use it. Take an order with three modifiers and an allergy. Split a bill. Move a table. Change a price. How many taps did it take? Was it obvious what to do next? Did you have to ask the salesperson for help?

Software that is easy for the salesperson but confusing for your team will be slow in service. Your team's experience in the demo is the best predictor of their experience on a Saturday.

Usability, how easily people can learn and use a system to do what they need, is the feature that decides whether everything else gets used. In a restaurant, it is tested at the worst moments: a new server on their second shift, a chef reading a ticket across a hot kitchen, a host with a queue at the door.

Watch for small signs in the demo. How many taps does a common task take? Are the buttons large enough to hit in a rush? Is it obvious what has been sent to the kitchen and what has not? These details matter more than any dashboard.

Beyond the scoring sheet, three things are must haves. Without any one of them, no number of features makes up for it:

These are not features. They are the foundations that make features worth having.

The first must have is that the software copes with your busiest shift. It must be fast to use, reliable under load, and clear to everyone who uses it, from the host to the kitchen. A delay of a few seconds per order sounds small, but across a busy service it adds up to minutes lost on every table.

Ask how the software behaves when the internet is slow or drops, and what the team should do. Ask to speak to a venue of a similar size and type that uses it on busy nights.

The second must have is support during service hours. Software breaks, devices fail and connections drop, and they rarely do so at 10:00 on a Tuesday. If the software stops working at 20:00 on a Saturday, who do you call, how quickly will they answer, and can they fix it?

Ask for the support hours, the ways to get help, and the typical response time. Ask other venues how support has been in practice.

The third must have is a clear, written price and a clear answer about your data. What exactly does the monthly fee include? What costs extra? What happens if you add a screen, a user or a venue? What happens to your bookings, guests and sales history if you leave?

A supplier who cannot answer these questions clearly before you sign will not answer them more clearly afterwards.

Some POS demo questions reveal far more than the demo itself:

Ask them in your own words, in the order they happen in your service.

If the software includes a kitchen display, ask the kitchen questions too. How do tickets reach each station? How are allergies shown? How does a chef hold and fire courses? What happens when a dish is remade? Can the kitchen see which tickets are oldest and which station is falling behind?

Ask your head chef to watch this part of the demo. They will see problems a manager might miss.

For bookings, ask how guests book on your own website, how reminders work, how the waitlist is handled, and how the host sees the evening. For guests, ask how a regular is recognised when they book or order, how allergies are kept, and how marketing consent is recorded.

Ask whether booking, order and guest records are connected, or whether they live in separate places that need to be matched.

Most restaurant software is sold as software subscriptions: a monthly or yearly fee per venue, per device or per user. Read the pricing carefully. Some fees grow with the business: a fee per cover, per order, per booking or per user can turn a low starting price into a large monthly bill as trade grows.

Add up the full cost over three years: subscriptions, hardware, set-up, training, any payment processing fees, and the cost of extra devices or users as the venue grows. Compare suppliers on that total, not on the headline monthly price.

Check the contract length and the notice period. A long contract with a short trial can leave a venue paying for software that does not work for it. A short notice period, or monthly billing, gives the venue the freedom to leave if the software does not deliver.

Check what happens at the end of the contract: does the price rise? Is the venue locked into a new term automatically?

Ask how long set-up takes and who does it. Building the menu with its modifiers and allergens, drawing the floor plan, setting the booking rules and pairing the devices all take time, and the supplier's estimate is often optimistic. Ask what help is included.

Ask how long it takes to train a new server, a host and a cook. If the answer is a whole day, every new starter will cost a day. If it is an hour, onboarding stays simple.

Cloud software changes over time: new features appear, screens move, old features are retired. Ask how updates are released, how much notice the venue gets, and whether a change can be delayed during a busy season. A supplier that changes a key screen without warning in the week before Christmas causes real problems.

Ask too what the supplier is planning. A product that is clearly improving is a better bet than one that has stood still for years.

Before signing, estimate the software ROI: what the software will save and earn, compared with what it costs. Will it save hours of manager time each week? Will it reduce no-shows, cut waste, speed up tickets or raise spend? Put rough numbers on each, and compare with the full cost.

If the return is unclear, the software may still be worth buying, but you should know why. Our guide to software ROI shows how to do the sum.

Every demo includes features that look impressive and that most venues never use: elaborate dashboards with dozens of charts, loyalty schemes nobody joins, complicated marketing automations, games for staff, detailed staff performance rankings. They are not useless, but they are rarely the reason software succeeds or fails.

Score them at the bottom of the sheet, if at all. A supplier that leads its demo with them may be steering attention away from the moments that matter.

Ask every supplier for two or three venues like yours that use the software, and call them. Ask what works well, what frustrates them, how support has been, what they wish they had known, and whether they would choose it again. Ask about a busy night when something went wrong.

If you can, visit one during service and watch the team use it.

If a supplier offers a trial, use it properly: set up your own menu and floor plan, train a few team members, and use it for real services, not just a look around. A trial that is only used for an hour by the manager reveals very little.

Plan the trial like a small project: what you will test, who will use it, and how you will judge it at the end.

Choosing one piece of software is easier when you know how it fits into the venue's restaurant technology as a whole. Which of the five jobs does it do: bookings and the room, orders and the kitchen, payment, guests, or the numbers? What will it replace? What will it need to connect to?

Our guide to restaurant technology: what a venue really needs sets out the five jobs and the back office beside them.

Bring it together. Add up the scoring sheet. Check the three must haves: busy shift, support, full price and data. Compare the three-year cost. Weigh the software ROI. Consider what the references said. The best choice is usually clear by then, and it is often not the one with the most features.

Involve the people who will use it every day: the head chef, the front of house manager, a senior server. Software chosen with them is far more likely to work.

Once chosen, plan the move: set up and test before going live, train the team, and choose a quiet week to switch. Keep the old system available for a short time in case of problems. Check in with the team after the first week and the first month.

Our guide to from spreadsheets to software at the right moment covers moving without losing history.

Here is an illustrative venue choosing a new point of sale. The details are examples.

The venue chose the system that scored highest on the Saturday moments, with clear support hours and a flat monthly price.

servearound covers bookings and the room, orders and the kitchen, guests, email campaigns, feedback and reporting in one system, so a scoring sheet can test the whole service from the first booking to the last check. It runs in a browser, on iPhone and iPad and on Android, and screens pair with an 8-character code, so a trial can run on devices you already own. Staff sign in with their own PIN.

Pricing is per venue, per month, with no fees per cover, order, screen or user, so the three-year sum is simple to do. Accounts, payroll, rotas and stock stay in their own tools. See pricing, or get in touch and bring your scoring sheet.

Build a scoring sheet from your own shifts and ask every supplier to show those moments, in your order, with your menu if possible.

It copes with your busiest shift, someone helps when it breaks during service, and the full price and data terms are clear in writing.

Ask to see an order with modifiers and an allergy reach the kitchen, a dish taken off everywhere, a bill split, a table moved, a void, the cash-up, and what happens when the internet drops.

Add up the full three-year cost, including fees that grow with trade, hardware, set-up and training.

Call them, ask specific questions about busy nights and support, and visit one during service if you can.

Long enough to run real services with your own menu and team: usually at least a couple of weeks.

The people who will use it every day: the head chef, the front of house manager and a senior server.

Usually the elaborate ones that look best in demos: complicated dashboards, games and automations most venues never open.

Choosing restaurant software without a demo haze means testing it against your own shifts, not the supplier's script. Build a scoring sheet from the moments of a busy Saturday, a quiet Tuesday and a Sunday cash-up, weight the busy moments most, and ask every supplier to show them. Let your team drive.

Insist on three must haves: it copes with the busiest shift, someone helps when it breaks, and the full price and data terms are clear. Ask the POS demo questions that matter, compare software subscriptions on their three-year cost, estimate software ROI, call references, and see the choice as part of the venue's restaurant technology as a whole.