Restaurant floor and table management
Give front-of-house staff a live service map
LiftedPOS table records and the floor map keep table, capacity, position, and service state visible from seating through clearing. A connected waitlist carries the arrival-to-seating handoff into the same operation. During rollout, test concurrent staff activity, active or paid checks, permissioned floor changes, and service types that do not use a table.
Keep the detailed request on the source order and make the kitchen handoff explicit
The source order can retain configured modifiers and server-authoritative price deltas plus seats, courses, and kitchen notes. The production team sees ticket identity and state on its configured station view, then follows the restaurant's procedure for richer detail. Build modifier groups, defaults, prices, recipes, stations, tax, and availability from the real menu; notes support staff procedure but cannot replace allergen and cross-contact controls.
Route the right work to the right kitchen display
Configured item lines can route to kitchen, bar, grill, bakery, cold, expo, or another station; an unassigned item falls back to the default board. Tickets advance from new to in progress, ready, and completed. Paid-sale recall and forward-only pre-payment or QR work are different paths, so test counter, table, QR, correction, simultaneous-update, station, and expo scenarios before launch.
KITCHEN SAFETY BOUNDARY
Visibility supports procedure; it does not replace it.LiftedPOS can preserve restaurant detail on the source order and display station-aware production state on the kitchen board. The restaurant remains responsible for confirming instructions, recipe accuracy, allergen policy, cross-contact controls, food-safety practice, equipment, staffing, and local requirements.
Let table QR orders enter a controlled staff queue
An authenticated operator can create a table-specific QR destination on the merchant's {company}.liftedpos.com subdomain. The guest builds a cart from the configured menu; the server resolves products, tax, and stored money values. The result is a server-priced pending order for staff review. An authenticated employee accepts or rejects it, the accepted order can move to the kitchen display, and payment is completed at the POS through the restaurant's configured staff procedure.
Connect recipes and component inventory to what was sold
A configured recipe connects the sold menu item to component quantities. Suppliers, purchase orders, receiving, counts, transfers, and low-stock visibility support the wider inventory workflow. Prove yields, units, modifiers, waste, voids, refunds, substitutions, receiving, and physical-count reconciliation with actual menu examples before relying on food-cost results.
Keep employees, permissions, cash, and reports in the close
Roles and permissions can separate discounts, refunds, drawer work, reporting, table changes, and payment operations. Register sessions retain opening cash, cash sales, refunds, paid-ins, drops, closing count, expected cash, and variance so the physical drawer can be compared with the transaction record.
When connectivity is lost, the documented LiftedPOS continuity path is cash only. A locally queued cash sale remains pending until server validation accepts and books its inventory, reporting, receipt, and drawer consequences. Restaurants define who owns retry and reconciliation and how the guest is informed during that interval.
Ring a realistic order, route it, tender it, and find the same event in transaction, drawer, inventory, employee, customer, and report views.
Use LiftedConnect for supported PAX payment context
LiftedConnect is the payment companion being qualified for supported LiftedPOS PAX A920 and A920 Pro deployments. Its verified on-device engine runs alongside BroadPOS through PAX POSLink 2 and excludes raw cardholder data from the allowlisted result. Raw cardholder data does not belong in LiftedPOS. The production backend handoff that connects a restaurant sale to that safe result must be enabled and proven before merchant use.
For a supported credit MID, processor tokenization is opt-in and defaults off. When the merchant and host support it, the engine can request a processor-issued token. Retaining that surrogate with the LiftedPOS transaction still requires the production backend handoff to be enabled and proven.
That qualified thread is the intended token foundation for future refunds and cards on file. Processor, MID, merchant configuration, host support, backend implementation, access control, and rollout determine what is enabled. Prove the real terminal, recovery, void, return, local preauthorization ledger, any separately integrated processor-backed hold, tip, and closeout path before launch.