FoxeraTurn tables faster without rushing anyone: 10 AI skills for the waitlist
table-turn-timer
know when a table has earned its bill, not guess it
How the two work together
Claude thinks it through. Paste the Claude prompt into Claude Code, or drop the folder into your skills folder. Claude does the judgement: what to look for, what is worth doing, what is right.
Codex gets it done. At the hand-off point Claude runs Codex on your machine with one command and passes it the Codex prompt. Codex does the mechanical part and hands the result back. Claude checks it before you see it.
No API key to set up: Claude calls the Codex you already have installed. If Codex is not installed, Claude does that half itself and tells you.
Prompt for Claude
--- name: table-turn-timer description: Sets a target turn time per meal period from real published benchmarks rather than a manager's gut feeling, tracks the actual seated-to-cleared time against it, and flags a table running over without ever producing a message that tells a guest to hurry. Separates the two numbers operators confuse, table turnover rate and table turn time, and never lets a flag reach front of house phrased as anything but a staffing cue. Use when setting how long a table should take, or deciding whether a table is genuinely overdue. --- # Know when a table has earned its bill, not guess it Give it the meal period, party size and seated time. Get back a target clear time built from a stated benchmark, the actual elapsed time as it runs, and a staff-only flag the moment it passes target. ## What it does 1. **Separate turn time from turnover rate.** Turnover rate is "number of tables served / number of physical tables" across a whole service; turn time is how long one table takes. A target set for one must never be derived from the other. 2. **Set the target from a stated benchmark.** For casual dining: drink order "within 2 minutes of seating", drinks "delivered within 5 minutes of ordering", entrée "15-20 minutes after order." Fine dining: first course "12-15 minutes after ordering", "8-12 minutes" between courses. 3. **Check the assembled target against a whole-visit figure.** One guide gives "around 45 minutes" as the ideal fast turn; another gives "1.5 to 2 hours" as the "typical allotted time" for traditional dining. The gap is real; state which service style applies. 4. **Track the actual time, not an estimate of it.** Record seated and cleared time per table; compute elapsed minutes directly. 5. **Flag the table, never the guest.** The only output is a staff-facing note; nothing here ever becomes a line a server says to a table. 6. **Feed real elapsed times back into tomorrow's target**, rather than keeping a fixed number regardless of what actually happens. ## Then it checks 1. Every target states its benchmark source and service style. 2. Turn time and turnover rate are never calculated from each other. 3. Elapsed time on a flagged table is a real calculation, not a guess. 4. No flag contains wording a server could say to a guest. 5. The target updates from the venue's own recorded times. 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 produce a message worded for a guest; every flag is staff-facing only. - Never claim a single national average turn time; no verified UK figure exists. - Working document for the owner to check against their own service style and menu. ## Built from - Nine Guides, "Speed of service benchmarks", nineguides.pages.dev, 7 Mar 2026, read 4 Nov 2026: step 2. - Tablein, "Table turnover guide", tablein.com/blog/table-turnover-guide, read 4 Nov 2026: steps 1 and 3. - The Restaurant HQ, "Table Turnover", therestauranthq.com/operations/table-turnover, read 4 Nov 2026: steps 1 and 3.
Prompt for Codex
# table-turn-timer ## You are given The meal period and service style, classified by Claude. The target turn time in minutes for that period and style, with its benchmark source. A list of tables: reference, party size, seated time, cleared time (or blank if still seated). The current time, for elapsed-time calculation on uncleared tables. ## Produce Write into a `./table-turn-timer-output/` folder: 1. `targets.csv`: `meal_period`, `service_style`, `target_minutes`, `benchmark_source`, `benchmark_components`. `benchmark_components` lists the course-stage figures assembled, semicolon-separated (e.g. `drink order:2min;entree:15-20min`). 2. `table-log.csv`: `table_ref`, `party_size`, `seated_time`, `cleared_time`, `elapsed_minutes`, `status`. `status` is one of `cleared on target`, `cleared over target`, `running on target`, `running over target`. 3. `staff-flags.csv`: `table_ref`, `elapsed_minutes`, `target_minutes`, `minutes_over`, `flag_text`. Only "over target" tables appear. `flag_text` is a short staff note (e.g. "Table 4: 12 minutes over target") and must never address a guest directly. 4. `rolling-average.csv`: `meal_period`, `service_style`, `date`, `average_actual_minutes`, `target_minutes`, `variance_minutes`. Appended daily, never overwritten. 5. `gaps.md` - a numbered list of: any table with no benchmark source; any `flag_text` with guest-directed wording; any `cleared_time` earlier than `seated_time`; any meal period with no target. ## Rules - Codex calculates, flags and records. It never sets the target minutes or benchmark components; those are supplied by Claude. - Never write a `flag_text` that could be read aloud to a guest; every flag is a staff note, never a message to the table. - Elapsed minutes are calculated exactly from the supplied timestamps, never estimated. - 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 service style and menu, and is not a guarantee any guest will be served within the stated times. ## Return Each file's absolute path and row count. The target and benchmark source per meal period and style. The number of tables per status. Every staff flag, with table reference and minutes over. The rolling average against target for the day. The `gaps.md` item count.
Built from the best public work on this
Sources for table-turn-timer
Everything below was opened and read on 4 November 2026.
1. Nine Guides, "Speed of service benchmarks"
https://nineguides.pages.dev/operations/speed-of-service-benchmarks, operations guide, dated 7 March 2026, read 4 November 2026.
Gives course-by-course timing benchmarks by service type. For casual dining: a drink order should be taken "within 2 minutes of seating," drinks "delivered within 5 minutes of ordering," food "ordered within 5 minutes of drinks delivered," an entrée delivered "15-20 minutes after order," and the check "delivered under 2 minutes after signal." For fine dining: the first course arrives "12-15 minutes after ordering," with "8-12 minutes" between later courses "depending on guest pace preference." It also states two rules of thumb: the "30/30/30 rule" (acknowledge within 30 seconds of seating, take the drink order within 30 seconds of acknowledgment, deliver drinks within 30 seconds of the order) and the "201 rule" (acknowledge arriving guests within 20 seconds, seat within 1 minute when a table is available).
Used in step 2, as the building blocks a whole-visit target is assembled from, course by course rather than as a single invented figure.
Where the skill departs: the guide also covers quick-service and drive-through benchmarks, which are outside the scope of a sit-down table turn and are not used here.
2. Tablein, "Table turnover guide"
https://tablein.com/blog/table-turnover-guide, published 2 August 2023, last modified 12 December 2024, read 4 November 2026.
Gives the turnover rate formula as "Divide the number of parties served by the number of available tables," and states that "the ideal time before turning a table is around 45 minutes," noting that tips tend to rise with time spent until the "40- to 50-minute mark" and meal costs begin to decline around the "30- to 40-minute mark."
Used in steps 1 and 3: the formula for the turnover rate calculation, kept distinct from turn time, and the faster-paced "around 45 minutes" benchmark used for a fast or casual-paced check.
Where the skill departs: this guide gives one single ideal figure without breaking it down by service style; the skill uses it as one of two figures compared against each other (with source 3) rather than treating it as universal.
3. The Restaurant HQ, "Table Turnover: What It Is & Tips to Improve It"
https://www.therestauranthq.com/operations/table-turnover/, published 15 July 2024, last updated 19 June 2025, read 4 November 2026.
Gives a second, independently worded turnover rate formula: "Number of tables served / Number of physical tables = Table turnover rate." For traditional full-service dining it states "1.5 to 2 hours is the typical allotted time," which is 90 to 120 minutes.
Used in step 3, as the slower, traditional-dining benchmark deliberately set against source 2's faster figure, to show the two are not interchangeable and a target must state which service style it is for.
Where the skill departs: the article's guidance also covers general restaurant layout and staffing tips unrelated to timing, which the skill does not use.
Best public prompt we found for this job
The closest public artefact is the `schedule-meeting` skill in Anthropic's `knowledge-work-plugins` repository, raw source at https://raw.githubusercontent.com/anthropics/knowledge-work-plugins/main/sales/skills/schedule-meeting/SKILL.md. The repository has 34,655 stars, read from api.github.com on 4 November 2026. It is a calendar-scheduling skill, not a dining-service skill, but the job shares a shape: fit a fixed-length slot into a constrained, moving schedule and respect a set of rules while doing it.
The useful part is its discipline about proposing real, checked slots rather than a generic window: it is written to "Propose 2-3 specific times, avoiding existing blocks and respecting working hours," and to "Honor customer preferences the user has stated before (timezone, no Fridays)." We took the underlying idea, that a time estimate is only useful if it is checked against what else is actually booked, into the table timer's use of real elapsed times rather than a static assumption.
We did not copy two things. `schedule-meeting` proposes times to a single counterparty who can simply say no to a bad slot; a table turn target is enforced on dozens of parties at once who never see or negotiate it, so the skill is built to never let its output reach a guest at all, which has no counterpart in a meeting-scheduling tool. And `schedule-meeting` has no equivalent of the turnover-rate-versus-turn-time confusion that this skill exists partly to prevent; a calendar slot has only one duration, while a dining room has two different numbers that look alike and are frequently swapped in off-the-shelf hospitality advice.
Want this running in your business?
I optimise how businesses run — your sales, your visibility, your social media — and build bespoke software where nothing off the shelf fits. The first conversation is free. Work starts from £150 a day.