POS software for a restaurant: judging it on what it does

Two suppliers send you a feature table. Both tables have a tick in every row. You are no closer to a decision than you were before you asked.

Pos software for restaurant use is the part of the system you live inside, so it deserves better than a table. A screen and a drawer are much the same wherever you buy them. The software decides how many taps a busy order takes, how often a ticket reaches the kitchen wrong, and how much of your night goes on fixing both.

This guide gives you a way to judge it. What to make a salesperson show you. Where the real cost hides in a quote. And the work a restaurant in the UAE needs doing that no counter software has ever done.

A tick is not a promise

Suppliers write their own tables, so a tick only means the feature exists in some form. It says nothing about the form.

"Stock control" can be a number somebody types in on Monday, or a count that falls on its own as orders arrive. "Loyalty" can be a points field nobody looks at, or a card sitting in a customer's phone. "Reporting" can be a file you download and open in a spreadsheet, or a screen that answers a question you actually had. All of those earn the same tick.

So judge behaviour. Ask for one specific thing to be done in front of you, and watch the salesperson's hands rather than the slide.

Four things to make them show you

Order the hardest dish on your menu. Choose one with three choices the customer must make: size, sauce, spice level. Count the presses from start to finish. Then read the kitchen ticket and check that all three choices are on it.

Run out of a sauce, not a dish. Ask them to set one option to zero in the middle of a service, then try to sell it anyway. If the option can still be chosen, somebody in your kitchen will be improvising on a Friday night.

Change a price while you watch. Then ask two questions. What does it cost when the supplier has to make the change, and may you make it yourself at eleven at night?

Ask for your own data, in the meeting. Sales history and customer list, exported by you, with no support ticket and no fee.

The fourth is the one people skip and later regret. Pos programs for restaurants are easy to walk into and vary enormously in how easy they are to walk out of.

Where the money hides in a quote

The monthly licence is rarely the line that hurts. Ask for a two year total that includes all of this on one page:

• a licence charged per station rather than per restaurant
• the installation visit, and the second visit when the menu changes shape
• a fee for each app you connect to it
• a support tier, in case the useful one is not the standard one
• the notice period, and the cost of leaving in month nine

Compare nothing until you have that page from every supplier.

The module trap

Most pos system software for restaurant use is sold as a core plus modules. Loyalty, marketing, delivery, stock, staff rotas.

The core is usually strong, because it is what the company was built to do and it has been shaped by thousands of busy evenings. The modules are usually thinner, because they exist to stop you buying elsewhere. That much is survivable. What is not survivable is a thin module holding something you cannot get back.

"Before you compare features, ask one question: can I take my customer list out of this tomorrow? The answer tells you who the software really works for."

— Anzul Aqeel, founder of Get Menu

Go module by module and ask that one small question. Does my data come back out of this one? A weak module you can leave is an irritation. A weak module holding your customer list will keep you there for years.

The work no counter software does here

Your counter serves whoever is standing in front of it, and it does that well. It has never been able to reach a customer at home, and in this country a great deal of the trade is at home, in a tower, on a phone.

Here is the work that gets left undone. None of it needs hardware, and this is the part we build.

The menu has to be somewhere a customer can open it. Get Menu gives a restaurant its own ordering page, with 12 page layouts so a grill and a bakery do not read the same way, and a link that carries your own name. Our guide to QR menus covers how the code and the page fit together.

Somebody has to keep it right. You edit it yourself in a browser. Options and add-ons carry their own prices, required choices are enforced before an order can go through, and a spreadsheet of two hundred items goes in at once instead of being typed.

Nothing may sell at yesterday's price. Every line is priced again at checkout from the live menu, so a page a customer left open overnight cannot cost you money.

Nothing may sell once it is gone. Stock counts fall on items and on options as orders come in, and a dish greys itself out at zero with nobody watching it.

Somebody has to be told. A confirmation reaches the customer, a ticket reaches the managers' group, and a dispatch reaches the riders' group carrying the GPS pin dropped at checkout. That is 3 messages in about 2 seconds and no one typed any of them.

The building has to be found. Delivery fees are set per building, so the tower next door and the villa across town each pay what they should.

The table should not have to be typed. Every table gets its own code, made in a designer so it looks like your restaurant, and the print pack arrives by email ready for the printer.

A regular should be worth something. Stamps accrue from the order itself. Tiers your regulars grow into carry their own automatic discount, and the card sits in the phone's wallet through Google's loyalty card format. Coupons, upsells and fixed-price bundles come with caps, exclusions and expiry dates, and two automatic discounts never land on the same order.

Your accountant needs paper. Tax invoices carrying your registration number are downloaded by the customer as a PDF, with no account and no login.

Changing systems without losing two weeks

Switching is not one hard problem. It is two weeks of small ones, and three of them are predictable.

The menu. Ask whether it comes in from a spreadsheet. If every item has to be typed, set aside a full day for a large menu and expect a few wrong prices for a week afterwards.

The staff. People are quick on the system they know and slow on the one they do not, and the slowness always lands on your busiest shift. Run the new one alongside the old one on a quiet Tuesday before it meets a Friday.

The history. Pull last year's sales out of the old system before the contract ends, not after. Once an account is closed a supplier has little reason left to help and often no obligation either.

None of that is an argument for staying on something that is not working. It is an argument for changing in February rather than in the week before a holiday.

What we do not do, said plainly

Get Menu is not counter software. It opens no cash drawer, drives no card reader, and does not close your day. If you need those, buy them and keep them. A restaurant POS and an ordering layer are two different purchases doing two different jobs.

Payment is cash or your own card machine, at the door or at the table. There are no online payments in the system. One benefit of that limit is that no card details exist in it for anyone to steal, and order details older than 120 days are cleared automatically.

Our pricing lives on the pricing page rather than in this article, and the trial runs 15 days without a card, which is long enough to put a real weekend through it.

Frequently asked questions

Is Get Menu pos software for a restaurant?

Not in the counter sense. It runs no drawer, no card reader and no end of day. It is the ordering, menu, stock and loyalty layer that sits beside whatever counter software you already use.

What should I ask to see in a demo?

The hardest dish on your menu ordered start to finish, one option set to zero mid-service, a price changed while you watch, and your own data exported in the meeting. Those four find more than an hour of feature talk.

Can I run two systems at once?

Yes, and most restaurants already do without giving it a name. The counter handles money in the room. The ordering layer handles the customers who never come into the room.

How do customers pay?

Cash, or your own card machine when the food arrives. The software carries the order and never touches the money.

What happens to my data if I leave?

You export it yourself, on any day, including your last one. Put that question to every supplier before you sign, and get the answer in writing.