Tables & Reservations in Meztezz: A Complete Owner's Walkthrough

Tables and reservations are where a restaurant POS earns its keep on a busy evening. Get them wrong and your floor turns into a guessing game — orders on the wrong bill, two parties shown to the same booking, a captain hunting the host for “which table again?”. Get them right and the system disappears into the background while service flows.

This guide is an exhaustive, plain-English walkthrough of every table and reservation feature Meztezz currently ships with — and, just as important, an honest list of what it doesn’t yet do. Read it once when you set up the floor, then come back to specific sections when a tricky situation comes up mid-service.

💡 Where this lives in the app. Day-to-day floor operations happen on the Tables screen, opened from the Select Table button on the billing view. Inside that screen, three tabs across the top let you switch between Tables, Reservations and Waitlist — and that’s where creating, editing and managing all three happens. Behaviour-level tuning lives under Settings → Reservations and Settings → QR Ordering. Owner-level reports for both features sit under More → Reports, with cloud-wide reports mirrored on app.meztezz.com.

Part 1 — The Floor at a Glance: Reading the Table Grid

The Table Grid is the screen your floor staff will look at more than any other. It’s a colour-coded view of every table you’ve defined, grouped by section, with a summary bar across the top.

1.1 The Four Table Statuses

Every table is always in exactly one of four states. There are no others.

Status	Card colour	What it means
Available	Green	Empty, clean, ready to seat a party. Shows the table number and seat capacity.
Occupied	Red	A live order is open on this table. Shows the table number, the running order total, and the order number — formatted as `#<terminal-id>-<n>` (e.g. `#T1-42` for terminal `T1`, order 42). The terminal prefix is configured per install.
Reserved	Yellow	A confirmed reservation is pinned to this table. The card shows a `📅 HH:MM` pill with the booking time and the guest’s name for the whole reserved window. Once the booking time passes but the guest hasn’t arrived, the pill turns amber and counts how late they are (e.g. `+12m`) until the no-show grace period lapses.
Blocked	Grey	Out of service for some reason (broken chair, deep-clean, repurposed for an event). Can’t be clicked to start an order.

Above the cards is a summary bar with live counts in each colour — useful when the manager wants to glance across and see “12 available, 18 occupied, 4 reserved” without scanning the whole grid.

1.2 Sections Are Just Labels (Not Floors)

Each table belongs to a section — a free-text label like Main Hall, Patio, Rooftop, AC, Non-AC. The grid renders these as tabs across the top, plus an All Sections tab. Each section tab shows how many tables in that section are currently available, so the host can pick the best zone at a glance.

💡 Sections are flat, not hierarchical. Meztezz does not currently model “Floor 1 → Wing A → Section 3”. A section is one string per table. If you have a multi-storey restaurant, embed the floor into the section name — Ground - Hall, First - Hall, Terrace — and that ordering will show up cleanly on the tabs.

1.3 What Each Card Shows You — In Detail

Beyond the colour and status, the table card surfaces a few small signals you should learn to spot:

Edit pencil (top-left of every card) — the structural edit dialog. The pencil is always shown; the table:manage permission is checked when you save — without it the dialog opens but the save is refused (unlike the three-dot menu below, whose options are hidden outright per permission). While the table is available it lets you change number, section and capacity; while occupied it’s effectively read-only because structural changes mid-service aren’t safe.
Three-dot menu (bottom-right of an occupied card) — the in-service context menu, gated only by table:update_status (plus the specific permission for Merge / Split / Transfer). Lists: Merge Tables, Split Table, Transfer Order, then a divider, then Change Covers and Table Notes. Floor staff use this menu — not the pencil — for the running-shift updates like notes and covers. Each option appears only if your user role has the matching permission.
Lock badge — appears when another terminal in the restaurant is actively editing the same table’s order. Prevents two captains overwriting each other.
“Repay” badge — appears on an occupied table whose order has a cancelled payment. A signal to the cashier that the bill needs to be re-collected before close.

💡 There is no drag-and-drop floor plan. The grid is a sorted, responsive list of cards — by section first, then by table number. There is no canvas where you draw your dining room. If your floor plan is unusual (round bar, banquet hall, food truck window), use descriptive table numbers and sections rather than expecting a visual layout — e.g. Bar-1, Bar-2, Banquet-A1, Banquet-A2.

Part 2 — Setting Up Your Tables

Done once on a fresh install, then occasionally as your floor changes.

2.1 Creating a Table

You’ll need the table:manage permission (Owner and Manager roles have it by default).

Each table requires three things:

Field	Notes
Table number	Free text, must be unique across the restaurant. Use whatever your team already says out loud — `1`, `A3`, `Window-2`, `Terrace-7`.
Section	The grouping label. Free text — reuse exact spelling for consistency (`Main Hall` and `Main hall` will become two tabs).
Capacity	Integer between 1 and 50. Used by the reservation flow to filter “which tables can fit this party?”. Be honest — over-stating capacity to “always show as bookable” will result in cramped seating and worse reviews.

2.2 Editing a Table

The edit pencil on each card opens the structural edit dialog (saving needs table:manage — the dialog opens for anyone, but the save is refused without it). Behaviour depends on the current status:

Table is available, reserved or blocked — you can change table number, section and capacity.
Table is occupied — structural fields are locked. Notes and covers for an occupied table are updated not from the pencil, but from the three-dot menu → Table Notes / Change Covers (those need only table:update_status). If you genuinely need to change the table’s number/section/capacity, finish or transfer the order first, then edit.

2.3 Deleting a Table

The delete action is only allowed on tables that are not occupied. Meztezz won’t let you delete a table that has an active order on it — for obvious reasons. If you genuinely need a table gone mid-service, block it instead and delete after close.

2.4 Permissions: Who Can Do What

Table operations are gated behind separate permissions so you can give a floor captain seating powers without giving them structural-edit powers.

Permission	What it unlocks
`table:manage`	Create, edit (structural), delete tables
`table:update_status`	Change status, update covers, update notes
`table:transfer`	Move an active order from one table to another
`table:merge`	Combine multiple tables’ orders into one
`table:split`	Move a subset of items off one table onto another check

In the context menu, options the current user lacks permission for are hidden, not greyed out — so don’t be alarmed if a junior cashier “doesn’t see” the Merge option; that’s by design.

Part 3 — Daily Operations on Tables

3.1 Seating a Party (Opening an Order)

Tap an available (green) card → the order screen opens for that table → start adding items. The moment the first KOT is fired, the table flips to occupied (red). The order number now appears on the card.

3.2 Covers — The Guest Count

When you flip a table to occupied, you can set covers (the number of guests actually seated). This matters because:

It feeds the “average cover” KPI in your reports — your spend-per-guest numbers depend on it.
It must not exceed the table’s capacity — Meztezz will reject the entry.

(Covers are stored on the order for that reporting; they aren’t printed on the bill or the KOT.)

Edit covers any time during service via the three-dot menu → Change Covers (requires table:update_status).

3.3 Table Notes

Free-text, up to 500 characters, only writable on occupied tables. Use it for the things that don’t belong on the KOT — “guest is regular, comp the dessert”, “anniversary — bring out a candle”, “table wobbles, send maintenance”. Notes are visible to anyone who opens the table.

3.4 Releasing a Table

When the bill is paid and the order is completed, the table automatically flips back to available. You don’t have to “release” it manually. (Important: a paid order whose food isn’t fully out yet is not completed — see the Getting Started guide for why these are two different states.)

3.5 Blocking a Table

Blocking marks a table as out-of-service. Blocked cards show grey and can’t be tapped to open an order. Use it for:

A broken table that’s getting repaired.
A table you’ve roped off for a private group later.
A staff meal area you don’t want billed against.

Status changes require the table:update_status permission. The blocked status is fully supported in the data model and rules — surface it through whichever menu your role exposes for status changes.

Part 4 — Three Power Moves: Transfer, Merge, Split

These are the operations that separate a “good enough” floor system from a real one. Each is auditable, atomic, and has guardrails to stop you destroying data.

4.1 Transfer — Moving an Order to Another Table

Use it when: the party wants to move, or you accidentally rang the order onto the wrong table.

What it does: takes the entire active order off the source (occupied) table and puts it on a destination (available) table.

Source table → flips to available, clears covers, notes and order link.
Destination table → flips to occupied, inherits the covers and notes from the source.
All active printed KOTs are automatically reprinted — meaning KOTs that have been printed and aren’t yet completed or cancelled. Each reprint carries a clear “TABLE CHANGED” banner so the kitchen knows the food now belongs to the new table. KOTs that already finished service or were cancelled before the transfer aren’t reprinted (there’s nothing to redirect).
A real-time event is fired to any connected KDS screen so the kitchen view updates without a refresh.

Required permission: table:transfer.

Constraints: source must be occupied with an active order; destination must be available.

4.2 Merge — Combining Multiple Tables Into One Bill

Use it when: two groups discover they know each other and want one bill, or a party that booked two adjacent tables is settling together.

What it does: moves all the items and KOTs from one or more source tables onto a single target table’s order. Source orders are cancelled with reason Merged into order #X; source tables release to available.

Required permission: table:merge.

Merge is blocked if:

Any source table already has a non-cancelled payment recorded (you can’t merge a partly-settled bill).
Any source order has a discount or offer applied. Both stack into the same check — if either is present on any source, the merge is refused.
The source and target orders have different billing tax snapshots — specifically, mismatched tax-inclusive flag, default GST rate, or liquor VAT rate at the time those orders were rung. Meztezz won’t quietly merge orders that were billed under different tax settings.

If any of these conditions apply, the system explains why the merge is refused rather than silently failing.

4.3 Split — Moving Some Items Off a Table

Use it when: a couple at a four-top wants to leave early and pay only for their items, or a corporate group needs the boss’s bill separated from the rest.

What it does: moves a chosen subset of items from a source occupied table onto either (a) a new order on an available table, or (b) a new takeaway check. A new order number is generated for the split.

Required permission: table:split.

Split is blocked if:

The source order has loyalty points already redeemed (those points are tied to the original bill).
The source order has a discount or offer applied (one combined check — either is enough to refuse the split).
You try to split all items (at least one must remain on the source).

❗ Audit trail on every power move. Every transfer, merge and split writes a record to the operations audit log on the terminal — who did it, which terminal, what was moved, when. This is what we’ll point at if a guest disputes a bill or if you suspect a staff member is masking voids as transfers. The log syncs to the cloud and is stored alongside your other operational data; a dedicated dashboard view for browsing it isn’t shipped yet, but the raw records are preserved for future tooling and for audit pulls on request.

Part 5 — Reservations: How Bookings Work

Reservations in Meztezz are a fully implemented module — not a placeholder. They flow from “phone rings” all the way through to “table billed”, with the right statuses captured at each step.

⚠️ License-gated feature. Reservations (and the walk-in waitlist) are part of the Waitlist & Reservations feature in your plan. If your current plan doesn’t include it, the reservations UI is hidden entirely. Check app.meztezz.com → Subscriptions to see what your current plan covers, or upgrade from there.

5.1 What Gets Captured When You Book

Open the Tables screen (via the Select Table button on the billing view), switch to the Reservations tab, and tap New Reservation. You’ll see:

Field	Required?	Notes
Customer	Yes	Must be an existing customer record. You can create a new customer inline — name + phone is enough. Name and phone are copied onto the reservation from that record.
Party size	Yes	Integer, 1–50.
Date	Yes	A date picker. Past dates are blocked.
Time	Yes	A free-form HH:MM input, with quick-select chips every 30 minutes from 10:00 to 22:30.
Table	No	Dropdown filtered to currently-available tables whose capacity is at least your party size. A reservation can be created without a table — assign it later.
Special requests	No	Free-text — “window seat”, “highchair needed”, “no nuts”.

💡 Reservations require a customer record — by design. This means every booking is tied to your customer master, so repeat guests and their history show up automatically in reports. A side benefit: when the captain opens an order on that seated table, the customer is auto-attached to the bill — no manual lookup at billing time.

What’s not captured (yet):

No deposit / advance payment field. If you take deposits over UPI, record it separately and treat the reservation as confirmed.
No source field. Meztezz doesn’t currently track “phone / walk-in / WhatsApp / online” as a structured field on a reservation. The closest workaround is to prefix the special requests — [via Zomato] window seat.

5.2 Auto-Confirmation (You Don’t Click “Confirm”)

When a staff member creates a reservation in Meztezz, it is immediately confirmed. There is no intermediate “pending → confirm” click step. The reasoning is simple: the staff member entering the booking is the confirmation authority — making them click twice would be friction without signal.

This also means there’s nothing to chase later. The list of upcoming reservations is the list of confirmed upcoming reservations.

5.3 The Six Statuses

Every reservation moves through this lifecycle:

Status	What it means	How it gets there
`pending`	Booked but not yet confirmed.	Rare in practice — only used if a reservation was created via an external channel.
`confirmed`	Booked and confirmed; awaiting the guest.	Default for reservations created on the terminal.
`seated`	Guest has arrived and been put on a table.	Set automatically when staff seat the reservation; the linked table flips to occupied.
`completed`	Service finished; bill paid.	Set automatically when the order on that seated table is paid/completed.
`no_show`	Reservation time has passed and the guest didn’t arrive.	Set manually, or automatically by the no-show watcher (see §7).
`cancelled`	Guest cancelled before the slot.	Set manually with a reason.

The system stamps a dedicated timestamp for each transition (confirmed_at, seated_at, completed_at, cancelled_at), which is how your no-show rate, cancellation rate and average-arrival-vs-booking-time stats are calculated downstream.

completed, no_show and cancelled are terminal states — once a reservation is in one of these, it can’t be revived. If a guest who was marked no-show actually shows up, create a fresh walk-in or a new reservation rather than reopening the old one.

5.4 Double-Booking Detection

Meztezz won’t let you book the same table for overlapping slots. The overlap window is computed as:

slot length = reservation_duration_minutes + reservation_buffer_minutes

Defaults are 90 minutes of dining + 15 minutes of buffer = 105 minutes per slot — both numbers configurable in Settings (§8). Two reservations overlap if their slot windows intersect at all. Cancelled and no-show reservations don’t block slots.

The check runs at create time and again whenever you edit table, date or time — so if a guest reschedules into a conflict, you’ll be told before you save the change.

There is also a database-level guard as belt-and-suspenders: a unique constraint prevents two active reservations on the same (table, date, time) from ever co-existing, even in the unlikely event two staff create them simultaneously on two terminals.

5.5 Restaurant-Wide Slot Capacity

Separately, you can cap how many concurrent reservations across the entire restaurant a single slot can hold — useful for a kitchen that can only push so many simultaneous covers no matter how many tables are free. Set max_reservations_per_slot in Settings (§8). The default is 0, meaning unlimited.

5.6 Duplicate-Customer Detection

Meztezz also prevents the same customer (matched by their normalized phone number, and by customer ID) from holding two active reservations at the same date and time. This catches the common case of a guest who calls twice forgetting they already booked, and accidental double-saves by staff.

Part 6 — The Reservation Day, In Practice

Here’s how a booked party flows through the system from morning open to bill paid.

6.1 The Upcoming-Reservations Alert

A live alert panel surfaces every confirmed reservation arriving within the next configurable window (default 30 minutes). It shows guest name, party size, time, and the assigned table — with a one-tap Seat action.

Set the warning window in Settings → Reservations using upcoming_reservation_warning_minutes. A bigger number gives staff more lead time; smaller keeps the panel clutter-free during a 100-cover lunch.

6.2 The Reservation Pill on the Reserved Card

If you’ve pinned a reservation to a specific table, that table’s card shows a yellow background (status: reserved) for the whole window between booking and arrival — and right alongside it, a 📅 HH:MM pill with the booking time and the guest’s name. So a 9pm booking viewed at 11am already shows yellow, the 📅 21:00 pill, and the guest’s name. Floor staff don’t have to memorise the upcoming list — the card itself says which tables are spoken for.

Once the booking time passes but the guest still hasn’t arrived, the pill turns amber and starts counting the minutes late (e.g. 📅 21:00 · +12m) for as long as you’re inside the no-show grace window (reservation_time + no_show_grace_minutes). After that grace window lapses the booking drops off the card — and if you’ve enabled auto no-show (§7), it’s marked accordingly.

6.3 The Walk-In Warning on an Occupied Card

Occasionally a walk-in lingers over coffee while a booked party is on the way. If a table is occupied and a confirmed reservation for that table is approaching within the alert window, the card shows an amber “upcoming” chip — a cue for the manager to start politely closing the current check.

6.4 Seating the Reservation

Two paths:

From the alert panel — tap Seat.
From the table grid — open the reserved (yellow) card and use the seat action there.

What happens under the hood, atomically:

Reservation status → seated, seated_at stamped.
Table → occupied.
A new order will, when started, auto-attach the reservation’s customer to the bill (no need to look the customer up at billing).
The order carries a reservation_id link back, so reports can join the two.

6.5 Auto-Completion at Bill Settlement

You don’t have to remember to mark a reservation as completed. When the order on the seated table is paid and completed, the linked reservation is automatically advanced from seated to completed. The whole funnel — booking → confirmed → seated → completed — happens with one human click (the Seat button) plus the normal bill flow.

6.6 Walk-Ins (Without a Reservation)

Walk-ins do not require a reservation record. The captain just opens an order on an available table and the system runs as normal. The reservation flow is for booked guests only; for spontaneous parties you can optionally use the Waitlist (§9).

Part 7 — Auto No-Show and the Grace Period

A reservation that’s both confirmed and past its time is a problem until somebody resolves it — and during a busy service nobody has the time. Meztezz handles this automatically if you switch it on.

Turn on auto_no_show_enabled in Settings → Reservations. The system will then, on a regular interval, find any confirmed reservation for today (or earlier) whose reservation_time + no_show_grace_minutes has elapsed, and:

Mark the reservation as no_show.
Release the reserved table back to available.

The grace period (no_show_grace_minutes) defaults to 30 minutes. A guest 10 minutes late won’t get marked off; a guest 35 minutes late with no contact will.

💡 Pick a grace period that matches your locality. In an Indian metro at 9pm where the guest is stuck in traffic, 45–60 minutes is humane. For a fast-turn lunch service where every minute is a cover, 15 minutes might be appropriate. There is no right answer — your no-show rate report (§10) will tell you over a few weeks whether you’ve set it too tightly.

Part 8 — The Settings Reference Card

Every reservation / table behaviour you can tune lives in Settings → Reservations (with a few QR-ordering settings overlapping in Settings → QR Ordering). Here’s the full list with defaults.

Setting	Default	What it controls
`reservation_duration_minutes`	`90`	How long a reservation occupies its table for overlap checks.
`reservation_buffer_minutes`	`15`	Cleanup / turnover time added on top of the duration.
`avg_table_turnover_minutes`	`45`	Used by the waitlist to quote a wait time to walk-ins.
`auto_no_show_enabled`	`off`	If on, late reservations are auto-marked no-show.
`no_show_grace_minutes`	`30`	How late before auto no-show kicks in.
`max_reservations_per_slot`	`0` (unlimited)	Restaurant-wide ceiling on concurrent reservations per slot.
`upcoming_reservation_warning_minutes`	`30`	How far ahead the alert panel highlights upcoming bookings.

QR-ordering settings (which intersect with tables because the QR is tied to a table number) are listed separately under Settings → QR Ordering.

Part 9 — The Waitlist (For Walk-Ins on a Busy Night)

Alongside reservations, Meztezz ships a walk-in waitlist under the same license feature. Different beast, different use case:

Reservations	Waitlist
Pre-booked, in the future.	Walk-in, here right now.
Linked to a customer master record.	Just a name + optional phone — no customer record required.
Six statuses, with double-booking and capacity guards.	Default status `waiting`; entries advance to `seated` when a table opens up, or are `cancelled` if the party leaves before being seated.
Slot math based on duration + buffer.	Wait estimate based on `avg_table_turnover_minutes`.

The waitlist panel shows parties in arrival order with their position number and a quoted wait. Seat them when a table comes free; the same flip-table-to-occupied logic kicks in.

Part 10 — Captain App: What It Can and Can’t Do

The Captain App (a phone / tablet client your floor staff use on the local WiFi) gets a deliberately narrower set of permissions than the POS terminal. For tables and reservations specifically:

Action	Captain App	POS Terminal
View tables and statuses	✅	✅
Open a new order on a table	✅	✅
Transfer / merge / split an order	❌	✅
Create or edit a reservation	❌	✅
View upcoming reservations	✅	✅
Seat a reservation	✅	✅
Mark a reservation no-show	✅	✅
View reservation detail	✅	✅

The reasoning is intentional: the captain app exists for speed-of-service moves a server makes on the floor, not for structural changes that ought to go through a cashier or manager terminal.

Part 11 — QR Ordering: Tables and Guest-Side Phones

Each table can carry a QR code that guests scan to open a menu on their phone (over your in-restaurant WiFi). It’s a separate feature from reservations, but it’s worth knowing the touchpoints because it lives on the same table model:

Codes are generated per table from the table number. The URL encoded into the QR points to the local terminal’s web server.
Whether QR ordering is enabled at all is controlled by qr_ordering_enabled in Settings.
Other QR settings — captain approval before KOT, multiple ordering rounds, requiring guest phone, showing alcohol items, session timeout — sit alongside in Settings → QR Ordering.
QR codes are generated for display so you can save / print them yourselves. Meztezz does not currently ship a one-click “print QR sticker per table” job.

Part 12 — Reports You’ll Actually Use

12.1 On the Terminal (`More → Reports → Reservations`)

For any date range you choose, the terminal’s Reservation Report gives you:

Total reservations in the window.
No-show rate as a percentage.
Cancellation rate as a percentage.
Average party size.
Status breakdown — how many were confirmed-only, how many seated, completed, etc.
Peak hours — which time-of-day slots saw the most bookings.
Day-of-week breakdown — Mondays vs. Saturdays at a glance.
Top cancellation reasons — so you can spot patterns (e.g. “weather” suddenly spiking).

12.2 On the Cloud Dashboard (app.meztezz.com → Reports → More → Reservations)

The cloud mirrors this with multi-outlet rollups and visual breakdowns:

Stat cards for total reservations, no-show rate, cancellation rate, average party size.
A bar chart of reservations grouped by status.
A status table (count and % of total).
Top cancellation reasons.
A daily breakdown table — total / completed / no-show / cancelled for each day in your range.

For tables specifically, the cloud dashboard doesn’t ship a dedicated “tables report”, because the interesting outcomes — orders, revenue per cover, peak occupancy — already live inside the Sales and Orders reports.

💡 Reservations don’t yet roll up to revenue. The reservation reports count bookings and rates; they do not currently join through to the linked order’s bill total. So you’ll see “12 reservations completed Saturday night” but not “Saturday night’s reservations generated ₹48,200 in revenue” in the same report. The order is already linked under the hood — this is a reporting addition we have on our list, not a data gap.

Part 13 — Honest List of What Meztezz Doesn’t Do (Yet)

We’d rather you know in advance.

No floor-plan visual editor. The grid is sorted cards, not a drag-to-position canvas. If your selling point is a beautiful interactive floor map, this is not it.
No floor / wing / room hierarchy. Sections are flat strings — bake hierarchy into the section name.
No SMS / WhatsApp / email reminders to guests about their reservation. All alerts are in-app for staff.
No public online booking widget. Reservations are created by staff. There is no book.meztezz.com/yourrestaurant URL today.
No deposit / prepayment field on reservations.
No “source” field to track phone vs. walk-in vs. online bookings.
Captain App can’t create or edit reservations. Seat and no-show only.
No one-click “print QR sticker per table” workflow.
Reservation reports don’t roll up to revenue.

If any of these are deal-breakers for your operation, write in — we prioritise feature work based on what real restaurants ask for, and a clear “we need X because Y” message goes a long way.

A Few Habits That Save You Later

Lock the structural permissions to managers. table:manage, table:merge, table:split and table:transfer are power actions. A cashier doesn’t need them. Give floor captains table:update_status so they can run the room, but keep the rest with managers and owners.
Pre-pin reservation tables when you can. A reservation without a table assigned is fine, but pre-pinning shows the yellow pill on the grid and lets your hosts seat without thinking. Re-pin if you need to reshuffle on the day.
Tune the slot math to your kitchen, not the industry average. 90+15 minutes is a sensible default for a sit-down restaurant. A fast-turn café might run 60+10; a fine-dining tasting menu might run 150+20. Set it once, watch your no-show and overlap numbers for a month, adjust.
Use the audit log when something looks off. If a bill total changed unexpectedly, ask “was a split or merge involved?”. The log will tell you who, when, and what.
Match your section names to how staff actually talk. If your team says “send the order to the rooftop”, call the section Rooftop, not Section-3.

Stuck? We’re Here to Help

If any of this didn’t behave the way the guide describes — a permission missing, a reservation status that won’t advance, a merge that’s getting refused without an obvious reason — drop us a line at bazimat@gmail.com or contact us. Tell us which section of this guide you’re on and what you’re seeing; we’ll usually have you sorted in a single back-and-forth.

Your floor is the part of the restaurant your guests actually live in. Spending an hour getting the table grid, sections and reservation rules right is one of the highest-leverage things you’ll do this week. 🎉