Reservation and Booking Confirmation

A reservation is a promise made twice: the guest promises to arrive and the venue promises to be ready. Most venues manage the second half well and the first half not at all. A booking comes in by phone at 11am, gets written into the book, and then nothing happens between that moment and the guest either walking through the door or not. There is no confirmation the guest can act on, no reminder, no reconfirmation, and no way to tell a firm booking from a vague intention. By the time the host stand knows a table is empty, the service period is half over and the covers are gone.

Underneath that sits a quieter failure: the detail that would make the visit good is collected inconsistently or not at all. The anniversary nobody knew about, the nut allergy mentioned on the phone to someone who has since gone home, the guest who asked for a quiet corner, the second family that needs a highchair, the arrival at 19:45 when the kitchen is already stacked. All of it is recoverable with two questions asked before arrival, and almost nobody asks them. The same gap swallows every pre-arrival sale a venue could reasonably make - the bottle on the table, the room upgrade, the tasting flight, the parking space, the late checkout - because an offer made at the table competes with a menu, while an offer made three days out competes with nothing.

The money leaks in three directions, and they compound. No-shows and late cancellations are the obvious one: a table or room held and unsold is revenue that cannot be recovered later, and without a reconfirmation step there is no moment at which the venue learns in time to resell it. Second, manual confirmation eats staff hours in the middle of service, which is exactly when those hours are most expensive. Third, every uncaptured preference is a service failure waiting to happen and a review you will have to answer in public. A reservation system that confirms instantly, reconfirms deliberately, enriches the record before arrival and backfills from a waitlist turns all three leaks into measurable, controllable numbers.

Pipeline and stages

One pipeline, Reservations, with a record per booking rather than per guest, because the same guest will hold several bookings and each one has its own clock.

• Inquiry - a request exists but no slot is held. Includes anything BO could not place against available capacity.
• Held - Unconfirmed - capacity provisionally allocated, guest has not yet confirmed. Carries an auto-release clock.
• Confirmed - guest has clicked confirm, replied YES, or been confirmed by a member of staff.
• Secured - deposit taken or card held where your policy requires it. Large parties and peak dates sit here, not in Confirmed.
• Pre-Arrival - inside 72 hours. Reconfirmation and enrichment sequences run from this stage.
• Reconfirmed - the guest has actively re-affirmed inside the final 48 hours. This is the stage that protects your covers.
• Arrived - marked by the host stand or the front desk.
• Completed - service finished. Triggers the review and rebooking sequence.
• No-Show - did not arrive, no contact. Reason captured where known.
• Canceled - In Policy and Canceled - Late - split deliberately, because they are different problems with different follow-ups.
• Waitlist - wanted a slot that was full. Holds the date, the time window and the flexibility, ready for backfill.

Calendars and capacity

• Service periods - one calendar per period (Lunch, Dinner, Weekend Brunch) or per inventory type (Standard Room, Suite, Private Dining Room), each with its own opening pattern.
• Slot capacity - maximum covers or units per slot, with staggered start times at 15-minute intervals to stop every booking landing at 19:30 and sinking the kitchen.
• Party-size rules - parties above your threshold cannot self-book; they route to the large-party calendar and a human. Set this threshold where your room genuinely stops being flexible.
• Lead time and horizon - minimum notice of 2 hours for standard slots, booking horizon of 90 days, and a shorter horizon on peak dates you want to hold back for direct inquiries.
• Turn times - per party-size band, so the calendar stops offering a slot that cannot physically exist.
• Blackouts - private hire, closures and maintenance blocked once, centrally, so no channel can sell them.

Custom fields

• reservation_datetime, party_size, service_period, inventory_type
• source_channel - Website, Phone, Voice Assistant, SMS, Walk-In, Third-Party Platform, Partner, Returning Guest Link
• guest_type - First Visit, Returning, VIP, Trade
• visit_count and last_visit_date
• occasion - None, Birthday, Anniversary, Business, Celebration, Proposal
• dietary_notes and allergy_flag - allergy_flag is a switch that forces a human read before service and is never actioned by automation alone
• accessibility_needs - free text, surfaced on the service sheet
• seating_preference and special_request
• confirm_status - Unconfirmed, Confirmed, Reconfirmed - and confirmed_at, reconfirmed_at
• release_deadline - the datetime an unconfirmed hold is released
• deposit_required and deposit_status - Not Required, Requested, Held, Released, Retained
• card_on_file - switch
• reminder_count - number of reminders sent, capped
• upsell_offered, upsell_accepted, upsell_items
• no_show_count and late_cancel_count - lifetime, on the guest record not the booking
• cancellation_reason
• waitlist_flexibility - Exact Time Only, Same Day Any Time, Same Week
• language_pref and consent_marketing - the second one separate from booking consent, always

Tags

• res-unconfirmed, res-confirmed, res-reconfirmed
• res-today, res-tomorrow - applied by the daily sweep and used by the service sheet
• guest-vip, guest-returning, guest-first-visit
• large-party, peak-date
• allergy-present, accessibility-need - both visible on every internal view
• occasion-birthday, occasion-anniversary, occasion-business
• upsell-offered, upsell-accepted
• deposit-unpaid, deposit-held
• no-show-history - applied at two lifetime no-shows and used to require a card, not to refuse a booking
• waitlist-active
• sms-opt-out - global suppression, checked first everywhere

Forms

• Booking Request - on the website, four fields visible: date, time, party size, name and contact. Everything else comes later. A long booking form is a canceled booking.
• Pre-Arrival Details - sent 72 hours out. Occasion, dietary notes, allergies, accessibility needs, seating preference, arrival time confirmation, and one open line. Two minutes to complete, and it is the highest-value form in the build.
• Large Party Inquiry - for parties over your threshold. Captures date flexibility, budget expectations in your own bands rather than figures, menu format preference and whether exclusive use is wanted. Routes to a human within the hour.
• Cancellation Form - one click from any confirmation message, with a reason picker. Making canceling easy is how you learn in time to resell.
• Waitlist Join - date, time window, party size, flexibility level.
• Post-Visit Feedback - two questions plus a review link, routed by score.

BO's role and guardrails

• BO takes booking requests by web chat, SMS and the overflow voice line, checks live capacity, and holds or confirms a slot inside the rules the calendar enforces.
• BO answers the standard questions from an approved venue fact sheet: opening hours, location and parking, dress code, children and dog policy, accessibility, menu format, cancellation terms as written in your policy.
• BO handles reschedules and cancellations end to end, including releasing the slot and starting the waitlist backfill.
• BO never exceeds the capacity rules, never books over a blackout, and never shortens a turn time. If there is no slot, BO offers the nearest alternatives and the waitlist, and never invents availability.
• BO never quotes a price, a deposit amount, a minimum spend or a discount, and never offers a comp or a goodwill gesture. Pricing and policy questions go to the venue's published terms and, where that is not enough, to a named human.
• Allergies are never handled by BO alone. A declared allergy sets allergy_flag, applies allergy-present, and creates a task for the duty manager to acknowledge in writing before arrival. BO does not confirm that any dish is safe.
• Large parties, exclusive-use inquiries, accessibility requirements and anything touching a complaint route straight to a human with full context.
• BO messages guests only between 08:00 and 21:00 in the guest's own time zone, with transactional booking messages the single exception where your policy and local rules allow it.

Numbers and channels

• One dedicated venue number for SMS and WhatsApp-style messaging, registered, with the venue name in the first message of every thread.
• Voice answering on the main line with an AI assistant handling overflow and out-of-hours: takes the booking, reads back the detail, and transfers to a human on request, on any allergy mention, and on any party above the threshold. Every call is logged against the booking.
• A booking page per service period under the venue's own domain, mobile-first, with the whole flow in under 60 seconds.
• Email from a monitored venue address for confirmations, with calendar attachments so the booking lands in the guest's own calendar.
• Internal: a service channel in Slack or your team chat receiving the daily service sheet, every allergy flag, every large party, and every late cancellation so the floor can react.

One booking, from a Tuesday afternoon inquiry to a rebooking two weeks later.

1. At 14:20 on a Tuesday a guest texts the venue number: four people, Saturday, around eight. The number is registered and the thread opens with the venue name.
2. BO reads the request, checks the Dinner calendar for Saturday, and finds 20:00 full but 19:45 and 20:15 open under the turn-time rules for a party of four. BO replies with both, plus the honest note that 19:45 is the better table.
3. The guest picks 19:45. BO creates the booking in Held - Unconfirmed, writes reservation_datetime, party_size 4, service_period Dinner, source_channel SMS, and sets release_deadline to 4 hours out.
4. The confirmation goes out immediately with a single confirm link and a single cancel link, the address, and the cancellation terms in one line. The guest taps confirm 90 seconds later. confirm_status becomes Confirmed, confirmed_at is stamped, the release clock is canceled, and the slot is now firm. A calendar attachment follows by email so the booking is in the guest's own calendar.
5. The guest record shows visit_count 3 and last_visit_date in February, so guest_type is set to Returning and guest-returning is applied. Party size 4 is under the large-party threshold, and Saturday is a peak-date, so your policy requires a card on file but no deposit. The card-capture link is sent and completed in one tap through Stripe; card_on_file is switched on, stage moves to Secured.
6. Wednesday: nothing happens. Deliberately. The system is quiet between confirmation and 72 hours out.
7. Thursday morning, 72 hours before the booking, stage moves to Pre-Arrival and the Pre-Arrival Details form goes out. The guest completes it in two minutes: occasion Anniversary, one guest avoids dairy, no allergies, prefers a banquette, arriving on time.
8. occasion is written, occasion-anniversary applied, dietary_notes recorded, seating_preference recorded. Because the occasion is a milestone and no allergy is present, the pre-arrival offer fires: a short message offering a chilled bottle on the table and a dessert plate inscribed, both bookable with one tap. The guest takes the bottle. upsell_accepted is set, upsell_items records it, payment runs through Stripe, and the kitchen and bar both get a line on the service sheet.
9. Friday, 24 hours out: the reconfirmation message. One question, two buttons - still coming, or need to change it. The guest taps the first. confirm_status becomes Reconfirmed, reconfirmed_at stamped, stage moves to Reconfirmed, and the booking is now as solid as a booking gets.
10. Saturday 08:00: the daily service sheet lands in the service channel and in the duty manager's inbox. Four covers at 19:45, returning guests, anniversary, banquette requested, dairy avoidance noted, bottle pre-ordered and paid, no allergy flags. The floor plan is built from real information rather than guesses.
11. 19:38: a short arrival message with the door code for the side entrance and the host's name. The party arrives at 19:44. The host taps Arrived; stage moves to Arrived.
12. Service happens. The bottle is on the table when they sit down, which is the part the guest will tell other people about. At 22:10 the host taps Completed.
13. 22:30, twenty minutes after departure: the Post-Visit Feedback message. Two questions. The guest scores 5 and writes one line about the bottle. Because the score is 4 or 5, the follow-up message invites a public review with a direct link; had it been 3 or below, the message would have gone to the duty manager instead and no review link would have been sent.
14. Fourteen days later, with consent_marketing on, a single rebooking message goes out referencing the anniversary and offering the same banquette. The guest books again from that message, and source_channel records Returning Guest Link - which is how you find out that this sequence, rather than any advertising, produced the booking.
15. Meanwhile, on the same Saturday, a second party canceled at 16:00 using the cancel link. cancellation_reason recorded as Illness, stage moved to Canceled - In Policy, the slot released back to the calendar, and the waitlist backfill fired to three guests holding waitlist-active for that evening. The first to reply took the table within 11 minutes, and the covers were never lost.

Eight workflows. Every one checks sms-opt-out before any SMS step and falls back to email rather than skipping the message entirely, because a booking confirmation is information the guest needs.

1. Booking Intake and Instant Confirmation

Trigger: a Booking Request form submission, a slot taken from the booking page, a booking captured by BO over SMS or web chat, a booking taken by the voice assistant, or a third-party platform booking arriving by integration.

Conditions and branches:

• Match the phone number and email against existing guests. On a match, link to the guest record and carry visit_count, last_visit_date, dietary_notes, seating_preference and no_show_count forward. A returning guest should never be asked twice for the same thing.
• If party_size is above your large-party threshold, do not confirm. Create the booking in Inquiry, apply large-party, send the Large Party Inquiry form, and alert the duty manager with a 60-minute response task.
• If the slot has no capacity, do not hold it. Offer the two nearest available times and the Waitlist Join link.

Actions in order:

• Create the booking in Held - Unconfirmed, write reservation_datetime, party_size, service_period, inventory_type and source_channel. Apply res-unconfirmed.
• Set release_deadline: 4 hours for a booking made more than 48 hours out, 60 minutes for a booking made inside 48 hours, 15 minutes for a same-day booking.
• Within 1 minute: send the confirmation request by SMS. [Venue] - holding a table for [party_size] on [day] at [time]. Tap to confirm: [link]. Need to change it: [link]. We hold unconfirmed tables for [window], so a tap now locks it in.
• Within 1 minute: send the same by email with a calendar attachment, the address, parking note and your cancellation terms quoted verbatim.
• On confirm: set confirm_status Confirmed, stamp confirmed_at, swap res-unconfirmed for res-confirmed, move to Confirmed, cancel the release clock, and evaluate workflow 3.
• If guest_type is VIP, additionally notify the duty manager immediately rather than waiting for the service sheet.
• If the date carries peak-date, or no_show_count is 2 or more, pass to workflow 3 for a card or deposit.

Exit: confirmed, released, routed to a human, or waitlisted.

2. Unconfirmed Chase and Auto-Release

Trigger: booking sits in Held - Unconfirmed.

Actions in order:

• At 50 per cent of the release window: one reminder. Still holding [day] at [time] for you - one tap confirms it: [link]. If plans changed, no problem, tap here and we will give the table to someone else: [link].
• At 15 minutes before release_deadline: final notice naming the exact release time.
• At release_deadline: release the capacity back to the calendar, move to Canceled - In Policy with cancellation_reason Unconfirmed, and send one plain message: We have released the table for [day] at [time] since we did not hear back. If you still want it, here is live availability: [link]. No hard feelings either way.
• Immediately on release: fire workflow 6 to backfill from the waitlist.
• Increment a soft counter on the guest record. A guest who fails to confirm three times gets no-show-history treatment on the next booking, meaning a card on file rather than a refusal.

Exit: guest confirms, cancels, or the hold is released. No guest receives more than two chase messages here.

3. Deposit or Card-on-File Capture

Trigger: booking reaches Confirmed and deposit_required evaluates true.

Conditions: deposit_required is set by your own rule set, typically party_size above a threshold, a date tagged peak-date, a private dining or exclusive-use booking, or a guest carrying no-show-history. The amount lives in your payment configuration and is never written into a message by the automation.

Actions in order:

• Send a Stripe payment or card-authorization link with the terms in plain words: what is held, when it is released, and what happens on a late cancellation or no-show, quoted from your published policy. Set deposit_status Requested, apply deposit-unpaid.
• Wait 12 hours. Not completed: one reminder. Wait 12 more hours: second reminder naming the date the hold lapses.
• At 48 hours unpaid, or 24 hours before arrival, whichever comes first: alert the duty manager with a task to call. Do not auto-cancel a deposit booking - a human makes that decision, because the guest may simply have a card problem.
• On payment or authorization: set deposit_status Held, swap deposit-unpaid for deposit-held, switch card_on_file, move to Secured, and send a receipt plus a restatement of the terms.
• On completed visit: set deposit_status Released and trigger the release or redemption in Stripe according to your policy.
• On a no-show or late cancellation: do not charge automatically. Create a task for the duty manager to decide and to contact the guest first. Set deposit_status Retained only after a human has acted.

Exit: deposit held, booking canceled by a human, or visit completed.

4. Pre-Arrival Enrichment and Reconfirmation Ladder

Trigger: scheduled relative to reservation_datetime, on any booking in Confirmed or Secured.

Actions in order:

• 72 hours before: move to Pre-Arrival, apply nothing loud, and send the Pre-Arrival Details form. [Venue] - looking forward to [day]. Two minutes here and we will have the table set up the way you want it, including anything you cannot eat: [link]. Skip the dietary questions for a returning guest whose answers you already hold, and instead ask them to confirm: Last time we noted [preference] - still right?
• On form submission: write occasion, dietary_notes, accessibility_needs, seating_preference and special_request. If an allergy is declared, set allergy_flag, apply allergy-present, and run the allergy branch in workflow 5.
• 48 hours before: if the form is not completed, one short nudge with the two questions that matter most - any allergies, and any occasion - answerable by reply.
• 24 hours before: the reconfirmation. Two buttons only. [Venue] tomorrow at [time] for [party_size]. Still good? Tap YES. Need to change or cancel? Tap here - the earlier we know, the better for both of us.
• On YES: set confirm_status Reconfirmed, stamp reconfirmed_at, apply res-reconfirmed, move to Reconfirmed. Stop reminding.
• 6 hours before, if still not reconfirmed: one last SMS, and add the booking to the at-risk list on the service sheet so the host stand knows. Do not cancel the booking - most unreconfirmed guests still arrive.
• 2 hours before, if still not reconfirmed and party_size is above the threshold: create a task for the duty manager to telephone. A large unreconfirmed party is the single most expensive thing in your book.
• 90 minutes before: the arrival message to every booking - time, address, parking or door detail, the host's name, and a reply route if they are running late. Cap total messages for this booking at four, counted in reminder_count.

Exit: reconfirmed, canceled, rescheduled, or arrival time passes.

5. Allergy, Accessibility and Special Request Routing

Trigger: allergy_flag set, accessibility_needs populated, or special_request containing text, from any source including the voice assistant.

Actions in order:

• Immediately: post to the service channel with the booking, the date, the exact wording the guest used, and the guest's contact. Never summarize an allergy; pass the words through.
• Immediately: create a task for the duty manager on shift for that service, due within 4 hours, to review with the kitchen and reply to the guest in writing.
• Wait 4 hours. Task not complete: escalate to the general manager. Wait 4 more hours: escalate again and flag the booking on the service sheet as unacknowledged. This chain should never go quiet.
• Human reply sent: log it against the booking so there is a record of what was promised to the guest, by whom, and when.
• Suppress the pre-arrival offer on any booking with allergy_flag set until the acknowledgement is logged. Selling a tasting flight to a guest whose allergy you have not yet answered is the wrong order of operations.
• Accessibility branch: notify the host stand and, where relevant, housekeeping or maintenance, with a task to confirm the specific arrangement - step-free route, accessible facilities, a particular table - and a written reply to the guest.
• Carry forward: write confirmed dietary and accessibility detail to the guest record so the next booking starts from it, within whatever retention period you have set.

Exit: acknowledgement logged. The workflow does not close itself on a timer.

6. Cancellation, No-Show and Waitlist Backfill

Trigger A - cancellation: guest uses a cancel link, replies CANCEL, cancels through BO, or a human cancels the booking.

• Capture cancellation_reason from the picker. Branch on timing against your policy window: outside it, move to Canceled - In Policy; inside it, move to Canceled - Late, increment late_cancel_count, and create a duty-manager task rather than taking any automated financial action.
• Release the capacity to the calendar immediately. This is the step that pays for the build.
• Send a short, graceless-free acknowledgement with a rebooking link: Canceled - thanks for telling us, it genuinely helps. Whenever you want to come back: [link].
• Immediately fire the backfill: query waitlist-active records matching the date and party size, ordered by waitlist_flexibility then by join time. Message the first three simultaneously with a first-come link and a 20-minute expiry. [Venue] - a table for [party_size] has just come free on [day] at [time]. First to tap takes it: [link]. Expires in 20 minutes.
• After 20 minutes with no taker: message the next five, widening to Same Day Any Time flexibility. After a further 30 minutes: release the slot to the public booking page and, if the date is within 48 hours, post it to your social channels.
• On a waitlist guest taking the slot, create the booking as Confirmed directly, skip the hold clock, and run workflow 4 from whichever point the lead time allows.

Trigger B - no-show: 20 minutes past reservation_datetime with no Arrived mark.

• Create a host-stand task to check the floor before anything else happens. Automation must not declare a no-show while the guest is standing at the bar.
• On confirmation from the host, move to No-Show, increment no_show_count, and release the capacity.
• Wait 2 hours, then send one message, written to learn rather than to scold: We had you down for [time] tonight and missed you - hope everything is all right. If something went wrong on our side, tell me and I will fix it. Capture any reply against cancellation_reason.
• At no_show_count 2: apply no-show-history, which makes a card on file a condition of the next booking. Never block a guest automatically; that decision belongs to the owner.

Exit: slot resold, or the service period ends.

7. Pre-Arrival Offer and Occasion Enrichment

Trigger: booking reaches Pre-Arrival with the details form complete, allergy_flag clear or acknowledged, and 36 or more hours remaining.

Conditions and branches: offer by occasion and guest_type, never a generic list.

• occasion Anniversary or Birthday: offer exactly two things - a bottle on arrival and something written on a plate. [Day] is a bit of an occasion. Two things we can have ready: a chilled bottle on the table when you sit down, or dessert with a message on the plate. Either, both, or neither - tap here: [link].
• occasion Business: offer the quieter table and a set-menu pre-order to save time, not celebration extras.
• inventory_type a room: offer early check-in, late checkout, parking, and breakfast added in advance - in that order, and never more than three.
• guest_type First Visit: offer nothing to buy. Send one message about what to expect and where to park. An unsold first visit that goes well is worth more than an upsold one that feels transactional.
• guest_type VIP: no automated offer. Create a task for the duty manager to make a personal call.

Actions in order:

• Set upsell_offered and apply upsell-offered. Send one message, on the guest's preferred channel, between 10:00 and 19:00 local.
• On acceptance: take payment through Stripe where your policy is to pre-charge, write upsell_items, set upsell_accepted, apply upsell-accepted, and post the item to the service channel so the kitchen, bar or housekeeping sees it on the sheet.
• No response after 24 hours: one reminder only if more than 24 hours still remain before arrival. Otherwise stop. One ask, one reminder, then silence.
• Never offer anything to a booking that is unconfirmed, carries an unacknowledged allergy flag, has a complaint logged against the guest record, or sits inside 12 hours of arrival.

Exit: accepted, declined, or the arrival window opens.

8. Daily Service Sheet, Post-Visit Review and Weekly Reporting

Trigger A: scheduled, 08:00 daily.

• Apply res-today and res-tomorrow, then build the service sheet by service period: time, name, party size, confirmation state, guest_type, visit_count, occasion, dietary_notes, allergy flags, accessibility needs, seating preference, pre-ordered extras and deposit state. Send it to the service channel and to the duty manager.
• Include three summary lines: total covers, covers reconfirmed, and bookings at risk because they are unreconfirmed inside 24 hours.
• Create one task per allergy flag not yet acknowledged, and one per large party not yet called.

Trigger B: stage moved to Completed.

• Wait 20 minutes after the completion mark, then send the two-question Post-Visit Feedback message. Twenty minutes is long enough to be out of the door and short enough to still be thinking about it.
• Score 4 or 5: reply with thanks and one direct review link to the single platform you most need. One link, not four.
• Score 3 or below: send no review link at all. Post to the service channel, create a duty-manager task to make personal contact within 24 hours, and log the resolution against the guest record.
• No response after 48 hours: stop. Do not chase feedback.
• Wait 14 days, and if consent_marketing is on, send one rebooking message referencing what you know - the occasion, the table they liked, the dish they mentioned. Then nothing for 90 days unless they engage.

Trigger C: scheduled, Monday 09:00.

• Send the owner and general manager the weekly report: covers by service period against capacity, no-show rate split by confirmation state, late cancellation rate with reasons, waitlist backfill rate and median refill time, pre-arrival form completion, occasion capture, attachment rate by offer type, channel mix with the direct versus third-party split, feedback scores and review volume, and repeat-visit rate.
• Flag any service period where reconfirmation rate fell below your threshold, and any day where released capacity went unsold, with the slot times, so the next week's staffing and promotion can respond to it.

Exit: none. The daily sheet and the weekly report run permanently.

Three things change on the floor. First, the book stops lying to you. Every booking carries a confirmation state, so a Saturday service sheet showing 84 reconfirmed covers means something, where 84 covers in a paper book never did. Second, service starts from information rather than discovery - the occasion, the dietary requirement, the seating preference and the arrival time are all on the sheet before anyone walks in, which is the difference between a competent visit and a memorable one. Third, a cancellation becomes an opportunity instead of a loss, because the slot goes back to the calendar and to the waitlist automatically, at 16:00 rather than at 20:30.

Behind the scenes, staff time moves out of the middle of service. Nobody is ringing round to confirm tomorrow's bookings during a lunch rush, because the reconfirmation ladder already did it, and the only calls a human makes are the ones that need a human: the large party, the allergy acknowledgement, the guest who has asked for something unusual.

What to measure

• No-show rate, split by confirmation state. The gap between the no-show rate on Confirmed bookings and on Reconfirmed bookings is the number that justifies the whole build.
• Reconfirmation rate - share of bookings actively reconfirmed inside 48 hours, by channel. If SMS reconfirmation runs well above email, rebalance.
• Late cancellation rate and the lead time distribution on cancellations. The goal is not fewer cancellations, it is earlier ones.
• Waitlist backfill rate - share of released slots resold, and the median minutes from release to refill.
• Unconfirmed auto-release volume - how much capacity is being held by people who never confirm, which tells you whether your release window is right.
• Pre-arrival form completion rate - target well above half. Below a third means the form is too long or sent at the wrong moment.
• Occasion capture rate and the share of bookings arriving with any enrichment at all.
• Pre-arrival attachment rate - share of bookings that accept an extra, and which extras get taken. Offer fewer things than you think; the single best-performing extra usually beats a list of five.
• Average party size and cover utilization per slot, to see whether staggered start times are actually smoothing the kitchen.
• Channel mix - direct bookings versus third-party platforms, and the trend. Every direct booking you win back is margin.
• Feedback score and review volume, with the share of 4-and-5 scores that convert into a public review.
• Repeat visit rate within 90 days, and bookings attributable to the rebooking message.

Prerequisites

• Real capacity rules written down before anything is built: covers or units per slot, turn times per party-size band, the party-size threshold above which a human must be involved, your minimum notice and your booking horizon. Automation cannot invent these, and a calendar configured on optimism will oversell your room.
• A written cancellation and no-show policy, published on the booking page and quoted verbatim in confirmation messages. Decide what triggers a card on file or a deposit - typically party size above a threshold, peak dates, and guests with no-show-history - and have that rule agreed by whoever will have to enforce it at the door.
• A venue fact sheet for BO: hours, address and parking, access, dress code, children and dogs, menu format, how long you hold a table for a late arrival, and how your deposit and cancellation terms are worded. BO answers only from this.
• A named duty manager per service period, since allergy acknowledgements and large-party inquiries route to a person, not a queue.
• Your blackout dates for the next 90 days loaded before go-live.
• Decided message channel preference per guest type, and the fallback order when a channel fails.

Integrations

• Stripe for card-on-file authorization, deposits and pre-arrival extras. Decide whether you authorize or charge, and whether extras are paid up front or added to the bill.
• Your till or property management system, so a booking marked Arrived and Completed reconciles against what actually happened. Where there is no native connection, a Zapier or Make step on the booking lifecycle is enough to keep the two in step.
• Google Calendar or Outlook for staff-facing views, plus calendar attachments on guest confirmations.
• Third-party booking platforms and your Google Business profile, each pushing bookings into the same pipeline with source_channel recorded. If third-party bookings bypass this system, your service sheet is incomplete and the floor will stop trusting it.
• Your review platform for the post-visit routing, and Slack or your team chat for the service channel.

Numbers and messaging compliance

• Provision a dedicated venue number and complete A2P 10DLC registration before launch. Register the brand and a campaign describing the real use case: transactional booking confirmations and reminders to guests who gave their number when booking, with marketing messages registered separately if you intend to send them.
• Keep transactional and marketing consent separate. Booking consent covers the confirmation, the reminder, the reconfirmation and the arrival message. It does not cover the seasonal promotion. Capture consent_marketing explicitly and never infer it from a reservation.
• Identify the venue by name in the first message of every thread. Carry opt-out language on marketing sequences, honor STOP, UNSUBSCRIBE, CANCEL and QUIT instantly, write the opt-out to the guest record, and make suppression global. Keep an email fallback for a guest who opts out of SMS but still holds a booking.
• Set quiet hours in the guest's own time zone - 08:00 to 21:00 is a reasonable default - and keep the arrival-day message inside them.
• Cap reminder_count so a guest cannot receive more than four messages about one booking. Reminder fatigue produces opt-outs, and an opted-out guest cannot be reconfirmed.

Allergies, accessibility and data protection

• Treat allergy information as safety-critical, not marketing data. It must appear on the service sheet, be acknowledged in writing by a named human before arrival, and never be answered by an automated message. Automation routes it; people own it.
• Dietary, allergy and accessibility details are health-related personal data in many jurisdictions. Collect only what service needs, restrict who can see it, set a retention period, and delete it on schedule rather than keeping it indefinitely in a guest profile.
• Card details belong in your payment processor, never in a custom field, a note or a message thread. If a guest sends a card number by text, delete it and tell them why.
• Confirm your lawful basis for booking and marketing messages, your retention periods and your privacy notice before go-live, especially if you take bookings from guests in the UK, EU or other regimes with data-protection law.
• None of this is legal advice. Have the venue's own counsel confirm the cancellation and deposit terms, the consent wording, the handling of dietary and health information and the retention schedule for your jurisdictions. To scope a build, book a call at bookings.appbo.io.