Waitlist and Table Management

On a Friday at half past seven the host is holding a clipboard, a wax pencil and about nine pieces of information that exist nowhere else. Four names waiting, two of whom have wandered off, a party of six who said they would be ten minutes and have not arrived, a two-top that is about to leave and a queue at the door being quoted a wait time that is a guess. The clipboard is the single source of truth and it is attached to one person who cannot leave the door, cannot answer the phone, and cannot look up to see that table 14 has just paid.

The money leaks in three directions. First, walk-aways. A guest told forty-five minutes with no way to go and do something else leaves, and leaves irritated enough to tell people. They were revenue standing in your doorway. Second, dead table minutes. The gap between a table clearing and the next party sitting down is the most expensive unoccupied space in the building, and on a busy night the host simply cannot see it fast enough - they are facing the door, not the floor. Ten minutes of dead time across twenty turns is two hours of a table you never sold.

Third, the phone. While the host manages the queue, the phone rings with people asking whether there is a table tonight. Those calls are either unanswered, which is a lost cover, or answered badly, which costs the host attention they owe to the people in front of them. And the whole night leaves no record: no idea how long the quoted wait actually was versus the real one, how many parties walked, which nights the no-show rate spikes, or who those walk-ins were so you could ever invite them back. The clipboard gets wiped and the information is gone.

Pipeline and stages

Two pipelines. The first, Tonight's Waitlist, is a live board displayed on a tablet at the host stand and on a phone in the manager's pocket. It replaces the clipboard entirely, and the stages are deliberately the physical states a party can be in:

• Inquiry - someone has asked about a table but is not yet on the list. Phone and web inquiries land here.
• Waiting - on the list, quoted a time, holding a place. The host's main column.
• Table Ready - the host has a table and has released the party. Dwell here should be seconds.
• Notified - the text has gone, the clock on their grace period is running.
• Seated - at a table, with table_number recorded.
• Walked Away - left before being seated, with a reason.
• No Show - notified, grace period expired, did not appear.
• Completed - left after dining; the record moves out of tonight's board and into history.

The second, Future Waitlist, holds parties who wanted a date that was full. Stages: Date Requested, On Standby, Space Offered, Converted, Expired. This is where cancellations get resold.

Calendars

• Service Periods - not a booking calendar but a configuration calendar defining lunch, dinner, late and the last seating time per day. Every wait quote and every standby offer reads from it, so changing Sunday's last seating is one edit rather than a hunt through message copy.
• Reservations - if you take bookings as well as walk-ins, the existing reservation calendar is connected read-only so the waitlist knows which tables are already committed. Turn times per party size are configured here: a two-top at 90 minutes, a four-top at 105, a party of six or more at 135, adjusted to your own observed averages.
• Standby Offers - short windows the manager opens when a cancellation lands, used by the Future Waitlist offer workflow.

Custom fields

• party_name, party_size, mobile.
• waitlist_source - door, web widget, QR code at the door, phone, walk-past.
• waitlist_joined_at, quoted_wait_minutes, promise_time - the actual clock time the guest was told.
• table_ready_at, notified_at, seated_at, actual_wait_minutes, table_number.
• seating_preference - any table, booth, bar, high top, outside, quiet. Also bar_acceptable as a simple yes or no, because it is the single most useful field on a busy night.
• occasion - birthday, anniversary, business, none. Free-text party_notes.
• accessibility_needs and allergy_notes - captured at join, passed to the floor before the party sits.
• repeat_visit_count, last_visit_date.
• walkaway_reason - wait too long, went elsewhere, changed plans, no reason given.
• no_show_count - carried on the contact, not the visit, so a pattern is visible.
• service_period and day_part for reporting.
• Future waitlist only: requested_date, requested_time_window, date_flexibility, standby_offer_sent_at.

Tags

• State: waitlist-active, table-ready, notified-once, notified-twice, seated, walked-away, no-show.
• Source: joined-at-door, joined-remote, joined-by-phone, joined-by-qr.
• Party shape: large-party, bar-ok, outside-only, flexible-seating, needs-accessible-table, allergy-flag.
• Relationship: regular, first-visit, vip, celebrating, repeat-no-show.
• Standby: standby-list, standby-offered, standby-converted.
• Compliance: sms-opt-in, sms-opted-out.

Forms

• Join the Waitlist. Four fields and nothing else: name, party size, mobile, and whether the bar counts as a table. Reachable from a QR code on an A-board at the door, from the website, and from a link BO texts to phone callers. A guest should be able to join from the pavement in twenty seconds without talking to anyone.
• Host Quick Add. The same form in a single-screen layout for the host stand tablet, with party size as large tap targets and the mobile field keyboard set to numeric. Speed at the stand is the whole game.
• Preferences and Notes. Optional second step, sent by text after joining: occasion, allergies, accessibility, seating preference. Guests fill this in while they wait, which is exactly when they have time, and the kitchen gets allergy information before the party is seated rather than after.
• Future Date Waitlist. For the nights you are full: date, time window, party size, flexibility, mobile. Feeds the standby pipeline.
• Quick Rating. One question by text the morning after, used to catch a party whose wait was badly misquoted and to build the regulars list.

BO's role and guardrails

BO takes the phone and the web off the host's hands and handles the waiting guest's questions. BO may:

• Answer the phone during service, state the current quoted wait for the caller's party size, and add them to the list - reading the quote from the live board rather than guessing.
• Answer web chat and QR arrivals, collect the four fields, and confirm their place with a position in the queue.
• Answer the two questions waiting guests always ask - how much longer, and can we sit at the bar - from the live board.
• Handle a party replying that they need ten more minutes, and push their position back accordingly rather than dropping them.
• Take a party off the list on request, record walkaway_reason, and thank them without guilt-tripping.
• Offer the Future Date Waitlist form when the night is genuinely full.

BO must not:

• Promise a specific table, a specific time, or a guaranteed wait. BO gives the current estimate and says it is an estimate.
• Seat anyone, or tell a guest a table is ready. Only the host releases a table - the notification fires from a human action, every time.
• Reorder the queue, skip a party, or decide who gets the booth. Sequencing is a floor decision made by someone who can see the room.
• Take a deposit, quote a price, or discuss a minimum spend.
• Argue with a guest about a wait time. Any complaint, any mention of a previous bad experience, and anything involving an allergy or a medical need goes straight to the duty manager.

Numbers and channels

• A front-of-house number, SMS-enabled, that is the same number printed on the door sign, the website and the QR landing page. Guests reply to it and the replies land in the shared conversation view visible at the host stand.
• Voice routing on that number during service: BO answers on the first ring, handles waitlist and opening-hours questions, and transfers anything else - large party inquiries, complaints, lost property - to the manager's mobile. Outside service hours BO takes a message and offers the future waitlist form.
• A QR code at the door and on the pavement board pointing at Join the Waitlist, which is what lets a queue form without a queue.
• The host stand tablet showing the Tonight's Waitlist board, sorted by waitlist_joined_at with party size and bar_acceptable visible at a glance.
• A manager's mobile view of the same board, so the person on the floor who can see table 14 paying can release it without walking to the door.

A party of four on a Saturday at 7:40pm, from the pavement to the morning after.

1. They arrive at the door. There is a queue of two groups ahead of them and an A-board with a QR code. Rather than queue to speak to the host, they scan it.
2. Join the Waitlist loads on the phone of whoever scanned. Four fields: name, four people, mobile, and yes the bar is fine. Submitted in under twenty seconds.
3. The contact is created or matched on mobile. waitlist_joined_at is stamped, waitlist_source set to QR, party_size to four, bar_acceptable to yes. Tags waitlist-active, joined-by-qr and bar-ok are applied. Because they have been in twice before, repeat_visit_count reads 2 and regular is applied.
4. The quote is calculated from the live board: the number of parties of a comparable size ahead of them, the turn time for a four-top, and the manager's current pace adjustment. It comes back as 35 minutes. quoted_wait_minutes and promise_time are stamped, and the confirmation text goes out: their position, the estimate, the fact that the bar is an option, and the instruction to reply if plans change.
5. The lead appears on the host stand tablet in Waiting, with the party size, the bar-ok flag and the regular tag visible without tapping anything. The host has not spoken to them and does not need to.
6. Two minutes later a follow-up text offers the optional Preferences and Notes form. They fill it in while standing outside: it is a birthday, and one of them cannot eat shellfish. occasion, allergy_notes and the allergy-flag and celebrating tags are set, and the kitchen and the section server see the allergy note before the party sits rather than after they have ordered.
7. They go for a drink two doors down, which is the entire point. At 18 minutes the courtesy update fires: a short text saying they are still on track, roughly fifteen minutes to go.
8. At 7:58 the manager, standing on the floor, sees table 11 settle the bill. He opens the board on his phone and moves the party to Table Ready. Nobody had to walk to the host stand.
9. That stage change immediately sends the ready text - "Your table is ready. Come to the host stand and ask for Nadia. We will hold it for 10 minutes." - stamps table_ready_at and notified_at, moves the lead to Notified, applies notified-once, and starts the grace clock. The host stand tablet shows the party in amber with a countdown.
10. They reply "on our way". The reply is logged, the countdown pauses for three minutes, and the host can see they are coming rather than wondering.
11. They arrive at 8:01. The host taps seated, records table 11, and the lead moves to Seated. seated_at is stamped and actual_wait_minutes is calculated at 21 against a quote of 35 - a quote that was pessimistic, which is the right direction to be wrong in, and which the reporting will show if it becomes a habit.
12. Because celebrating is set, a task fires to the section server about the birthday, and because allergy-flag is set, the kitchen printout carries the shellfish note.
13. At 9:45 the server closes the table. The lead moves to Completed, drops off tonight's board, and last_visit_date and repeat_visit_count are updated on the contact.
14. At 11am the next day a single-question Quick Rating text goes out. They rate it highly, which puts them into the review routing step; had they rated the wait poorly, the manager would have had it in front of him before lunch service with the quoted-versus-actual wait attached.

Two other paths run off the same board. If they had never arrived after the ready text, a second notification would have fired at 5 minutes, the grace period would have expired at 10, the lead would have moved to No Show, no_show_count on the contact would have incremented, and the table would have been released back to the host instantly rather than held on faith. And if at 7:40 the night had been genuinely full with a 90-minute wait, BO would have offered the Future Date Waitlist instead - putting them on standby for next Saturday, which is where the following week's cancellation gets resold.

Seven workflows. Everything here runs in minutes rather than days, which is the main difference between this build and a normal sales automation - a wait duration that is five minutes late is a guest at the door asking the host why nobody texted them.

1. Waitlist Join and Quote

Trigger: submission of Join the Waitlist or Host Quick Add.

Conditions: if the current time is outside the Service Periods window, or past last seating, do not join them to tonight's list - route to workflow 7 instead.

Actions in order:

1. Create or match the contact on mobile. Write party_name, party_size, bar_acceptable, waitlist_source, service_period, and stamp waitlist_joined_at.
2. Increment repeat_visit_count. If 1, apply first-visit; if 3 or more, apply regular. If no_show_count is 2 or more, apply repeat-no-show and flag it on the board for the host - not to refuse them, but so the host knows to confirm by voice.
3. Apply waitlist-active plus the source tag, and large-party if party_size is 6 or more. Large parties bypass the automatic quote and go to the host for a manual one.
4. Calculate the quote: count parties in Waiting and Notified whose party_size fits the same table class, multiply by the configured turn time for that class, divide by the number of tables in that class, and add the manager's current pace adjustment. Round up to the nearest 5 minutes. Always round up.
5. Write quoted_wait_minutes and promise_time, and create the lead in Waiting.
6. Send the confirmation SMS immediately: "You are on the list - party of 4, roughly 35 minutes, so around 8:15. You are third in the queue. The bar has space if you would rather wait with a drink. Reply CHANGE if your numbers change, or CANCEL to come off the list."
7. Wait 2 minutes. Send the Preferences and Notes link: "While you wait - anything we should know? Allergies, a birthday, a table you would prefer. Takes 20 seconds: [link]"
8. If party_size is 6 or more, notify the host instead of quoting, because a large party quote depends on whether tables can be joined and only a human knows that.

Exit: runs once per join.

2. Waiting Guest Updates

Trigger: lead enters Waiting.

Actions:

1. Wait until 50 percent of quoted_wait_minutes has elapsed. Check whether the lead is still in Waiting; if not, exit.
2. Recalculate the estimate from the current board. If the new estimate is within 10 minutes of the original, send the reassurance version: "Still on track - about 15 minutes to go." If it has slipped by more than 10 minutes, send the honest version instead: "Running a little behind - realistically another 25 minutes. Sorry about that. Reply CANCEL any time and there are no hard feelings." Offering the exit is what keeps the review good even when the wait is bad.
3. Wait until promise_time passes with the lead still in Waiting. Send one apology update with a revised estimate, and notify the host that a promise has been missed so they can look the party in the eye about it.
4. Wait a further 15 minutes past promise_time. Notify the floor manager, not the host - at this point it is a pacing problem rather than a door problem.

Exit: the lead leaving Waiting for any reason.

3. Table Ready Notification and Grace Clock

Trigger: a human moves a lead to Table Ready. This trigger is never automatic. No system should tell a guest their table is ready on the strength of a POS event.

Actions:

1. Stamp table_ready_at and notified_at, move to Notified, apply notified-once.
2. Send immediately: "Your table is ready. Come to the host stand and ask for Nadia. We will hold it for 10 minutes." Name the person, give the deadline, keep it to two lines.
3. Calculate actual_wait_minutes from waitlist_joined_at to table_ready_at.
4. Wait 5 minutes. If still in Notified, send the second nudge: "Still holding your table - we can give it another 5 minutes." Apply notified-twice.
5. Wait 5 minutes. If still in Notified, move to No Show, apply no-show, increment no_show_count on the contact, and notify the host that the table is released. Send the guest one courteous close: "We had to release the table, sorry - the queue was moving. Come back in and we will get you on the list again." Never scold.
6. If the guest replies with anything indicating they are on their way, pause the grace clock for 3 minutes, log the reply on the board, and notify the host so the table is not released under someone walking through the door.

Exit: moved to Seated by a human, or the grace period expiring.

4. Inbound Reply Handling

Trigger: any inbound SMS or web chat message from a contact with an active waitlist lead.

Branches:

1. CANCEL, or any phrasing meaning they are leaving. Move to Walked Away, set walkaway_reason from the message or to no reason given, remove waitlist-active, notify the host so the queue re-quotes, and reply: "No problem at all - taken you off the list. Hope to see you another time." Then fire the standby offer in workflow 7 if they mentioned a future date.
2. CHANGE, or a new number of people. BO confirms the new party_size, recalculates the quote, rewrites quoted_wait_minutes and promise_time, and tells them the revised estimate. If the new size is 6 or more, hand to the host.
3. How long, how much longer, any variant. BO answers from the live board with the current recalculated estimate and their queue position. No apology padding, just the number.
4. Running late, need more time. BO moves them back one position in the effective order, confirms the new estimate, and notifies the host. The guest keeps their place rather than losing it.
5. Complaint, previous bad experience, allergy or medical mention, or an aggressive tone. BO does not reply with substance. Acknowledge in one line, flag the thread, and notify the duty manager immediately with the conversation attached.
6. STOP, UNSUBSCRIBE. Apply sms-opted-out, suppress every message, and flag the board entry so the host knows this party must be called to or found in person. A silently un-notifiable party on a waitlist is a guaranteed complaint.

Exit: each inbound message handled once.

5. Seating, Floor Notes and Table Close

Trigger: a human moves a lead to Seated.

Actions:

1. Stamp seated_at, record table_number, recalculate actual_wait_minutes from join to seated, remove waitlist-active, apply seated.
2. If allergy-flag is present, push the allergy_notes text to the kitchen channel and to the section server, with the table number. This is the step that has to be reliable - if it is not, do not collect allergy data at all.
3. If needs-accessible-table is present, notify the host before the walk to the table rather than after.
4. If celebrating is present, notify the section server with the occasion and any name detail.
5. If regular or vip is present, send the server a one-line history: visit count, last visit date, and anything in party_notes worth knowing.
6. Wait until the table is closed, either by a human marking it or a POS check-closed event. Move to Completed, update last_visit_date, and remove the lead from tonight's board.

Exit: table completed.

6. Morning-After Rating

Trigger: lead enters Completed.

Conditions: requires sms-opt-in. Excludes anyone who was a no-show or walked-away, and anyone flagged to the duty manager during service.

Actions:

1. Wait until 11am the following day. Never send this during service or late at night.
2. Send the Quick Rating link: "Morning - how was last night? One tap: [link]"
3. Branch on the rating. High: show the review routing options immediately on the same page, with no incentive attached. Low or middling: show a single comment box, and notify the general manager with quoted_wait_minutes, actual_wait_minutes, the table number and the comment. A bad rating attached to a 40-minute overrun is actionable; a bad rating on its own is noise.
4. Any comment mentioning the wait specifically is tagged so quote accuracy and satisfaction can be looked at together.
5. No reminder. One ask, then silence.

Exit: rating submitted, or 48 hours elapsed.

7. Future Waitlist and Cancellation Fill

Trigger part one: submission of Future Date Waitlist, or BO offering it when tonight is full or closed.

Actions:

1. Create a lead in Future Waitlist at Date Requested. Write requested_date, requested_time_window, party_size, date_flexibility. Apply standby-list.
2. Confirm by SMS: "You are on standby for Saturday 14th, 7 to 8pm, party of 4. If something opens up I will text you straight away - first to reply gets it." Setting the first-to-reply expectation up front is what makes the fill workflow fair and fast.
3. Move to On Standby.

Trigger part two: a cancellation is recorded on the reservation calendar, or a manager opens a Standby Offers window manually.

Actions:

1. Select matching standby records: same date, overlapping time window, party size that fits the released table, ordered by waitlist_joined_at. Cap the batch at the first five matches.
2. Send all five simultaneously, not sequentially: "A table for 4 has just opened at 7:30pm this Saturday. First to reply YES gets it - reply within 20 minutes." Sequential offers waste the window; a cancellation two hours before service has a short shelf life.
3. Stamp standby_offer_sent_at, apply standby-offered, move to Space Offered.
4. On the first YES: confirm that one, move to Converted, apply standby-converted, create the booking or notify the host to enter it, and immediately send the others: "That one has gone, sorry - you are still on standby if anything else opens." Move them back to On Standby. Telling people quickly matters more than telling them gently.
5. If nobody replies in 20 minutes, widen to the next five matches, including parties whose date_flexibility covers an adjacent day.
6. Two days after requested_date passes with no conversion, move to Expired, remove standby-list, and send one message offering to put them on standby for another date.

Exit and stop conditions: conversion, expiry, or opt-out. Across every workflow in this build, sms-opted-out suppresses all messaging and flags the record for human handling rather than silently dropping the party, and any thread flagged to the duty manager pauses all automated messaging on that contact until a human clears it.

The first thing that changes is where people wait. Once the list is a text thread rather than a clipboard, guests leave the doorway, have a drink somewhere, and come back - and a guest who spent their wait enjoyably is a guest who arrives in a good mood and spends. The queue at the door stops being a bottleneck and the host stops being a human database.

The second thing is dead table minutes. The release action moves from the one person facing the door to anyone on the floor who can see a table clearing, and the notification is instant rather than dependent on someone walking over to say so. That gap is where the recovered covers come from.

The third is that the night finally leaves a record. Every party has a quoted wait and an actual wait, a source, a party size and an outcome. You can see which service periods you consistently misquote, how long a party will actually tolerate waiting before they walk, which nights the no-show rate spikes, and - for the first time - who your walk-in guests are, which turns an anonymous Saturday into a list of people you can invite back on a quiet Tuesday.

Metrics to watch

• Quote accuracy - quoted_wait_minutes against actual_wait_minutes, as a distribution rather than an average, split by party size and service period. Being consistently ten minutes pessimistic is a feature; being optimistic is what produces walk-aways.
• Walk-away rate, and walkaway_reason mix. Track walk-aways against the wait they were quoted to find your actual tolerance threshold - the number past which quoting honestly loses the table anyway.
• Table turn gap - the median minutes between table_ready_at and seated_at. This is the number the build most directly attacks. Watch it by who released the table.
• No-show rate on notified parties, and whether a shorter or longer grace period changes it.
• Remote join share - the proportion of parties joining by QR, web or phone rather than at the stand. A rising share means the door is less congested.
• Phone handling - calls answered by BO during service, and how many converted to a waitlist entry rather than being lost.
• Standby conversion - of cancellations offered to the Future Waitlist, the share filled, and how quickly.
• Covers per service period against the same period before launch, which is the only number that settles whether any of the above mattered.
• Preference form completion rate, and specifically how often allergy_notes is captured before seating rather than at the table.

Decisions to make before building

• Your real turn times by party size, measured rather than assumed. Every wait quote in the build is only as good as these numbers. Observe two weeks of service before setting them.
• The grace period after a table-ready notification. Ten minutes is the common setting; a very busy site with a queue outside may run five. Decide it once and make it the same for everyone, because exceptions made at the door are what regulars notice.
• Who can release a table. The build works best when it is the host, the floor manager and the section servers - not just the host. Decide the list and give them the mobile board.
• How you sequence. The build presents the queue in join order with party shape visible; it deliberately does not auto-assign. Agree the house rule for when a smaller later party takes a two-top ahead of a waiting four, so the host is applying a policy rather than improvising.
• Whether the bar counts as being seated, and whether bar covers are tracked separately. This single decision changes your quoted waits more than anything else in the build.
• What happens to parties with a high no_show_count. A policy you will actually apply, agreed in advance, is better than a judgment call at the door on a Saturday.

Integrations and provisioning

• A front-of-house number, SMS-enabled, provisioned and verified before launch. This is the most important piece of plumbing in the build - the whole thing is a text conversation.
• Your reservation system, read-only, so committed tables are visible to the waitlist. If you have no reservation system and run walk-ins only, the build is simpler and faster to launch.
• Your POS, if it can expose table status or a check-closed event. This is optional but valuable: a check-closed event can prompt the floor to release the table rather than waiting for someone to notice.
• A tablet at the host stand on reliable wifi, and a fallback. Decide now what the host does if the wifi drops mid-service, and keep a paper sheet in the drawer - the busiest night of the year will be the night it happens.
• Printed QR codes for the door, the pavement board and the bar, each with a distinct source parameter so you can tell which placement actually gets used.
• Google Business Profile and your main review platform for the morning-after rating step.

Compliance

• A2P and 10DLC registration. For US sending, register the brand and campaign before the first text. Waitlist messaging is high-volume, bursty and concentrated at peak times, which is exactly the profile carriers scrutinize - register it honestly as operational guest notifications with sample copy, and expect throughput limits that matter on a busy Saturday. Test at volume before you rely on it.
• Opt-in and opt-out. Joining the waitlist with a cell number is consent for messages about that visit, and the form must say so in plain words next to the mobile field. It is not consent for marketing. Keep the morning-after rating and any later invitation behind a separate marketing opt-in offered at the end of the visit. STOP must set sms-opted-out and suppress everything - which in practice means the host must be able to see at a glance that a party cannot be texted and has to be called instead.
• Quiet hours. Operational waitlist texts are exempt by their nature - a guest who joined a queue at 9:30pm expects to hear from you. The morning-after rating and any marketing message are not: hold those to 9am to 8pm local time.
• Allergy and accessibility information. This build captures it, which creates an obligation to act on it. Make sure the route from allergy_notes to the kitchen is a real operational step with a named owner, not a field nobody reads. A captured-but-ignored allergy note is worse than never having asked.
• Data protection. You are collecting cell numbers and visit history for people who may never have given you anything else. Set a retention period for waitlist records, decide whether non-returning walk-ins are purged after a defined period, and keep allergy and accessibility data - which may be health-related - to the shortest retention you can operate with. Under GDPR, UK GDPR or similar regimes, health-related data carries additional conditions, and you will need a lawful basis, a retention schedule and a route for access and deletion requests.
• None of this is legal advice. Confirm consent wording, retention periods, registration requirements and the handling of allergy and accessibility data with the client's own counsel before launch.

Turn times, POS integration and number throughput all vary by site. To get this scoped against your own service, book a call at bookings.appbo.io.