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.

The boundary between the guest and the bar, and therefore the thing that decides where the queue stands. Site it so the ordering queue and the collection point do not merge into one crowd — a guest waiting to pay and a guest waiting for a drink standing in the same place is how both start asking the barista questions. In the movement triangle the workflow article describes, the terminal is the third point: it must be reachable in a step from the machine when one person is running the whole bar, and out of the barista's path entirely when two people are.

  • Buying a faster front end to fix a bar-side bottleneck, which converts a visible queue into an invisible one and changes nothing the guest experiences.
  • Letting the menu be built by whoever installs the system rather than by whoever works the counter at peak.
  • Accepting free-text modifiers because they are quicker to configure, and paying for it on every ticket afterwards.
  • Shared logins, which cost nothing until the first variance and then cost the ability to investigate any of them.
  • Treating the terminal as exempt from the cleaning routine because it is electronic. It is the single most hand-contacted surface on a bar that also handles open cups.
  • Discovering at commissioning that the counter has no cable route, and solving it with a trailing lead across a wet floor.
  • The terminal, its printer and its drawer draw a small continuous load, but it is the load whose loss stops trading. Whether they sit on a protected or separate circuit, and whether the site warrants an uninterruptible supply behind them, depends on the equipment selected and the supply available — a licensed electrician must confirm it and the local authority governs. This site does not specify amperages.
  • Plan the terminal, its printer and its drawer as one counter run rather than three objects found space for. The cable route between them is part of that run and is a joinery decision made at fit-out.
  • The cashier must be able to reach the screen and the drawer without stepping back into the barista's working path, and the screen must be readable at the angle the cashier actually stands at rather than the angle it was mounted at.
  • This screen lives in the steamiest, wettest corner of a room that also handles milk and syrup. Splash, condensation and hand contact are constant, and a unit with seams that trap milk becomes a cleaning problem that never goes away.
  • Fixed counter till
  • A purpose-built unit anchored to the counter, usually with its printer and drawer as one installed assembly.
  • Hardest to knock over, easiest to keep sealed against milk and steam, and it fixes where the queue forms. That last point is the real one: an anchored till is a floor-plan decision, and it cannot be moved later to shorten a queue that formed in the wrong place.
  • Tablet terminal
  • A consumer tablet running the ordering software, held by a mount and paired with separate peripherals.
  • Cheap to add a second one, which is genuinely useful. The cost is that a consumer device now sits on a commercial bar: battery, forced updates, mounting and replacement cycles all become the operator's problem, and the mount stops being an accessory and becomes part of the specification.
  • Handheld / line-busting
  • A pocket-sized terminal carried down the queue so the order is taken away from the counter.
  • Orders enter the bar earlier, so production starts before payment finishes. This only pays where order entry is genuinely the bottleneck. Where the bar is the bottleneck — which is the usual case — line-busting makes the queue invisible without making it shorter, and the guest waits the same time with less to look at.
  • Self-order kiosk
  • A guest-facing screen that takes the order directly, with staff only handling payment exceptions and handover.
  • Moves order entry to the guest and removes the conversation, along with the upsell and the allergen question that a trained cashier asks out loud. It also shifts labour rather than removing it: the bar now receives orders faster than a cashier would have fed them, and if the bar was already the constraint the kiosk simply exposes that.
  • Orders are being verbally corrected or re-keyed at the bar rather than read off the ticket.
  • The modifier structure does not match how the menu is actually ordered, so cashiers are working around it with free text and speech.
  • Seconds on every ticket at exactly the wrong time, plus the remakes that follow a misheard correction. It also silently destroys the sales data you would use to fix the menu.
  • The queue stalls whenever the connection blips, even briefly.
  • Order composition depends on a live link rather than being assembled locally and queued for sync.
  • Straight downtime — the bar cannot take money, and it will happen during the hour that matters, because that is the hour everything else is loaded too.
  • Cashiers mis-tap, or wipe their fingers before touching the screen.
  • A screen sited under a light that glares, or one that needs a dry precise fingertip on a bar where hands are wet.
  • Slow order entry and wrong buttons, both of which read to the guest as an inattentive bar rather than a badly sited screen.
  • End-of-day totals never quite reconcile and nobody can say whose shift the difference belongs to.
  • A shared login, so every action on the terminal belongs to everyone.
  • Money, and worse than the money: a variance you cannot investigate becomes a variance you stop investigating.

Related tools

Cleaning and care

Related articles

Equipment, workflow & commissioning

العربية