Features

Everything between “Can I book a table?” and the end of service.

Five chapters, in the order a restaurant actually works them: get booked, plan the service, run the floor, protect revenue, and keep the guest relationship afterwards.

01

Get booked

A booking page guests can finish in under a minute

Your own public booking page shows live availability from your real tables and services — not a static timetable.

  • Date, party size and time selection with availability decided at the moment the guest looks.
  • The chosen time is held while the guest completes their details, so two guests cannot take the same table.
  • Occasion, dietary requirements and access needs captured with the booking.
  • Your booking policy is shown and acknowledged before confirmation.
  • Immediate confirmation, or a request for approval where you prefer to review first.
Your own booking page shows live availability from your real tables, and holds the chosen time while the guest finishes.
02

Plan the service

You decide what is sellable, table by table

Availability is calculated from your configuration every time, so what a guest sees is what the floor can actually take.

  • Services and opening hours per day, with closures and one-off date overrides.
  • Booking durations and turnaround time by party size and service.
  • Table capacities and the specific table combinations you allow for larger parties.
  • Cover pacing so a service fills at a rate the kitchen can deliver.
  • Requested times are held as real inventory, not a provisional note.
Pacing closes 20:00 once the kitchen’s cover limit for that slot is reached, and the booking page simply stops offering it — no manual blocking mid-service.
03

Run the floor

One book for the whole shift

The day book and the live floor are the same reservations seen two ways, so nothing is reconciled by hand.

  • Day book by service with covers, requests and status at a glance.
  • Live floor with table state, drag-and-drop assignment, moving and seating.
  • Reservation detail in a side panel that keeps your place in the service.
  • Walk-ins added straight onto the floor with the same availability rules.
  • Lifecycle actions: arrive, seat, complete, cancel, no-show.
Booked to Seated is one action on the floor. The table state, the turn timer and what the booking page can sell all move together.
Widget bookings, phone bookings, walk-ins and waitlist seatings land in the same book, in the same order of service.
04

Protect revenue

Deposits, waitlist and policies, handled properly

Protect the bookings worth protecting, and turn a cancellation back into a seated table.

  • Deposits and prepayments taken through your own Stripe account — ResRes takes no cut of guest payments.
  • Waitlist with a seating claim, so two staff cannot offer the same table.
  • Payment state kept separate from booking state, so a table is never quietly treated as paid.
A 20:00 cancellation does not become an empty table: the waitlist party is claimed by one member of staff and seated against the same availability rules.
A deposit is attached to the booking and charged on your own Stripe account. Payment state is tracked separately from booking state, so nothing is quietly treated as paid.
05

Know your guests

Context before the guest reaches the pass

Every booking builds a durable guest record that stays with the restaurant.

  • Reservation history and visit count on the guest record.
  • Dietary requirements, access needs and occasions carried with the booking.
  • Staff notes and preferences kept with the guest, not in someone’s head.
Allergies, access needs and the occasion travel with the booking, so the section knows who is walking in before they arrive.

Around the service

Confirmations and reminders

Transactional email is part of the reservation flow: a confirmation when a booking is made or approved, and pre-arrival reminders on plans that include them. No marketing blasts, and no guest list sold on.

One dining room to a small group

Essential runs one active location with the full core product. Professional adds multiple locations, deeper floor operations and team roles. Premium adds group organisation, consolidated reporting and location comparison.

Reporting you can act on

Covers, bookings, cancellations and no-shows by service and by location, exportable, based on the same records the floor works from.

Team access, scoped

Staff access is scoped per location, so a team member only sees what they should, and invitations are issued rather than passwords shared.

Reliability and security

Built to be correct under pressure

Separated by restaurant

Each restaurant’s data is isolated, and access is enforced on the server for every request — not hidden in the interface.

Changes are all-or-nothing

Moving, amending or seating a booking either completes fully or does not happen. Two staff acting at once cannot double-book a table.

Payments handled by Stripe

Card details never touch ResRes. Deposits are charged on your own connected Stripe account and reconciled from verified Stripe events.

Notifications that do not get lost

Guest email is queued durably and retried, so a confirmation is not dropped because one send failed.

Direction, not shipped: external booking platforms, assistant-driven booking, a public API and SMS or WhatsApp messaging are design direction for the same core engine. They are not available today, and nothing on this page should be read as an announcement that they are.

See the whole workflow on your own restaurant.

Set up your restaurant, configure your tables and services, and publish your booking page.

No card required · Professional plan for 30 days