Restaurant reservation systems

A table reservation system built around your floor plan.

Guests reserve direct while you control covers, turn times, joined tables and the capacity held for walk-ins. A focused restaurant reservation system is usually £600 - £1,200 and works with an existing or new website.

Run a busy Friday demo See the rules that matter

No per-cover fee from Ernest. Payment, messaging and third-party providers may charge their own fees.

Friday dinnerone live floor plan

T12T22T34T44T52T64

New direct reservation4 guests at 19:30T6 held

28 of 40 covers reserved

The guest promise and the host floor plan agree.

24/7direct reservations

0%per-cover fee from Ernest

Oneagreed floor plan

Yoursguest and reservation records

Try it without signing up

A guest sees a time. The host sees the consequence.

Change the party size and time, then confirm the pretend reservation. Nothing is sent or stored. The floor plan shows why a real reservation system needs capacity rules behind the form.

Interactive example

Guest viewThe Green Room

Friday dinner

Table for 2

1 hour 30 minutes·No deposit

Main dining room

Choose a time

NameAlex MorganRequestBirthday meal

No depositReady to reserve

Host viewFloor plan at 19:30

planning

WindowT12T22T34T44T52T64T73T83Private roomapproval

availablebookedsuggested

Suggested allocationT2, window table

Fits one two-seat table without changing the held walk-in capacity.

What gets lost without one route

The empty table is visible. The broken process is not.

Calls during service, messages across several channels, table combinations and held walk-in capacity make reservations more than a contact form. One dependable route prevents a guest promise from disagreeing with the floor plan.

During service

Calls interrupt the room

Guests can reserve or send the right enquiry without waiting for someone to answer.

Across channels

Messages go missing

Website, phone and walk-in records meet in one agreed working view.

At the same time

Capacity gets promised twice

The confirmation checks current inventory, table combinations and held capacity.

Before arrival

No-shows stay unmanaged

Clear policies, reminders and proportionate deposits can protect the difficult bookings.

Rules before features

A form takes details. A system protects the shift.

The useful work is deciding what the website may promise at each service, not adding another calendar to the site.

One availability decisionfloor plan + service rules + current reservations

Turn times and pacing

Set realistic duration by party size and spread arrivals so one time does not overwhelm the kitchen.

Tables and combinations

Know which tables can join, which must stay separate and what is genuinely suitable for a party.

Walk-ins and large parties

Hold capacity back, pause online availability and route exceptional groups to staff approval.

Commitment rules

Apply reminders, deposits, card holds or cancellation terms only where they are useful and supported.

One reservation, start to finish

Direct for the guest. Useful for the team.

The guest selects a valid party size and service time. The system checks the agreed floor plan and capacity rules, collects only the useful details and optional payment, stores the reservation, then confirms it and runs the reminder or change route.

The system never invents a table. It confirms from the agreed source or clearly asks staff to review the request.

01
Check
Party, service and capacity
Only valid times appear after the party and floor rules are applied.
02
Collect
Useful guest details
Name, contact route, access or dietary note and the agreed payment step.
03
Commit
Allocate and confirm safely
The authoritative record updates before the guest receives confirmation.
04
Run service
Remind, move, seat or waitlist
Routine changes stay attached to the same reservation instead of becoming another message.

Choose the right ownership level

Keep, connect or build.

Best for restaurants, cafes, pubs and other businesses reserving finite spaces. Keep a trusted platform when it already runs service well, own a focused route on the website when the rules are contained, or build a fuller app when staff need live floor status and permissions.

01Your current platform runs service well

Connect it cleanly

Keep its floor plan and staff workflow. Improve the direct website route through a supported link, widget or API.

Best when the operating tool already earns its place.

02You need one focused direct route

Own it on the website

Use your own rules and records without paying Ernest per cover or renting features the venue does not need.

Best for a clear floor plan and contained workflow.

03Reservations affect the whole operation

Build a front-of-house app

Add staff access, live table status, waitlist, multiple areas, guest notes, reporting and custom permissions.

Best when the table diary is only one part of service.

One inventory principle, different spaces

Reserve what is finite. Keep the rules specific.

Restaurant table booking system

Covers, turns, joined tables, walk-in holds, large parties and a host view built around the real room.

See restaurant website work

Private dining and function rooms

Capacity, layouts, enquiry approval, menus, deposits and an agreed handover to the events team.

See event website work

Pitches and limited spaces

Dates, capacity, unit rules and closures can follow the same inventory principle when the business needs a focused route.

Find the closest industry

Need appointments instead?

A salon chair, clinic practitioner or service visit is a time-slot problem, with different availability and staff rules.

See the online booking system

Connections checked before the quote

One floor plan. No pretend sync.

A link, widget, export or API can all be valid. Ernest checks what the selected provider actually exposes, which direction records move and what staff do if that connection fails.

Website and Google reservation routePOS or front-of-house systemReservation recordDeposit or card providerEmail and optional SMS

Simultaneous requests and stale availability tested

Payment success, failure and refund route agreed

Manual fallback written for service staff

Proof is a working shift

Test the awkward cases. Then hand it over.

The interactive floor plan above is an illustration, not a claim about your capacity. Your build uses the real room, service periods and staff decisions. Acceptance testing follows the situations that usually break a generic form.

See restaurant website experience

01Two guests confirm togetherOnly one receives the final table.

02A large table changes sizeCapacity and deposit rules recalculate.

03Payment or message failsThe reservation is not silently lost.

04Staff pause online coversThe public availability follows safely.

05A guest moves or cancelsThe same record and capacity update.

06A provider is unavailableThe team has a clear manual route.

Restaurant reservation system price

A focused build with visible boundaries.

The range covers one contained reservation route. The proposal names the floor plan, service rules, messages, payment behaviour and connections before the build begins.

See all website and system prices

Typical one-off build£600 - £1,200usually 1 to 3 weeks

Party, service, turn and table rules
Guest reservation and confirmation route
Host record and tested capacity behaviour
Launch, training and practical fallback

Price rises with multiple rooms or venues, live floor status, waitlists, staff permissions, migration, POS integration, complex payments or closed third-party systems.

Standalone support£25 - £45/moorRun Growthincluded in £199/mo

Support is optional. Payment, SMS, email, POS or reservation platforms may charge their own fees directly.

Before the reservation build

Table reservation questions.

Can I keep the reservation platform my team already uses?

Yes, if it works and provides a dependable direct route. I check whether the website should use a link, widget or documented API, which system owns availability and what happens when the connection is unavailable before proposing replacement.

How does the system prevent overbooking?

A confirmed reservation must check one authoritative inventory at the final step, not rely on an old screen. I test simultaneous requests, table combinations, service limits and stale sessions. Exceptional parties can become staff-reviewed enquiries instead of automatic promises.

Can I keep tables available for walk-ins?

Yes. Online capacity can be lower than the physical room and can vary by service or time. Staff can also pause availability or hold particular tables when the agreed workflow supports it.

Can it take deposits or card details for large parties?

Yes, through a suitable payment provider and an agreed policy. Deposits, full prepayment or card holds are separate behaviours, so the proposal states which one applies, how cancellation works and which provider fees remain payable.

What happens with private rooms or very large parties?

They can follow a separate enquiry and approval route rather than appearing as ordinary instant availability. The system can collect the event details, hold a provisional option, request a deposit after approval and keep the handover visible to staff.

Can future reservations be moved from my current system?

Sometimes. It depends on the available export or API, the quality of table and guest fields and the permission to use those records. I map and test a small import before migration is included in the build.

Bring the floor plan and one busy service

Show Ernest how a table is promised today.

The first conversation maps covers, turns, exceptions and the system staff already use. You will know whether to keep, connect or replace it before a build is proposed.

Discuss your reservation route Explore every system and add-on Email or telephone only. No obligation and no platform sales pitch.