Order terminal (POS)

Captures the order, prices it, and turns it into both a ticket the bar can act on and a record the business can count.

Two different things get called the terminal and they fail differently. One is an input device on the counter: a screen, a button tree and a modifier structure, judged only by how few actions a common drink takes and how honestly it represents that drink. The other is a record-keeping system: the sale is composed somewhere, written somewhere, and dispatched to whatever prints or displays it. Where that composition happens is the architecture question worth asking — a terminal that cannot assemble and hold an order without a live connection stops taking money the moment the connection stops, and connections in a fitted-out venue drop for reasons nobody predicted at design stage. Card payment is normally a separate certified device on its own path: the terminal sends an amount and receives an approval, and does not handle the card data itself, which is why the payment side and the ordering side are two procurement decisions and not one.

• Find the real bottleneck before you buy anything that speeds up the front end. If drinks, not orders, are the constraint, every pound spent on faster order capture buys you a longer visible wait and a more frustrated queue. Watch a peak and count where the time actually goes: a bar that cannot make drinks faster does not need a faster till.
• Count staffed ordering positions at peak, not counter length. A second terminal only earns its space if a second person is genuinely standing there taking orders at the same time. A terminal nobody stands at takes no orders, occupies the most valuable counter run in the venue, and still has to be cleaned.
• Test the offline behaviour with the network actually pulled, not described to you in a meeting. Ask three specific things: what happens to an order half-composed when it drops, what happens to the tickets queued behind it, and what the day's totals look like when the connection returns. An answer that is vague on any of the three is an answer.
• Judge the menu build, not the hardware. Take your three most-ordered drinks with their usual modifiers and count the actions each takes on the layout you would actually deploy. Vendors demonstrate a clean menu with a handful of items; your menu is not that, and the difference lands entirely on the cashier during the rush.
• Modifier structure decides whether the ticket the bar receives can be trusted. If a substitution has to be typed as free text, the bar reads prose under pressure and guesses at it. Structured modifiers also make the sales data usable afterwards — you cannot count how many oat-milk drinks you sell if oat milk is a comment.
• Allergen flags must be a structured field, and this is not a preference. Anything the barista has to read out of a comment box will eventually be missed during a rush, and it is the single field where a miss is a safety incident rather than a service one. Check how the flag travels all the way to the display or the ticket, not just how it looks at the till.
• Ask who owns the data and how you get it out, in writing, before signing anything. An operator who cannot export sales by item cannot run menu engineering, cannot cost a recipe against the actual sales mix, and cannot hold a supplier to a claim. Reporting inside the vendor's own dashboard is not the same as having your data.
• Confirm the power route and the network route at fit-out, with the joinery, not after delivery. A terminal, its printer and its drawer are a small load but the one you least want to lose mid-service; whether they belong on a protected or separate circuit is a question for a licensed electrician and the local authority, and it is far cheaper to ask before the counter is built than after.