POS features that matter after the first week

In the demo, every feature looks essential. The salesperson shows a loyalty scheme, a dozen kinds of report, a stock module, a scheduling tool, customer profiles and a dashboard with thirty charts. Each one sounds useful, and together they make the system feel complete.

Then the first week of real service arrives. The features that matter turn out to be the ones nobody demonstrated with any enthusiasm: how fast a server can ring in a burger with no onions, how easily a check splits for a table of six, how quickly a void can be done without calling a manager. The thirty charts are opened once and never again.

This guide covers the POS features a venue actually uses every shift, the ones it uses weekly or monthly, and the long list that rarely matters, so you can judge a system by the short list rather than the brochure. Every venue and figure in it is an example.

Demos are built to impress, not to reflect a busy Saturday. A point of sale is where a sale is completed, and in a restaurant that means hundreds of small actions a night, not a tour of menus and charts. A salesperson shows the broadest range of POS features in the shortest time, usually on a quiet screen with a simple menu and no queue of servers waiting to use it.

The features that matter in service are hard to demonstrate, because they are about speed, reliability and small details under pressure. How many taps does it take to add a side? What happens when two servers try to open the same check? Can a server find a dish in a large menu in two seconds?

Judge a system by what your team will do hundreds of times a day, not by what the demo shows once.

A handful of POS features are used constantly, by every server, on every shift. Ringing in orders, with their options and changes. Opening and finding checks, usually from a table plan. Sending orders to the kitchen, and holding or firing courses. Splitting, moving and closing checks. Recording payments.

If any of those is slow or awkward, the whole service suffers. A few extra seconds per order become minutes per table and hours per week, and frustrated servers find workarounds that cause mistakes.

These are the features to test hardest, with your own menu, your own staff and a realistic rush.

The most important single feature is how quickly and accurately a server can ring in an order. Count the taps for a typical order: a steak, medium rare, with a side swapped and a sauce added. Count them for a table of six with two changes each.

Look at how dishes are found: by category, by search or by a favourites screen. Look at how options are chosen: required choices presented at once, common removals easy to find, notes easy to add but not needed for routine changes.

A system where a common order takes five taps rather than fifteen saves real time, and the server's attention stays on the guest rather than the screen.

Most table-service venues open checks from a table plan: a map of the room on the screen, showing which tables are free, occupied or waiting for the bill. A good table plan matches the real room, shows status at a glance and opens a table's check with one tap.

Checks need to be easy to find, even for tables a server did not open. They need to show what has been sent, what is held and what has been paid. And they need to stay correct when two servers touch the same table.

Our guide to order management from table to pass covers how orders should flow from the check to the kitchen and back.

The changes a server enters must reach the kitchen exactly as intended. That depends on how the POS handles modifiers: choices set up on each dish, required where needed, removals taken from the dish's ingredients, and notes for anything else.

A POS that forces servers to type every change produces inconsistent tickets and missed changes. One that offers the common changes as taps produces tickets the kitchen can read in a second.

Test it by entering your hardest orders and looking at what the kitchen receives. If the ticket is not clear, the feature does not work, however it looks on the till.

In a sit-down venue, the POS must let servers send starters at once and hold mains until the table is ready, then fire them in one action. Without that, either the kitchen cooks everything at once or the server has to remember to send the mains later.

Look at how held items appear on the check and in the kitchen, and how quickly the fire can be sent. A fire that takes one tap gets sent on time; one buried in a menu gets forgotten.

Look also at remakes. When a dish comes back, the server should be able to send it back to the kitchen as a remake, without charging the guest twice or confusing the bill.

Tables split their bills, move to the bar, join other tables and hand over to another server. A POS must handle each of those quickly and without mistakes.

Test the common cases: a table of six paying in three parts, a couple moving from the bar to a table with their drinks, two tables joining, a server going home and handing their tables to a colleague. Each should take seconds, and the kitchen tickets should follow the check when it moves.

These features are rarely shown in demos, and they are where many systems are weakest.

Closing a check should be quick: the bill presented, the payment recorded by its method, the check closed and the table freed. Any delay here keeps a table occupied after the guests want to leave, and holds back the next booking.

Look at how the POS records payments: cash, card on the venue's terminal, part payments and mixed methods. Look at how it handles a payment recorded wrongly, and how it shows what is still owed on a partly paid check.

A check that closes cleanly also makes the end of the night easier, because the takings match what the POS says.

On a shared screen, every member of staff should sign in as themselves, quickly, so their orders, voids and payments are recorded against their name. A four-digit code or a tap on a name is usually enough; long passwords on a busy till get shared, which defeats the point.

POS permissions decide who can do what: who can void a dish, comp a check, change a price or see the takings. Set them by role, so a new server cannot void a check by accident and a manager can do what a manager needs to do.

Check how permissions are set, how easy they are to change and whether they cover the actions that matter in your venue.

Voids and comps are part of every service: a dish entered by mistake, a dish sent back, a drink on the house for a regular. The POS should make them quick to do and easy to review later.

A void or comp with a reason is far more useful than one without. "Entered twice" and "guest unhappy with the steak" tell a manager very different things. A POS that asks for a reason, without making it a burden, builds a record that explains itself.

Review voids and comps each week, by reason and by member of staff. Patterns show where training or the menu needs attention.

The end of the night is where a POS proves itself to managers. Every check should be closed, every payment recorded and the takings by method should match what is in the drawer and what the card terminal says. Open checks, unrecorded payments or a payment recorded under the wrong method all turn a ten-minute close into an hour.

Look at how the POS shows what is still open, how it reports the day's takings by method and member of staff, and how a mistake found at close is corrected. A clean close every night makes the accounts easier every month.

The kitchen ticket is a POS feature, even though the kitchen never touches the till. What the POS sends decides what the cook sees: whether changes appear under their dish, whether allergies stand out and whether held courses are marked. A till that is quick for servers but sends unclear tickets to the kitchen moves the problem rather than solving it.

When testing a POS, look at the kitchen end as carefully as the front. Our guide to kitchen tickets that never need a shout covers what a good ticket shows.

Some features are used less often but still matter. POS reports are the main ones: sales by day and by hour, by payment method, by member of staff and by dish, along with voids, comps and discounts.

A manager should read a few reports each day and a few more each week. Most venues need far fewer reports than a system offers, but they need the important ones to be clear and quick to open.

Our guide to restaurant reporting: six reports, no more covers which ones are worth reading.

Menus change: new dishes, new prices, seasonal changes and, during service, dishes that run out. The POS should make planned changes easy for managers and the 86 easy for anyone on duty.

When a dish runs out, it should be marked sold out once and disappear from ordering everywhere at once: on the till, on any guest menu and on any boards. A dish that stays orderable after it has run out causes declined orders and disappointed guests.

Test it: 86 a dish on one till and check that it cannot be ordered anywhere else.

In many venues, the POS and the booking system are separate, so the server at the till knows nothing about the guest at the table: not their allergy, not that it is their birthday, not that they are a regular. A POS connected to the bookings and guest records can show that information where it is needed, and send a guest's allergy to the kitchen with their order.

Decide how much that matters to you. For a venue whose guests are mostly regulars, or where allergies are common, it matters a great deal. For a busy counter with few repeat guests, less so.

Many venues use more than one kind of device: a fixed screen at the bar, tablets on the floor, a phone for the manager. The POS should work the same way on each, so a check opened at the bar can be closed on the floor and staff do not have to learn two layouts.

Check how the system behaves on each device you plan to use, and whether two people can work on the same table at once without one overwriting the other.

Every POS has features that look impressive and are rarely used. Elaborate dashboards with dozens of charts. Reports nobody reads. Settings for situations the venue never faces. Modules bought because they were included, then left untouched.

That does not mean those features are worthless; some venues use them well. But they should not decide which system you choose. A system with a long list of rarely used features and a slow, awkward ordering screen is a worse choice than one with fewer features that does the daily work well.

When choosing a POS, separate the features your team will use every shift from the ones that would be nice to have, and weight them accordingly.

Every POS breaks sometimes: a device stops connecting, a payment records wrongly, a menu change does not appear. What matters then is how quickly you can get help. Ask when support is available, especially in the evenings and at weekends, how you reach it and how quickly problems are answered.

Ask other venues using the system about their experience. Support that answers within minutes on a busy night is worth more than a long list of features.

When choosing a POS, start from the short list: ordering speed, the table plan, modifiers, sending and firing, splitting and moving checks, payments, sign-in and permissions, voids and comps, a few clear reports and the 86. Score each system on those, with your own menu and your own staff.

Then consider the longer list, but only for features you can name a real use for. Our guide to choosing a POS: twelve questions, in order sets out the questions to ask.

Price matters too, over the whole first year, not only the monthly fee. Our guide to how much does a POS cost in the first year covers the full sum.

Staff turnover means the POS is learned again and again. A system that a new server can learn in one short session, and use confidently on their first shift, saves time every month. One that takes days to learn costs training time and causes mistakes on new starters' first nights.

During a trial, ask a member of staff who has never used the system to ring in a few orders without help. How quickly they manage it tells you a great deal about how easy the system will be for every new starter.

The best test of a POS is a real shift. Ask for a trial, set up your menu and your tables, and let your servers use it during a quiet service, then a busier one.

Ask the servers what slowed them down, what confused them and what they had to work around. Ask the kitchen whether the tickets were clear. Ask the manager whether the end-of-night figures made sense.

A system that survives a real shift with your team is worth more than one that impressed in a demo.

An invented bistro chooses a POS on the strength of its demo: a large set of reports, a loyalty module and a stock module. In service, ringing in an order takes many taps, splitting a check is awkward and servers type every change as a note. Within a month, the loyalty and stock modules are unused, and the servers have found workarounds for the ordering screen.

When the contract comes up for renewal, the bistro tests three systems in real shifts, scoring each on the short list. It chooses the one with the fastest ordering, the clearest tickets and the simplest splitting, even though it has fewer features in the brochure.

Within weeks, servers are faster, the kitchen's tickets are clearer and the manager reads three reports each morning instead of ignoring thirty.

In servearound, the point of sale runs in a browser on tablets and computers, and staff sign in on a shared screen with their name and a four-digit PIN. Checks open from the floor plan, dishes are rung in with their options, removals and notes, by seat if the server likes, and a round can be sent at once or held and fired later, with a sent dish re-fired as a remake without charging the guest again.

A line can be comped or voided with a reason, a check can be split by moving items onto a new one, merged with other open checks, handed to another member of staff or moved to another table with its kitchen tickets, and payments are recorded against the check by method, with cards taken on the venue's own terminal.

Roles are set module by module, with view, create, edit and delete for the point of sale, payments, menus and the rest. Order analytics show the average and median check, lines per check, what is ordered together and the void and comp rates, and payment analytics show takings by method, by hour and by member of staff, with voids and comps by member. See Order Fulfillment.

The ones used every shift: ordering speed, the table plan, modifiers, sending and firing, splitting checks, payments and sign-in.

Count the taps for typical and difficult orders, with your own menu, and watch real servers use it.

To decide who can void, comp, change prices or see takings, set by role so mistakes and misuse are harder.

A few each day, such as sales by hour and voids and comps, and a few more each week. Most systems offer far more than a venue needs.

They should. A void with a reason builds a record that explains itself and shows where training is needed.

It should be marked sold out once and disappear from ordering everywhere at once.

Only for ones you can name a real use for. Many are bought and never opened.

In a real shift, with your own menu and staff, and ask the servers and the kitchen what slowed them down.

The POS features that matter after the first week are the ones your team uses hundreds of times a day: ringing in orders quickly with their changes, a table plan that matches the room, sending, holding and firing, splitting and moving checks, recording payments, signing in quickly, permissions by role, voids and comps with reasons, a few clear reports and an 86 that works everywhere.

Judge a system by that short list, tested in a real shift with your own menu and staff, not by the length of the brochure. Pay for extra modules only when you can name a real use for them.