Restaurant waitlist

Move the guest from arrival to an available table.

LiftedPOS keeps the front-door queue connected to the live dining room. Staff can record the guest, party size, phone, notes, and quoted wait, move the visit through clear states, and seat the party against an available table.

WORKSPACE LENSOpen the restaurant floor and waitlist, add a safe test party, and seat it against the current table state.

LiftedPOS restaurant floor used to choose a live available table for waitlist seating
  1. 01Add the party
  2. 02Quote the wait
  3. 03Notify with evidence
  4. 04Seat an available table
Party context

Guest, party size, phone, notes, and quoted wait stay on one queue record.

Visible state

Waiting, Notified, Seated, Cancelled, and No Show make the next action readable.

Atomic seating

The party moves into a currently available table through one guarded action.

01

Capture enough context to recognize the party

Create the waitlist entry with guest name, party size, phone, notes, and a quoted wait. The team gets a shared front-door record instead of translating a paper list during a rush.

02

Give every guest a visible queue state

Waiting, Notified, Seated, Cancelled, and No Show keep the next action explicit. Staff can see the queue, average wait, seated guests, and no-shows while the dining room continues to change.

03

Attempt the notification from the same record

When configured messaging is available, staff can attempt an SMS notification and see a surfaced failure instead of assuming delivery. The Notified state records the operator workflow; it is not treated as proof that a carrier delivered the message.

04

Seat the party against a real available table

The seating action checks the current table and waitlist state together. Choosing an available table moves the guest into the dining-room workflow without leaving a second active version of the same party behind.

05

Rehearse the front-door procedure before opening

Use real table capacities, quoted-wait policy, notification configuration, seating authority, cancellation, no-show, and bussing steps in rollout. Staff should be able to recover when the desired table changed after the floor was first viewed.

Rehearse arrival, notification, seating, and recovery

Add test parties with different sizes and quoted waits, attempt a configured notification, surface a controlled failure, seat one party against an available table, and work a table-state conflict. Confirm the queue, floor, and party record agree after every action.

Inspect in the live demo

Open the restaurant floor and waitlist, add a safe test party, and seat it against the current table state. Availability can depend on enabled modules, hardware, payment setup, role, location, and rollout configuration.

Move from the feature to the operation

This capability shares customer, employee, product, location, transaction, and reporting context with the rest of LiftedPOS. The value is not a checked box. It is the handoff the operation no longer has to rebuild.

See the capability inside a working store.

Run it with safe demo data, then map the locations, roles, devices, and configuration your operation needs.