Skip to content

Tablez — Technical Analysis

Source: Tablez Specification v1.2 (shared by Daniel R. Döderlein, Tabelz AS) Reviewed: 2026-02-24 Reviewer: Claude-6 / Codi-E Status: Pre-engagement — evaluation only

What Is Tablez

An AI-driven restaurant reservation and guest engagement platform. Restaurants configure their layout, services and booking rules; guests book via web form, AI chat, AI phone agent, or email; staff operate a live floor view with real-time table status.

The differentiator is the LLM layer — every guest-facing channel (phone, chat, email) is handled by an AI agent backed by a tool-based API. The backend is always the source of truth; the LLM only talks to guests and calls tools.

System Map

Channels (guest-facing)
├── Web booking widget (form)
├── Web chat widget (LLM)
├── AI phone agent (LLM + STT/TTS)
├── Email agent (LLM)
├── Google Reserve (partner API)
└── Walk-in / staff direct entry

                    │
                    ▼

Core Platform (backend)
├── Restaurant configuration
│   ├── Profile & users
│   ├── Floor plan (zones + tables + canvas)
│   └── Service schedule (per-date rules)
├── Reservation engine
│   ├── Availability check
│   ├── Table assignment (auto + manual)
│   ├── Lifecycle management
│   └── Waitlist queue
├── Guest database (CRM)
│   ├── Identity + contact
│   ├── Preferences + allergies
│   └── LLM-enriched notes
└── LLM tool API (Section 11)
    ├── check_availability
    ├── create_reservation
    ├── create_waitlist_entry
    ├── cancel_waitlist_entry
    ├── get_service_overview
    ├── get_service_details
    ├── get_guest_profile
    └── update_guest_profile

                    │
                    ▼

Staff dashboard
├── Live floor view (table statuses)
├── Reservation list
├── Manual reservation entry
└── Override controls

What the Spec Gets Right

LLM Tool Architecture (Section 11)

This is the strongest part of the document. The design is correct:

  • LLM receives only lightweight static context at startup (restaurant ID, current datetime, channel type)
  • All dynamic data (availability, menus, service rules) fetched via tools on demand
  • LLM never confirms a booking on its own — always calls create_reservation
  • Tools are designed to be minimal and stateless

This is exactly how a production AI booking agent should be built. It prevents hallucinated availability, keeps prompts small, and ensures menu/event changes propagate immediately.

Waitlist Design

The waitlist behavior is well thought through:

  • Queue ordered by creation time + time window compatibility
  • Slot opens → SMS link sent → temporary hold → guest completes or hold expires
  • Guest specifies flexible window (earliest + latest acceptable time)
  • Position shown as non-exact hint (not a precise number that becomes stale)

Reservation Lifecycle

Creation → edit → cancellation → arrival → no-show is fully defined. Editing is treated as re-creation (free old capacity, re-check, update in place) — correct approach that avoids partial-state bugs.

Guest Database

First-party CRM built in from day one. LLM enrichment during conversation (allergies, preferences, VIP signals) stored automatically. This is the long-term moat for the product — restaurants gain a guest intelligence layer they don't get from OpenTable or Google Reserve.

Gaps

Critical — Blocks MVP

Gap Detail
Payment provider Ticketing and no-show fees are described in detail but no provider is named. Stripe at minimum; local payment methods (Apple Pay, Google Pay, regional wallets) per market. Payment flow (webhook, hold vs. charge, refund) is unspecified.
SMS provider SMS confirmation links, waitlist notifications, payment links — SMS is used everywhere. Provider not named. Twilio and Vonage are international; regional providers can be layered per market.
AI phone agent stack "Calls handled by AI" with no STT, TTS, or telephony provider. This is a significant integration. Options: Twilio Voice + Deepgram + ElevenLabs, or a managed voice AI platform (Bland.ai, Vapi.ai).
GDPR / data privacy EU market, Norwegian restaurants, guest phone + email stored. No mention of data retention policy, consent model, right to deletion, or privacy policy. Required before any guest data is processed.

Major — Needs Decision Before Architecture

Gap Detail
Tech stack No mention of backend language/framework, database, hosting, or frontend framework.
LLM provider GPT-4o? Claude? Gemini? Matters for tool-call support, latency, cost, and Norwegian language quality.
Multi-tenancy model Multiple restaurants implied throughout but the isolation model is not defined (shared DB with restaurant_id scoping vs. per-tenant schema).
Real-time infrastructure Floor view requires live table status updates. WebSockets? Server-sent events? Not addressed.
Race conditions on availability Two guests checking availability simultaneously for the same slot — how is a slot locked during create_reservation? Optimistic lock? Database transaction?
Google Reserve Marked as "requires partner verification." This is an external business dependency with its own timeline. Not a code problem — needs to be treated as a separate track.

Minor — Fine to Defer

Gap Detail
Auth detail OAuth mentioned but JWT/session strategy not defined
Admin notification model No mention of how staff are notified of new bookings
Reporting No analytics or export in MVP (listed as future)
API versioning External partners (Tripadvisor, Meta) imply a public API — no versioning strategy

MVP Scope Assessment

The spec labels everything as MVP. It is not. This is a phase 1 + phase 2 product if built with a small team.

Phase 1 — Core Booking Platform

  • Restaurant profile, users, service schedule
  • Web booking form (no AI, just form)
  • Staff dashboard: reservations list, manual entry, table status
  • Basic table management (no canvas floor plan editor)
  • Guest database (manual creation, no LLM enrichment yet)
  • SMS confirmations
  • Waitlist (manual, no AI)

Phase 2 — AI Channels + Full Floor Plan

  • Web chat widget (LLM)
  • AI phone agent
  • Email agent
  • Floor plan canvas editor
  • LLM guest enrichment
  • Google Reserve integration
  • No-show fee processing

Rationale: The floor plan canvas editor is a complex drag-and-drop UI (weeks of work on its own). The AI phone agent requires STT + TTS + telephony + LLM + latency tuning. Neither is required to take first reservations.

Complexity Flags

Things in the spec that look simple but are not:

Floor plan canvas — Grid-based drag-and-drop editor with table merging, rotation, and real-time occupied state. Comparable in scope to a simplified Figma or Miro canvas. Not a weekend feature.

AI phone agent — Real-time voice with sub-second response latency, Norwegian language support, graceful handling of interruptions, background noise, and accents. Needs careful provider selection and significant prompt tuning.

Concurrent availability — Two guests booking the same slot simultaneously must not result in double-booking. Requires database-level locking or a reservation token pattern. Easy to get wrong.

Waitlist timing — When a slot opens, the system must find the best matching waitlist entry (party size + time window), send an SMS, start a hold timer, and release if no response — all without race conditions across potentially many concurrent waitlist entries.

Open Questions

Before any architecture or timeline discussion:

  1. Engagement model — Build-for-hire, co-venture, or evaluation?
  2. Daniel's role — Is he the CEO/founder of Tabelz AS, or is this a spec for a client?
  3. Timeline expectation — What's the target for first bookable demo?
  4. Market — Single-country launch or international from day one? Which markets first?
  5. Budget — Is this funded, self-funded, or pre-revenue?
  6. Designer — Is there a UX designer involved, or does that land on us?
  7. Existing codebase — Is anything already built, or greenfield?
  8. Norwegian language requirement — Must the AI agents support Norwegian fluently from day one?

Suggested Next Steps

If we move forward:

  1. Answer the open questions — engagement model and scope must be clear before any tech decisions
  2. Agree on phase 1 scope — cut the canvas editor and AI phone agent from MVP
  3. Select payment + SMS providers — Stripe + Twilio as the international baseline; layer local payment methods per market
  4. Draft architecture doc — backend stack, database model, auth, hosting
  5. Spike the LLM tool API — Section 11 is already well-defined; a working prototype of check_availability + create_reservation + chat agent can validate the approach quickly
  6. GDPR baseline — privacy policy, data retention rules, consent model before any guest data is stored

References

  • Spec source: Tablez Specification v1.2 (Tabelz AS)
  • LLM tool pattern reference: Section 11 of spec
  • Related: OpenTable, SevenRooms, Eat App (competitive context)