Insights

Building a POS menu that does not annoy you later

Build from the sales report, not the printed menu. Where modifiers go wrong, why notes fields are a leak, and the two people who must check it.

Every complaint about a point of sale that is not about hardware is really a complaint about the menu inside it. Buttons in the wrong place, an item that rings up at the wrong price, a modifier nobody can find, a report with a hole in it — all menu problems wearing a software costume.

The menu is also the one part you control completely. Here is how to build one that does not annoy you for the next three years.

Build from your sales report, not your printed menu

Your printed menu is organised for customers. The screen should be organised for the person ringing it in, under pressure, without looking.

So start from what actually sells. Pull last year's item sales, sort descending, and build in that order. The top twenty items are most of your volume and they should need the fewest taps.

This also surfaces the dead weight. Every menu in a system that has been running a few years has items nobody has sold in a year, duplicate entries created by someone in a hurry, and categories that stopped making sense after a menu change. Do not carry any of it across.

Categories are for finding things fast

Not for matching the menu's design. A server looking for a flat white does not care that the printed menu groups it under "hot drinks, espresso-based".

Rules that hold up:

  • Few categories, obvious names. If someone has to think, it is wrong
  • Order by frequency, not alphabetically. The most-sold item in a category goes first
  • Put the thing everyone orders on the first screen. If your best seller needs two taps to reach, fix that before anything else
  • Never more than one level of nesting. Sub-sub-categories are where items go to be forgotten

Modifiers are where systems are won and lost

A modifier changes an item. Three things about them decide whether your menu is good.

Required versus optional. Steak needs a temperature — that should be impossible to skip. Extra prawns is optional. A system that treats both the same produces either tickets missing information or a forced tap on every item.

Priced versus free. No onions is free. Add bacon is not. Oat milk might be either, and it should be whatever you actually charge, not whatever is easier to configure.

What the kitchen sees versus what the bill says. These are legitimately different. The kitchen needs "NO NUTS" in large letters. The bill does not need it at all.

The test for a modifier set: can a server ring in your single most awkward real order without typing anything into a notes field? If not, the modifier set is incomplete, and everything that ends up in notes is invisible to every report you own.

Notes fields are a leak

Worth its own heading because it is the most common way a menu quietly fails.

Anything staff type as free text is unsearchable, unreportable and often unread. If the same note is being typed repeatedly — a common substitution, a common allergy, a common split — that is a modifier that does not exist yet.

Read a week of notes fields once a quarter. Every recurring one is a menu fix.

Get tax right, item by item

Not a setting you do once at the top level. In most places the treatment varies by item and by whether it is eaten in or taken away, and alcohol and packaged goods often differ again.

Check it against real receipts: one dine-in food item, the same item as takeaway, a drink, alcohol if you serve it, and anything sold in a package. If your jurisdiction treats any of those differently and your menu does not, you have a compounding problem that is tedious to unwind.

This is worth verifying against your state or local rules rather than trusting a default, and worth asking your accountant about once rather than assuming.

Have two different people check it

The chef checks that the items and modifiers describe reality.

A server checks the ringing-in flow — how many taps, whether anything is hard to find, whether the awkward order works.

These two find completely different problems and you need both. An owner checking their own menu finds neither, because they know where everything is.

Then revise it, twice a year

A menu is not a setup task. Prices change, items are added, staff develop workarounds.

Twice a year, spend an hour: remove anything with no sales, fix any price that has drifted from what you actually charge, read the notes fields, and ask the two checkers again. That hour is the difference between a system people like using and one they complain about.

← More insights

Keep reading

Running a Profitable Vegan Restaurant with POS Software

3 min read

Learn how modern POS software, automated reservations, and kitchen tools help your vegan restaurant control labor costs and improve margins.

Technology for Chain Casual Dining Restaurants

3 min read

Learn how chain casual dining restaurants manage menus, automate phone orders, control prime costs, and scale point-of-sale systems across locations.