POS 16 September 2025 3 min read

What a POS actually decides in a service

It is not the payment. It is the order of the tickets, the table state and what the kitchen sees first.

POS selection is usually run as a comparison of features and payment integrations. That comparison rarely predicts which system a branch will be happy with a year later, because the payment step is the part of a POS that almost never goes wrong.

Short on time

Test order flow

Modifiers and kitchen dispatch timing shape the shift.

Check awkward cases

Test late changes and offline behaviour before adopting a system.

Tie state to the record

Table or order state should match what the team sees in POS.

Judge a real service

A feature tour alone will not show how the system behaves in a busy branch.

The decisions that shape the service

During a busy hour a POS makes a continuous series of small decisions that nobody put on a requirements list, and those decisions determine how the service feels.

WHAT IT IS DECIDING WHILE YOU ARE BUSY

Ticket orderWhich ticket the kitchen sees first, and whether a large table’s items are held together or fired as entered.

Course timingWhen the second course is released, and whether that is automatic or somebody’s job.

Table stateWhether a table is occupied, paying or free, and how quickly that reaches the host.

Modifier handlingHow a change made after firing reaches a station that has already started.

RecoveryWhat happens when a terminal drops mid-order, which is the only test that matters.

Why the demonstration will not show you this

Every POS is fast with one order on the screen.

A demonstration runs at zero load with a clean menu and an expert operating it. None of the decisions above are visible under those conditions. They become visible at forty covers with a modifier-heavy menu and a member of staff who started last week.

How to test it properly

Bring your own menu

Your real one, with the awkward items and the modifiers that cause arguments.

Have a new starter drive it

Not the vendor, and not your best supervisor. The learning curve is the product.

Run a split bill and a late modifier

Two things that happen constantly and expose the design immediately.

Pull the network cable

What the terminal does offline, and what it does when it reconnects.

The question underneath all of it

A POS is the place where a service is recorded as it happens. Everything downstream — cost of goods, labour against sales, a claim against a delivery channel, a compliance record — inherits the quality of that recording. Chosen that way, the payment integration is a checkbox and the ticket logic is the decision.

PUT YOUR OWN NUMBERS IN