Table Reservation Calendar (Restaurants)

Paid pluginsize Mplanned, not built

Indicative price, not an offer: €34/mo; table map, availability sync to Google/Facebook

Generated from docs/plan/paid/table-reservation-calendar/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

A paid feature for restaurants and cafes: a calendar-based table reservation system with no-show tracking, table map management, multi-day availability sync to Google Business and Facebook, and real-time double-booking prevention. Restaurants stop managing reservations in spreadsheets.

The problem

A Greek restaurant uses a spreadsheet to manage table reservations: 6 tables, 40 bookings a day. Customers reserve on Google Business, Facebook, and call directly. Owner double-books tables constantly, misses confirmations, and loses revenue. She pays €45/month for a dedicated service (Yelp, OpenTable) but they take a 3-4% commission on orders.

What it does

• Table map editor: add/remove tables, set capacity per table (2/4/6 seats), seat arrangement (round/rectangle/booth)
• Calendar view: 7-day/30-day, drag-and-drop to create reservations, color-coded by party size
• Reservation fields: name, phone, party size, time, special requests, confirmed/cancelled/no-show status
• Double-booking prevention: block tables when a reservation exists; show available tables only
• Sync to Google Business: 7-day availability, customer can book via Google Search/Maps
• Sync to Facebook: 7-day availability, customer can book via Facebook event page
• No-show tracking: mark reservations no-show, calculate no-show rate per customer
• SMS confirmation: send auto-confirm to customer on booking (links to confirmation URL)
• Overbooking intelligence: allow merchant to manually overbook (e.g., expect no-shows), flag high-risk bookings
• Reports: daily covers by table, revenue per day, no-show rate, peak hours

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.

• Waiter/kitchen display system (POS integration)—out of scope; third-party POS handles this
• Customer loyalty or recurring-reservation programs—handled separately
• Menu integration (customers can’t order drinks/appetizers during booking)—POS handles this
• Catering and group events (>20 people)—out of scope, too specialized
• Delivery/takeaway (separate feature if needed)

Data model

New: Table(shopId, table_number, capacity, arrangement_type, location_in_venue); Reservation(id, shopId, tableId, customer_name, phone, party_size, reserved_time, confirmed_at, no_show_at); ReservationSync(id, reservation_id, platform, sync_status, sync_error). Requires schema migration.

API

• GET /tables — list all tables for this restaurant
• POST /tables — create new table
• PUT /tables/:id — update table (capacity, arrangement)
• GET /availability/:date — return available tables (by time slot)
• POST /reservations — create new reservation
• PUT /reservations/:id — update (confirm, cancel, no-show)
• GET /reservations/:date — list all reservations for date
• POST /sync/google-business — trigger sync to Google
• POST /sync/facebook — trigger sync to Facebook
• GET /reports/covers/:date — covers by table/time

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

Admin

Reservation dashboard: calendar view (7-30 day), table map showing occupied tables (color-coded), drag-to-create reservation, sync status (Google/Facebook), no-show rate chart, reports (daily covers, peak hours, no-show trends)

The seam — why this is paid

Core owns: table management, reservation storage, double-booking logic, SMS sending. Paid pack owns: Google Business/Facebook sync API credentials, no-show intelligence, overbooking recommendations, premium support.

Support commitment: reservation sync, no-show tracking, table-turnover analytics

Dependencies

• SMS layer (must be available to send confirmations)
• Google Business API credential (paid pack provides)
• Facebook API credential (paid pack provides)

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.

• A table (capacity 4) at 19:00 is reserved; attempting to reserve same table at 19:15 fails (‘table not available’)
• A reservation created in admin appears on Google Business within 2 hours (sync)
• A customer books via Google Business; reservation appears in admin calendar within 30 minutes
• A no-show reservation on 2025-09-02 is marked no-show; no-show rate shows 1 no-show in daily report
• A reservation receives SMS confirmation with link to confirm/cancel; clicking link marks as confirmed
• Deleting a table (capacity 4) that has a future reservation fails with error ‘table has active reservations’
• Daily covers report for 2025-09-02 shows: Table 1: 3 covers, Table 2: 4 covers, etc. (total = sum of party sizes)
• Syncing to Facebook is triggered; sync status shows ‘in progress’, then ‘success’ within 5 minutes

Risks

Double-booking logic bug: if a table is booked, it still appears as available—merchants lose revenue. Google/Facebook sync latency: customer books via Google, admin doesn’t see it for hours. No-show tracking doesn’t match reality (e.g., customer arrives but is no-show in system). SMS delivery failure: customer never gets confirmation. Table map editor too complex (merchant can’t add tables).

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.