A restaurant waitlist check-in is the short service decision between an active wait and a confirmed table. It verifies that the group is here, connects the host with the current floor signal, and prevents a guest from repeating their story to every person at the stand.
It is not a second intake form. The party has already entered the queue and received a current status. Check-in protects that record while the restaurant decides whether a compatible table is truly ready.
Treat check-in as arrival confirmation, not a new queue entry
Start by finding the active party in the shared queue. Confirm a minimal identifier, the number of guests present, and any detail that affects the next seating decision. A host does not need to collect a fresh phone number, replay a message history, or ask the guest to scan another code.
This distinction matters when a party joined by a link or QR code and later comes to the door. The arrival changes the party’s service state. It does not give the party a second position or a different promise. The multiple waitlist entry points guide covers how requests become one active queue before that point.
Use the host stand opening checklist before service to agree on the labels your team will use. If one host calls a party “checked in” while another uses the label only after a table is assigned, the queue becomes hard to read precisely when the room gets busy.
Run five checks at the host stand
The same compact sequence works better than a long script. It lets staff help a guest without guessing at capacity.
- Locate the active party. Match the group to the current record before changing anything. If two records may describe the same visit, pause and resolve the duplicate in the authorized queue rather than adding another line.
- Confirm what is true now. Note who is present, the current party size, and a service-relevant seating need only if it changes the next decision. Do not ask a guest to disclose more personal information to prove they are waiting.
- Mark arrival in the current record. Record the arrival state and time where the next host can see it. Keep the original quoted range and promised update visible, because they remain part of the restaurant’s commitment.
- Ask for a floor signal, not a prediction. A table is ready only when the floor confirms it is clean, compatible, and not needed for a protected reservation or another documented use. “It should be soon” is not a seating signal.
- Give one next step. Seat the party, tell them where to wait, or state who is checking the exception and when they will return with an answer. The waitlist status update policy helps teams keep that promise current.
| Check-in situation | Record the operational fact | Owner of the next decision | What the guest needs to hear |
|---|---|---|---|
| The whole party arrives | Arrival confirmed and current size | Host | Whether the floor has a confirmed table signal |
| Part of the party is still arriving | Current attendance and house rule that applies | Host or manager | What must happen before seating can proceed |
| The original table is no longer compatible | Constraint and the time the floor was asked | Floor lead | When a compatible option will be reviewed |
| A table is ready | Confirmed table and service state | Host | Where to go and any documented arrival step |
| An exception needs approval | Question, named decision owner, next review point | Manager or floor lead | That the request is being decided, not ignored |
Do not turn a check-in into a private side conversation
The fastest workaround during a rush is often the least reliable: a host writes a name on a personal phone, takes a photo of a paper list, or leaves the exception in a staff chat. Those copies make it unclear which record is current and can keep personal information longer than the service needs it.
Keep the active visit in the approved workflow and record only what helps the next decision. The NIST Privacy Framework is a useful reference for thinking about governed, minimized information. Local requirements and the restaurant’s approved process still determine what should be collected and retained.
The same principle applies to an accessible arrival. A guest who cannot use a QR code, cannot stand in one place, or prefers a staffed explanation still needs a clear route into the same live queue. The accessible restaurant waitlist guide explains how to offer that route without creating an invisible second line. W3C’s WCAG 2.2 is a practical reference for clear instructions and usable digital controls; it does not replace an operational service policy.
Assign exceptions before the guest reaches the table
Check-in exposes decisions that the normal flow cannot answer alone. The party may have changed size, a compatible table may have been reassigned, an accessible option may need review, or a late reservation may still protect capacity. These are not reasons to leave the party in a vague holding state.
Name the person who can decide, record when that person will review the case, and preserve the original queue state until an approved decision changes it. When a reservation is involved, use the restaurant’s documented arrival and release rule. The late-arrival policy guide is about that separate capacity decision, not a reason to make a walk-in wait without an explanation.
At a shift change, the incoming host should immediately see which checked-in party is waiting on the floor and who owns the exception. The waitlist shift handoff checklist gives the team a practical review around those open promises.
Make the final handoff explicit
A check-in ends when the group has a confirmed table, a documented next review, or a clear outcome under the restaurant’s policy. It does not end merely because someone greeted the guest. Review a few check-ins after a busy service: did the queue show arrival? Did the floor signal arrive? Did the guest know the next step? The answers reveal whether the process needs a clearer owner, not a longer script.
If the restaurant needs a shared live view, StoveOps supports a restaurant-owned waitlist where guests can join from a phone by QR code or link and receive table-ready updates by SMS, WhatsApp, or email. It runs alongside the POS or checkout stack the restaurant already uses. Compare that workflow with your service rules on the restaurant waitlist software page.