Restaurant POS workflows for hotel operations.

Keep table and counter tickets within the property

The local demo includes property-scoped tables with names and seat counts, plus table or counter tickets. Staff can select active catalog items and quantities for an open ticket and review its accepted line prices before settlement.

A seat count describes table capacity; it does not establish seat-by-seat ordering, floor plans or table reservations. Use the walkthrough to check whether this current ticket model matches the way your hotel serves food or records ancillary sales.

Follow kitchen progress at ticket level

An open ticket can move through NEW, PREPARING, READY and SERVED. This gives staff a simple order-level progress record within the current workflow.

These status changes are not kitchen order tickets, a station-based kitchen display system or printer routing. If your kitchen needs item-level preparation, separate stations or hardware delivery, retain those as explicit requirements for the planned restaurant expansion.

Distinguish a cash sale from a guest folio charge

The current POS supports staff-recorded CASH or FOLIO settlement. Cash is a staff-observed money record, not proof from a card terminal. Folio settlement posts a charge to the selected guest folio; it does not mean the guest has paid that charge.

Review the complete path from accepted ticket lines to the resulting record. Confirm the target folio and staff authority before posting, and inspect the guest balance afterward. Mixed tender, split or merged bills and live card-terminal integration are not included in this local-demo promise.

Review one cash session and aggregate catalog stock

A property has one open cash session in the current workflow. Its opening amount, expected balance, counted balance, difference and recorded reason help an authorized operator review the close. This is not a multi-register or independent-outlet cash model.

Catalog-item stock is consumed at settlement, and a full-order return restores the corresponding aggregate stock. This does not represent recipes, ingredient use, cooking waste, warehouse balances or purchasing. A restaurant's actual preparation and return rules need review before this model is used with real food operations.

Use a synthetic sale to evaluate fit

In an illustrative walkthrough, create a table ticket, add one sample catalog item and move the ticket through kitchen progress. Review one ticket settled as recorded cash and a separate ticket posted to a sample guest folio. Inspect the resulting cash or folio record and catalog stock movement.

Then review a full-order return and the cash-session close. Record what actually happened, the evidence and any unmet requirement. This is a suggested evaluation exercise, not a customer result, a production acceptance record or a claim that a new test passed.

• Confirm whether the business needs hotel-bound POS or independent restaurant provisioning.
• Separate ticket status from a requirement for KOT, KDS or kitchen printers.
• Check whether aggregate item stock fits the operation or ingredients and recipes are required.
• Keep cash collection, folio charging and later guest payment as distinct records.

Agree current scope before restaurant rollout

The confirmed offer on this page is the bounded AU-PMS local demonstration within hotel operations. Restaurant-only provisioning, independent outlets/registers, split billing, ingredient purchasing, offline selling, restaurant QR ordering and delivery-aggregator connections are not confirmed current capabilities.

The broader restaurant platform remains planned. Share the hotel setup, service pattern, cash process and required kitchen connections when requesting an AU-PMS walkthrough. Any live rollout requires reviewed property policies, data, access and operating acceptance; no fixed restaurant price or delivery date is promised here.

Questions to work through.