waitlist-sms-flow

---
name: waitlist-sms-flow
description: Builds the text message flow that tells a waitlisted guest their table is ready, keeping it strictly a service message under the Privacy and Electronic Communications Regulations 2003 unless it carries an offer, in which case it checks the soft opt-in conditions before anything is sent. Built on a measured finding that a delivered SMS reminder is associated with a materially lower no-show rate, and never attaches marketing content to a table-ready text without separately checking the legal basis for that content. Use when setting up or auditing the texts your waitlist or booking flow sends.
---

# Text the wait, not the apology

Give it the waitlist flow's message templates and when each fires. Get back each message classified as service or marketing, the soft opt-in check for the second category, and the measured reminder effect that justifies the text at all.

## What it does

1. **Know the measured reason to send the text.** A booking-platform measurement found "reservations with a delivered SMS reminder showed a 16% lower recorded no-show rate", stated as "an observed association... not a controlled experiment."

2. **Classify every message as service or marketing first.** "Your table is ready" is a service message. Add "here's 10% off your next visit" and the whole message is marketing, not just that line.

3. **Treat any marketing content as subject to the soft opt-in, in full.** Regulation 22 restricts unsolicited marketing by electronic mail (covering SMS) "unless the recipient... has previously notified the sender that he consents", unless the details were "obtained... in the course of the sale or negotiations", the marketing is for "similar products and services only", and a "simple means of refusing" was given at collection and at each later message.

4. **Keep the opt-out live on every marketing message**, not only the first.

5. **Keep pure service messages free of the marketing check, deliberately**, so neither a genuine notice is over-blocked nor a genuine offer under-checked.

6. **Use the standard automated-reminder pattern**, within that boundary; platforms are described as using "automated reminders and estimated wait times" to keep guests informed.

## Then it checks

1. Every template is classified `service` or `marketing`, with the reason stated.
2. Every `marketing` template has a recorded soft opt-in basis.
3. Every `marketing` template shows the opt-out in that message.
4. No `service` template contains an offer or promotional line.

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 send a marketing-classified text without a recorded soft opt-in basis and a working opt-out in that message.
- Never claim an SMS reminder is proven to cause fewer no-shows; it is an observed association, stated that way every time.
- Working document for the owner's data protection adviser to confirm the lawful basis for any marketing content.

## Built from
- Resos, "No-Show Index 2026", resos.com/restaurant-no-show-rate/, 19 Aug 2026, read 4 Nov 2026: step 1.
- Privacy and Electronic Communications Regs 2003, reg.22, legislation.gov.uk/uksi/2003/2426/regulation/22, read 4 Nov 2026: steps 3 and 4.
- Eat App, "Why Don't Restaurants Take Reservations?", restaurant.eatapp.co, 10 Mar 2025, read 4 Nov 2026: step 6.

# waitlist-sms-flow

## You are given
Every SMS template used in the waitlist or booking flow, with the exact text and the trigger that fires it (`joined waitlist`, `table ready`, `booking reminder`, `other`). The classification already made by Claude for each template: `service` or `marketing`, with the reason. For each `marketing` template, how the phone number was collected, what product or service the marketing is for, and where the opt-out appears in the message. The consent or collection record for recipients, if available.

## Produce
Write into a `./waitlist-sms-flow-output/` folder:

1. `message-classification.csv` with columns: `template_ref`, `trigger`, `message_text_verbatim`, `classification`, `classification_reason`, `contains_offer_words`, `offer_words_found`. `classification` is `service` or `marketing`. `contains_offer_words` searches the literal tokens `off`, `discount`, `free`, `offer`, `% off`, `voucher`, `come back`, `next visit` and records every hit with its position.
2. `soft-opt-in-check.csv` with columns: `template_ref`, `details_collection_context_verbatim`, `marketing_is_similar_products_only`, `opt_out_present_in_message`, `opt_out_text_verbatim`, `opt_out_offered_at_collection`, `outcome`. The three `yes`/`no` columns are `marketing_is_similar_products_only`, `opt_out_present_in_message`, `opt_out_offered_at_collection`. `outcome` is exactly one of `not applicable, classified as service`, `soft opt-in conditions met`, `soft opt-in conditions not met`.
3. `reclassification-flags.csv` with columns: `template_ref`, `original_classification`, `reason_for_flag`, `recommended_classification`. One row for any template where `message-classification.csv` shows `classification` of `service` but `contains_offer_words` found a hit, or vice versa.
4. `gaps.md` - a numbered list of: every row in `reclassification-flags.csv`; every `marketing` template with an `outcome` of `soft opt-in conditions not met`; any `marketing` template with no `opt_out_text_verbatim` recorded; any template with no `trigger` recorded.

## Rules
- Codex classifies by rule, checks and records. It never decides the underlying legal classification method - that is supplied by Claude - it only applies the offer-word search and the soft opt-in field checks mechanically.
- Never mark `soft opt-in conditions met` without all three of `marketing_is_similar_products_only`, `opt_out_present_in_message`, and `opt_out_offered_at_collection` being `yes`.
- Never write or suggest message text; it only reads and classifies the text it is given.
- Token searches are literal, case insensitive, and record the position of every hit.
- Use British English and DD Month YYYY dates. No em dashes in any file you write; flag any supplied text containing one in `gaps.md`.
- Every file ends with this line: this is a working document prepared for the owner to check against their own data protection and marketing policies, and for their solicitor or data protection adviser to confirm the lawful basis for any marketing content. It is not legal advice.

## Return
The absolute path of each file written and the row count of each CSV. Every template's classification and whether an offer word was found that contradicts it. The soft opt-in outcome for every marketing template. The full list of reclassification flags. The `gaps.md` item count.