Restaurant Waitlist and No-Show Management
Design a host workspace and guest status flow for realistic wait estimates, arrival check-in, table readiness, and no-show handling.
The brief
Understand the problem
Background
Restaurant wait estimates shift with meal duration, table combinations, party size, late arrivals, and accessibility needs. Aggressive reminders can create stress, while vague status leaves tables idle.
User context
Mina hosts a busy neighborhood restaurant with a twenty-party waitlist. A table for six is nearly ready, two smaller parties are late, and one guest requested space for a wheelchair.
Product problem
Mina needs to seat fairly and use capacity well while guests need understandable estimates, check-in options, and transparent no-show rules.
Objective
Create staff queue, guest status, table assignment, and late-arrival resolution for an evening waitlist.
What to design
Define the experience
Required experience
- Add a party with seating and contact needs
- Prioritize the live queue using transparent operational context
- Notify and check in a party when a suitable table is ready
- Handle late, partial, canceled, and no-show arrivals
Screens and states
- Host waitlist
- Guest wait status
- Table assignment
- Late-arrival and no-show resolution
Core user flow
Follow the critical path
- 01
Mina adds a party of three with a wheelchair space request
- 02
The guest receives a range and chooses text updates
- 03
A compatible table becomes ready and the party checks in from outside
- 04
Another party misses its grace period, so Mina records a no-show and releases the table
Product rules
Requirements and constraints
Requirements
- Show estimate ranges and when they last changed
- Keep party size, arrival, seating needs, owner, and contact status visible
- Match tables using capacity and access requirements
- State grace periods and no-show consequences before joining
- Synchronize staff actions and guest messages
Constraints
- Wait time remains an estimate, not a reservation
- Accessibility needs must not be exposed to other guests
- Hosts need a usable fallback when guest messaging fails
Reality check
States worth considering
Ready-to-use content
Mock data
Use this content to test hierarchy and realistic data states. You can expand it when the concept needs more depth.
Live waitlist
- Party of 2: 18 to 25 minutes
- Party of 6: table nearly ready
- Party of 3: wheelchair space required, 12 minutes waiting
- Party of 4: notified 7 minutes ago
Finish line
What to deliver
- Three tablet host screens and one mobile guest status screen
- A queue state model for waiting, notified, checked in, seating, delayed, canceled, and no-show
If you want more
Optional extensions
Optional direction
Visual resources
Use these as a starting constraint if you want one. They are not part of the required solution.