overbooking-threshold

---
name: overbooking-threshold
description: Sets how many extra covers it is reasonable to book against real capacity, using the venue's own recorded no-show rate rather than a borrowed rule of thumb, checked against what deposits and SMS reminders are independently shown to do to that rate. Never recommends overbooking a confirmed guest out of a table, and never invents a no-show percentage this venue has not measured. Use when deciding how many bookings to take above seated capacity.
---

# Overbook by the number that protects you, not a guess

Give it the service's seated capacity and the venue's recorded no-show history. Get back a recommended margin built from that history, a comparison of what deposits and reminders are shown to do to no-shows, and a hard rule against ever bumping a guest who did turn up.

## What it does

1. **Start from this venue's own recorded no-show rate.** A measurement across "3,768,761 reservations across 2,417 restaurants" found "the average recorded restaurant no-show rate is 2.33%", and states its customers "are not a random sample of all restaurants." A borrowed figure is not evidence about this venue's book.

2. **Size the margin to the measured rate, not above it.** A 60-cover service with a 5% recorded rate justifies roughly 3 extra covers, not a round "10% just in case."

3. **Weigh a deposit requirement first.** The same measurement found "reservations requiring no-show protection recorded a 0.80% no-show rate" against "2.47% for reservations without a payment requirement", calling these "raw descriptive rates" rather than proof of cause.

4. **Weigh an SMS reminder as a smaller lever.** "Reservations with a delivered SMS reminder showed a 16% lower recorded no-show rate", again "an observed association... not a controlled experiment."

5. **Track the trend.** UK no-shows "fell by 6% year-on-year" per one report, which cites a platform finding deposits "saw a 60% reduction in no-shows" globally. Recalculate from recent weeks.

6. **Draw the hard line at the guest who turns up.** The margin is absorbed by no-shows, never imposed on the confirmed guest at the door.

## Then it checks

1. The rate used is this venue's own recorded figure where one exists, with weeks stated.
2. The margin is no higher than the measured rate for that slot.
3. Any deposit or reminder in place is reflected in which rate was used.
4. The margin has a recalculation date.
5. No output describes bumping an arrived guest.

Any check fails: redo that step once. Failed twice: say what is wrong and stop.

## Rules
- Public information only. Never invent a fact, number or quote. Anything sent in someone's name says whose name it is.
- Never set a margin above the measured no-show rate for that slot.
- Never describe overbooking as a way to manage a guest who arrives; it is only ever a hedge against guests who do not.
- Never present an association as proof of causation.
- Working document for the owner to check against their own booking data.

## Built from
- Resos, "No-Show Index 2026", resos.com/restaurant-no-show-rate/, published 19 Aug 2026, read 4 Nov 2026: steps 1, 3 and 4.
- RestaurantOnline, "No-show rates fall year-on-year, report finds", restaurantonline.co.uk, 6 Oct 2026, read 4 Nov 2026: step 5.

# overbooking-threshold

## You are given
Seated capacity in covers, by slot (e.g. `dinner 7pm-9pm`). The venue's own booking history for that slot, if available: total bookings, total no-shows, date range. Whether a deposit/card-hold or SMS reminder already applies (`yes`/`no` each). The industry comparison figures supplied by Claude: the Resos overall rate, deposit-vs-no-deposit rates, and SMS reminder effect, each with source and date read.

## Produce
Write into a `./overbooking-threshold-output/` folder:

1. `no-show-rate.csv`: `slot`, `total_bookings`, `total_no_shows`, `measured_no_show_rate_percent`, `date_range_start`, `date_range_end`, `rate_source`. Calculated from the venue's own counts where available; otherwise `rate_source` names the industry figure used, never a blended guess.
2. `margin-recommendation.csv`: `slot`, `seated_capacity`, `measured_no_show_rate_percent`, `recommended_extra_covers`. `recommended_extra_covers` is `seated_capacity` × rate, rounded down; never recorded above the measured rate.
3. `lever-comparison.csv`: `slot`, `deposit_or_hold_in_place`, `measured_rate_with_lever_percent`, `measured_rate_without_lever_percent`, `sms_reminder_in_place`, `which_rate_was_used`.
4. `recalculation-log.csv`: `slot`, `margin_set_date`, `next_recalculation_date`, `weeks_of_data_used`. Appended, never overwritten.
5. `gaps.md` - a numbered list of: any margin above its measured rate; any slot using an industry figure with under four weeks of venue data (flagged, not blocked); any guest-facing wording about delaying or bumping an arrived guest; any slot with no `next_recalculation_date`.

## Rules
- Codex calculates and records. It never decides which rate to use when both are available, and never writes guest-facing wording.
- Never record a margin above the measured rate for that slot.
- Never write or leave in any file a sentence about reducing, delaying or reallocating service to an arrived, confirmed guest.
- Rates are calculated exactly, never estimated, always rounded down when converted to covers.
- Use British English and DD Month YYYY dates. No em dashes; flag any supplied text containing one in `gaps.md`.
- Every file ends with: this is a working document for the owner to check against their own booking data, and is not a guarantee against walk-away guests or complaints from an overbooked service.

## Return
Each file's absolute path and row count. The rate used per slot, and its source. The recommended margin per slot. Which lever is reflected in the rate used. The recalculation date per slot. The `gaps.md` item count.