Core Features

Table Booking

Reservations taken in chat, sized to the right table, paced so the kitchen can cope — and a floor plan your staff run the shift from.

Overview

A guest says “table for four, Friday at 8” and it is booked — on a table that actually seats four, for as long as four people really take, and only if the kitchen has room at 8 o’clock. If the floor is full they join the waiting list and are offered the first table that frees up.

Table booking is built on top of Appointments. A reservation is an appointment, so everything you already know works the same way: reminders, approval, cancellations, the Live Chat panel, the phone app, webhooks and the export. What this page adds is the part that is specific to a restaurant.

Note

You need Appointments switched on. Open Customers → Appointments → Settings, set your opening hours, then turn on Table booking. Your hours are the hours the floor takes bookings.

Setting up the floor

Add your areas

Indoor, terrace, rooftop, private room, bar counter. An area is what a guest chooses from, and what you can close on its own — the terrace in the monsoon, say.

Add your tables

Each table has a name (“T4”, “Window 2”), how many it seats, and the area it stands in. You can also give it a smallest party, so a table for six is not spent on a couple.

Set your turn times

How long a party really keeps a table, by size: a couple for 60 minutes, a four for 90, a party of eight for two hours. This is the single most important setting — get it wrong and you either double-book or leave tables empty.

Pace the kitchen

Covers per 15 minutes caps how many guests may be seated in any quarter hour. A kitchen that can plate twenty covers at once should say 20, or every table at 8:00 sharp arrives at once. Leave it at 0 for no cap.

Add a Book a Table step to a chatbot

Start from the Restaurant — Table Booking template in the chatbot builder. It already asks party size, area, day, time and occasion, shows the menu, and offers the waiting list when the floor is full. Nothing in it needs a key or a URL configured.

How a table is chosen

When a guest picks a time, the tightest table that fits is taken — a party of two gets the two-seater, not the six. That is what keeps your big tables free for the bookings that need them.

Real time, not slots. A 90-minute booking at 7:30 blocks 7:30 to 9:00 on that table, so a 8:00 enquiry is correctly refused even though 8:00 is a “free” slot time.
Party size vs. seats. A party of four takes one table, not four. Your table capacity is checked against the party; your covers cap is checked against the guests.
Grace period. How long a table is held for a party that has not turned up before it can be released and the booking marked a no-show.
Large parties. Set a size above which a booking always waits for your approval — a party of twelve is a conversation, not a click.

The waiting list

When a date is full, a guest can join the queue instead of being turned away. They are told roughly how long the wait is, and when a table frees up the party at the front is offered it.

The offer holds the table. An offered table is held for a set number of minutes, so two guests are never sent to the same one. If the offer is not accepted in time the hold is released automatically and the next party is offered it.
Accepting is one reply. The held booking becomes a real reservation with its own reference — no re-asking for the date, the size or the name.
A cap per date. So the queue stays a queue and not a false promise.

Deposits and pre-orders

Deposit. Charged per guest for parties at or above a size you choose. With hold until paid on, the booking sits as awaiting approval until the money is in, so an unpaid large party never quietly occupies your best table on a Saturday.
Pre-order. Ask parties from a certain size up to choose their food in advance, up to a cut-off before they arrive. The kitchen gets a prep list instead of eight decisions at once.
What the guest carries. Occasion, seating preference, dietary needs, allergy note and high chairs all travel with the booking and show up wherever your staff read it.

Your menu is your products

The menu in chat is your product catalogue — there is no second list to keep up to date. Turn table booking on and each product gains a dining panel:

Field	What it does
Course	Starter, main, dessert, drink — groups the dish in the menu the guest sees.
Diet	Pure veg, Jain, vegan, no onion / no garlic, halal. A guest who says “pure veg” only sees food they can eat.
Spice level	Shown beside the dish, so nobody is surprised.
Allergens	Listed with the dish, and matched against the allergy note on a booking.
Signature dish	Lifted to the top of the menu — the things you want ordered.
Serves	How many people a dish feeds, for sharing plates and thalis.
Serving window	Days and times a dish is available, so a breakfast item is not offered at dinner.
In stock	Turn it off and the dish is 86'd for today — it disappears from chat immediately.

Tip

Photographs only as JPG or PNG. WhatsApp drops a WebP product image without saying so. Save dish photos as JPG or PNG.

What guests can do in chat

Book a table. Party size, area, day and time, all read live from your real floor — a guest can only pick something that is genuinely available.
See the menu. Browse by course, filtered to what they can eat and what is being served at that hour.
Check, move or cancel. The same reference and the same rules as any other booking, including your cancellation cut-off.
Join the waiting list. Offered automatically when the time they asked for is full, rather than a dead end.

For your team

Floor plan. Tonight’s service by area and table: who is booked, who has arrived, what is free and for how long. Seat a party in one tap, or move them to another table.
Walk-ins. Booked and seated in the same action, so the floor plan stays true to the room.
In Live Chat. A guest’s bookings sit beside the conversation, with their occasion, dietary needs and pre-order in plain sight — so “happy anniversary, and the Jain thali is noted” needs no other screen.
Waiting list. See the queue, offer the next party a table, and watch offers expire on their own.
On the phone. A Floor screen in the app: tonight’s tables by area, who has arrived, and the waiting list — built for the two things you do standing up, which are seating the party in front of you and calling the next one off the queue. It refreshes itself, because the floor changes while you are walking across it. The row only appears for a business that takes table bookings.
Permissions. The same View Appointments and Manage Appointments as the rest of the diary, granted in Team.

In workflows

A Book a Tablestep books, waitlists or reads the menu from any workflow — so a review request can go out two hours after a party is seated, or a regular can be offered their usual table on their birthday. Table bookings raise the appointment webhooks, plus table.waitlisted, table.offered and table.seated. Every one of those is also available as a workflow trigger.

For your developers

Session and mobile apps read and write the floor through /api/restaurant/*: availability, bookings, move, seat, floor plan, tables, waiting list, menu and settings.

Note

Not yet on the public REST API. The versioned /api/v1 surface covers appointments but not the restaurant-specific endpoints. To book a table from your own software today, use the appointment endpoints in the API Reference— a table booking is an appointment — or drive it from a workflow.

Appointments

Analytics & Reports