Party Size & Seating Validation (Restaurants)

Paid pluginsize Mplanned, not built

Indicative price, not an offer: €19/mo; table capacity rules, seating suggestions, turn-time optimization

Generated from docs/plan/paid/party-size-seating-validation/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Table management and seating logic for restaurants. Define table sizes, capacity, and seating combinations (e.g., tables 2+3 combine for party of 5). Prevent overbooking and suggest optimal seating. Reservation system with auto-population of suggested tables. Admin manages floor map, sees occupancy in real-time, tracks turn times.

The problem

Table 2 can’t seat party of 8; hostess manually tries different table combos, often fails. Without seating logic, overbooking happens (two parties assigned same table), guests wait longer, turn times suffer. No visibility into which tables are available, leading to guesswork.

What it does

• Table master (define tables, capacity, section, shape)
• Seating combinations (define which tables can combine, combined capacity)
• Reservation with party size
• Availability check (given date, time, party size → available slots)
• Seating suggestion algorithm (suggest matching tables for party)
• Reservation status tracking (booked/seated/closed)
• Manual seating override (staff can assign different table)
• Turn time tracking (duration from seated to closed)
• Overbooking prevention (no double-booking single table)
• Admin floor map view (see current occupancy)

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Visual floor plan editor (drag/drop layout) — UI complexity, limited ROI. Reason: staff uses sketches, rarely updates.
• POS system integration (Toast, Square, Lightspeed) — vendor lock-in, no standard API. Reason: each vendor has custom integration.
• Revenue optimization (expensive tables first) — fairness concern. Reason: ethical boundary.

Data model

New tables: tables (tableId, section, name, capacity, shape). seating_combos (comboId, tables (array of tableIds), combined_capacity). Reservation schema: add partySize, seatedTableIds (array), seated_at, closed_at. turn_times (reservationId, tableId, duration_minutes, seated_at, closed_at). Occupancy tracking (current reservations per table). Migration: add tables + indexes on date+time for availability queries.

API

• GET /api/tables
• GET /api/availability
• POST /api/reservations
• GET /api/reservations/{reservationId}
• POST /api/admin/tables
• POST /api/admin/seating-combos
• PUT /api/admin/reservations/{reservationId}/seating
• POST /api/admin/reservations/{reservationId}/close
• GET /api/admin/turn-times-report

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Table management (add/edit/delete, set capacity). Seating combo builder. Reservation list (by date, status, party size). Floor map view (occupancy heatmap). Turn-times dashboard (average, by section, peak hours). Availability calendar.

The seam — why this is paid

Core owns: reservation + table schema, availability logic, reservation status. Paid pack owns: seating suggestion algorithm, turn-time analytics, combo management.

Support commitment: seating algorithm, turnover analytics, SLA management

Dependencies

• Reservation/booking system
• Availability calculation engine

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• Restaurant has tables: 2-top (x4), 4-top (x6), 8-top (x2)
• Party of 5 books; system suggests table 4 + table 2 (combined 6)
• Party of 8 books; system assigns 8-top
• Status progresses: booked → seated → closed
• Turn-time report: average 75 min, peak 7-9pm is 60 min
• Two reservations cannot book same table at overlapping times
• Deleting seating combo re-suggests affected reservations
• Availability calendar shows Sept 1 (50% capacity), Sept 2 (90%)
• Staff manually overrides seating; system allows + logs override
• Turn-time only recorded after reservation closed

Risks

Overbooking logic fails: two staff book same table simultaneously. Seating suggestion too slow (30 tables, combos calc takes 10 sec). Turn-time calculation includes canceled reservations (skews average). Combo capacity wrong (defined 5, actually seats 4). No idempotency: double-click books twice.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.