Restaurant Reservation No-Show Killer

Restaurants doing 30+ reservations per week with measurable no-show pain. Ideal: fine dining (2-3 turns/night, $80+ check averages, no-show kills the whole night), upscale casual ($40-60 check, 4 turns), brunch destinations (high-volume weekend rush). Less applicable: quick-service, walk-in dominant, food trucks.

The pitch lands hardest with owners who can name their no-show rate, they're aware of the problem and ready for a solution. Owners who haven't measured no-show pain are pre-aware; lead with "what's your current no-show rate?" If they don't know, walk them through how to calculate it from their OpenTable/Resy data. Once they see the number, the pitch sells itself.

The system ingests new reservations from the restaurant's existing booking platform (OpenTable, Resy, Tock, SevenRooms, Toast, or manual entry). For each upcoming reservation, it fires a 3-touch confirmation sequence: 1. 24 HOURS before, friendly confirmation with restaurant details and any specials 2.

4 HOURS before, confirmation with one-tap CONFIRM/CANCEL/RESCHEDULE buttons 3. 90 MINUTES before, final reminder + arrival logistics (parking, dress code, etc.) When a customer taps CANCEL, the system instantly: (1) notifies the host stand on the floor manager's device, (2) checks the waitlist for that time slot, (3) auto-fires waitlist outreach: "We just had a table open at [time] tonight for [party size]. First to confirm gets it!", converting a no-show loss into a recaptured seating.

When a customer goes silent (no confirmation by 4hr mark), the system flags them as high no-show risk on the host stand dashboard. The 24-hour SMS doubles as an upsell channel, chef's special, wine pairing of the day, dessert menu preview, lifting average check 5-15%. Built for the operating tempo of a real restaurant: the floor manager sees tonight's confirmation status at a glance on their tablet, can manually escalate to a personal call for high-value reservations, and the system tracks no-show rate trends so management can see the lift over time.

This is one of the most operationally-impactful tools in the library, and one of the most timing-sensitive. Expect Base44 to build in 20-30 minutes. Likely follow-up prompts:

If timing logic is firing at wrong times: "Reservation timing logic isn't respecting the restaurant's local timezone. All scheduled SMS times need to be calculated in the restaurant's timezone (set in Settings), not server UTC. When a reservation is for 7pm local time, Touch 2 should fire at 3pm local (4hr before), not 3pm UTC."

If waitlist outreach is double-booking: "The waitlist auto-fill is creating race conditions. When multiple waitlisters reply YES simultaneously, both end up booked. Add atomic check-and-set on the canceled Reservation: when a waitlist accept comes in, transactionally update the canceled Reservation to 'filled_by_waitlist' AND create the new Reservation in the same transaction.

If the canceled Reservation already shows 'filled_by_waitlist' when checking, send the apology message instead."

If the host stand dashboard isn't auto-refreshing: "Host stand dashboard needs real-time updates. Implement either WebSocket connection OR aggressive polling (every 30 seconds). Floor managers cannot manually refresh, they're running the floor."

If reply parsing is misclassifying: "Reply parser is missing common variations. Expand keyword lists. CONFIRM: 'yes', 'y', 'confirm', 'confirmed', 'see you', 'coming', 'we'll be there', 'still on', 'good to go'.

CANCEL: 'cancel', 'no', 'can't', 'cant make', 'have to cancel', 'something came up', 'won't be able'. RESCHEDULE: 'change', 'reschedule', 'different time', 'move'. Use LLM only as fallback for ambiguous replies."

If OpenTable/Resy webhook is missing reservation modifications: "When a guest modifies their reservation (party size change, time change), the source platform sends a 'modified' webhook event. We're not handling this, we're treating modifications as duplicate new reservations. Add handling: on 'modified' event, find the existing Reservation by source_platform_reservation_id, cancel all unsent TouchScheduled records, recalculate timing based on new reservation_datetime, re-schedule fresh touches."

If the dashboard isn't visually clear during service: "Host stand dashboard needs stronger visual hierarchy during the rush. Color-code aggressively: green=confirmed, yellow=pending past 4hr mark, red=canceled, orange=high-risk no-show (silent past 4hr). Make the COUNTS at the top tile large and color-coded too.

Floor managers should be able to glance at the screen during a busy rush and instantly know the status of tonight."

The biggest gotcha: timezone handling. Restaurants run in their local time, period. All timing math must respect that.

If a customer travels and uses a different cell timezone, the reservation_datetime is still in restaurant local time. Server time is irrelevant.

Second biggest gotcha: the restaurant's existing booking platform integration. OpenTable and Resy webhooks aren't always trivial, sometimes the restaurant doesn't have webhook access on their plan tier. Have a manual-entry fallback ready.