Cover management and pacing
A booking grid built on measured turn-time by table, party size and day part, with pacing rules that control how tightly a service is booked and how much capacity is held back for walk-ins.
Hospitality
Reservation platform development
OpenTable, ResDiary and SevenRooms all do a competent job of taking a booking for a single site. What they do less well, or not at all, is give a multi-site group a consistent policy for deposits and no-shows across every location, a waitlist that spans sites in the same area, and turn-time logic tuned to how that specific group actually runs a service — a fine-dining format seating for a two-hour experience behaves nothing like a high-volume casual format turning tables three or four times a shift.
We build reservation and cover management platforms, either as a layer that extends an existing OpenTable, ResDiary or SevenRooms setup or as a full replacement where a group's format needs pacing and turn-time logic the off-the-shelf tool cannot express, with deposit and no-show charging, waitlist handling and walk-in seating built around the shape of the specific business rather than a generic booking form.
The workflow this replaces
What a Friday night service looks like without this
Before cover optimisation and a shared waitlist exist, a busy multi-site group typically runs Friday and Saturday night service like this.
Step 01
Bookings are accepted evenly across the evening regardless of table mix
The reservation platform books tables against a simple time-slot grid rather than against actual table turn-time by party size, so a run of 8pm bookings for tables of two can leave larger tables under-booked and smaller tables double-booked against a turn-time that was never modelled accurately.
Step 02
A deposit is taken manually over the phone for large parties
For parties above a certain size, a manager takes card details over the phone and processes a deposit outside the booking system entirely, which means the deposit, the booking, and the eventual no-show or attendance are three separate facts that have to be reconciled by hand if a dispute arises.
Step 03
A no-show is noted, but the charge is rarely enforced
Policy on the website says a no-show forfeits the deposit, but enforcing it requires someone to manually process the charge against card details taken over the phone, which is awkward enough that it often does not happen, undermining the credibility of the policy for repeat offenders.
Step 04
The waitlist is a paper pad at the host stand
Walk-ins are logged by hand, quoted a rough wait time based on the host's judgement, and if the site is full, staff have no reliable way of checking whether the sister site two streets away has space, even when they know it from memory on a quiet night.
Step 05
Turn-time is estimated, not measured
Nobody has an accurate figure for how long a table of four actually occupies a table on a Friday night, so the booking grid is built on a rounded assumption — typically ninety minutes or two hours regardless of what actually happens — which either leaves tables empty when turn-time is faster than assumed, or creates a queue of frustrated guests when it is slower.
Step 06
A manager manually overrides the system to seat a walk-in during a full service
When a table becomes free and a walk-in is waiting, a manager makes the seating call from the floor rather than from any system, which works on the night but leaves no record that would let head office understand how often walk-in demand exceeded what the booking system had planned for.
A reservation platform built around turn-time and pacing does not remove the manager's judgement about who to seat next. It gives that manager, and the group's operations team afterwards, an accurate picture of what actually happened during service, and it enforces the deposit and no-show policy that already exists but currently depends on someone remembering to act on it.
What we build
Modules in a typical reservation platform build
Deposit and no-show charging
Card capture or tokenisation at booking through a PCI-compliant payment gateway, policy terms shown and accepted at the point of booking, and automated charging for no-shows and late cancellations outside the policy window.
Shared waitlist across sites
A live waitlist visible to host staff at every site in a group, with the option to offer a guest a table at a nearby location when the site they approached is full.
Walk-in handling and floor management
A host-stand view that shows current table status, pacing headroom, and the live waitlist together, so a host can seat a walk-in against real availability rather than guesswork.
Turn-time measurement
Seating and clearing timestamps captured per table, combined with EPOS course-timing data where available, to build a reliable turn-time figure by table, party size and service, refreshed continuously rather than set once and left.
Group and site-level reporting
Covers per shift, average turn-time, no-show and cancellation rates, and deposit revenue, reported per site and rolled up across the group for operations and finance teams.
Integrations
Named systems and interfaces
Reservation platforms
OpenTableResDiarySevenRooms
EPOS
LightspeedToastSquareZonalTevalis
Payments
PCI-compliant payment gatewaystokenised card storage
Communication
SMS gatewaysemail confirmation services
Where a group is committed to OpenTable, ResDiary or SevenRooms for the booking form itself, we integrate with its API for booking data and build cover optimisation, deposit handling and waitlist logic as a layer above it. Where the group's format needs pacing logic those platforms cannot express, we build the booking engine directly.
Data and compliance
Requirements written into the build
- PCI DSS scope
- Card capture for deposits runs through a PCI-compliant payment gateway; the reservation platform itself stores tokenised references, not raw card data, keeping the platform outside the highest tiers of PCI DSS scope.
- Deposit policy versioning
- Every booking is linked to the specific version of the deposit and no-show policy shown to the guest at the time, so a later dispute can be resolved against what was actually agreed.
- Turn-time data
- Seating and clearing timestamps by table, party size and day part, retained long enough to build seasonal pacing models rather than a single static assumption.
- Licensing hours
- Booking grids respect each site's specific licensed hours and last-orders times, which can differ across a group even under the same brand.
- Waitlist consent
- Guest contact details captured for waitlist SMS or call-back notification are held only as long as needed for that visit, with consent captured for any subsequent marketing use.
Architecture note
How the system is put together
The booking engine is built as a service independent of any single reservation platform's API, so pacing and turn-time logic runs against internal data even where OpenTable, ResDiary or SevenRooms remains the guest-facing booking form. This avoids being constrained by whatever pacing features a third-party platform happens to expose.
Payment and card data flow through a dedicated PCI-compliant gateway integration, with tokenised references, not card numbers, stored in the reservation platform's own database, which keeps the bulk of the system outside the highest tiers of PCI DSS scope.
Turn-time and pacing models are calculated per site rather than applied as a single group-wide figure, because a group's sites frequently differ in format, table mix and typical party size even under one brand, and a shared model would misprice pacing for at least some of them.
The waitlist and cross-site offer logic runs as a real-time layer connected to every site's live table status, built so a new site can be added to a shared waitlist group without a schema change, just a configuration entry linking it to its neighbours.
Timeline
Build phases in weeks
Discovery
Weeks 1-3
Mapping of current booking, deposit and waitlist processes across sites, turn-time data availability assessment, and a phased build plan.
Booking engine and cover management
Weeks 4-9
Core booking grid, pacing rules and integration with the existing reservation platform or replacement booking form.
Deposit and no-show charging
Weeks 10-13
Payment gateway integration, policy versioning, and automated charge triggering for no-shows and late cancellations.
Waitlist and walk-in tooling
Weeks 14-16
Shared waitlist across sites, host-stand floor view, and walk-in seating workflow.
Turn-time measurement and pacing tuning
Weeks 17-19
Timestamp capture, EPOS course-timing integration where available, and initial pacing model calibration per site.
Rollout and stabilisation
Weeks 20-22
Site-by-site rollout, host staff training, and a defined period of pacing model refinement based on live service data.
Indicative cost
Budget bands, not quotes
- Discovery and scoping
- £12,000 to £25,000, credited against the build.
- Cover management layer on an existing reservation platform
- £250,000 to £340,000.
- Full booking engine replacement with pacing and turn-time logic
- £340,000 to £480,000.
- Waitlist and walk-in module added to either build
- £40,000 to £80,000.
- Managed run
- Monthly retainer against an agreed service level, priced after go-live scope is confirmed.
Bands assume a UK group of four to fifteen sites with an existing reservation platform in place. A group needing pacing tuned per format across a wider range of site types sits at the upper end.
Where this sits
Related pages
Questions
Frequently asked
Do you replace OpenTable, ResDiary or SevenRooms, or build alongside them?
Most engagements build alongside the existing platform, adding cover optimisation, group-wide waitlist visibility and deposit handling that the standalone reservation tool does not do well across multiple sites. Some groups outgrow their reservation platform entirely — usually when they need pacing rules or turn-time logic specific to their format — and choose a full replacement instead, which we also build.
How does automated no-show charging actually work?
A card is captured or tokenised at the point of booking through a PCI-compliant payment gateway, held rather than charged, and a no-show or a late cancellation outside the stated policy window triggers the charge automatically against pre-agreed terms shown to the guest at booking. The charge, the policy version in force at the time, and the booking record are all linked, so a dispute can be resolved from the system rather than from someone's memory of a phone call.
Can the platform manage a shared waitlist across several sites in the same area?
Yes, where a group operates multiple sites close enough together that a guest turned away from one is a plausible booking for another. The waitlist can offer a guest a table at a nearby site as an alternative, with staff at both locations seeing the same live queue, which is not something a single-site reservation tool is built to do.
How do you calculate table turn-time, and what do you do with it?
Turn-time is measured from the point a table is seated to the point it is cleared and available again, drawn from EPOS course-timing data where available and from host-stand seating and clearing actions where it is not. Once measured reliably by table, by day part and by party size, it feeds pacing rules that control how tightly the system books tables in a given service, which is the main lever for increasing covers without adding tables.
What happens to a walk-in when the system shows the restaurant fully booked?
Pacing rules protect a margin of tables for walk-ins during services where they are commercially significant, rather than allowing online booking to fill every table. Host staff can also override pacing manually for a walk-in they can seat immediately, with the system tracking that override so management can see how often the buffer is used and adjust it by day part.
Does the reservation system integrate with our EPOS?
Where useful, yes — seating a table in the reservation system can open the corresponding cover on the EPOS, and course timing from the EPOS feeds back into turn-time calculation. This is typically built as part of a combined reservation platform and EPOS integration engagement rather than the reservation platform alone.
Tell us what your systems are doing wrong.
Send the problem, not a brief. We will tell you whether it is a project we should be involved in.
Talk to us