A restaurant replaced its static booking grid with a live table occupancy system driven by camera feeds and predictive ML.
Duration
14 weeks
Year
2025
Services
Tables monitored
68 covers
Cameras deployed
4
Menu update latency
< 5 seconds
Build duration
14 weeks
The challenge
The client ran a high-volume London restaurant with 68 covers. Their existing booking system operated on fixed time slots that bore no relationship to how the restaurant actually moved on any given night. Early tables sometimes turned in 45 minutes; later tables could run past midnight. The fixed-slot model meant they were refusing walk-ins while tables sat empty and double-booking slots where the previous sitting had overrun. They estimated they were losing 15–20% of potential covers per week to this structural inefficiency alone.
The secondary problem was the menu. They ran a seasonal menu that changed frequently, plus specials that changed daily. The printed menu and the PDF on their website were routinely out of date, leading to tableside disappointment when dishes shown online were unavailable. They wanted a digital menu system that reflected the actual menu at any given moment — including real-time 86ing of dishes that sold out during service.
The solution
We installed four overhead cameras positioned to cover the full restaurant floor with overlapping fields of view and no blind spots. Each camera fed into a lightweight occupancy detection model running on an on-premises edge device — a small server unit in the restaurant's back office that processed the video streams locally without sending footage to external servers. The model was trained to identify occupied versus empty table states based on visual cues: presence of diners, food and drinks on table, glasses and crockery layout. It was not trained to identify individuals and processed only occupancy state, not imagery.
The occupancy data fed in real time to a booking engine we built that managed reservations as dynamic time windows rather than fixed slots. When a table became available, the system immediately opened that slot to new bookings. Walk-in waitlists were managed by the same engine: walk-in guests were given a real-time estimated wait based on current occupancy, average cover duration for that table size, and remaining bookings in the queue. The front-of-house team operated a dashboard showing every table's state, incoming reservations and the walk-in queue simultaneously.
The menu system ran separately but integrated with the same dashboard. Managers could update the menu in real time through a simple interface, including setting any dish to 86 (sold out) with a single toggle. The digital menu displayed to diners on a QR-code-linked web page reflected the current active menu at that moment, with sold-out items greyed out rather than removed — preventing the UX problem of dishes disappearing from view mid-service and confusing guests who had already scanned and decided.
Key features
Four cameras processed locally on an on-premises edge device. No video data leaves the restaurant. The model identifies table occupancy state — empty, occupied, in service, clearing — updated every 30 seconds.
Reservations are managed as time windows with probabilistic duration rather than fixed slots. The system adjusts available booking times in real time as tables turn faster or slower than the predicted average.
Walk-in guests enter a live queue with a dynamic estimated wait time. When a table becomes available, the next queue guest receives an SMS notification. No pager devices, no verbal queue management required from front-of-house staff.
A manager-facing dashboard allows the kitchen or floor manager to update the menu live — adding specials, removing dishes, adjusting prices — with changes reflected on the guest-facing QR menu within seconds.
The system builds a historical model of average cover durations by party size, day of week and time of booking. This feeds back into wait time predictions, improving accuracy over time as the model learns each restaurant's actual patterns.
Outcome
In the first four weeks after launch, the client reported a measurable increase in covers served per service versus the same period the previous year. The walk-in queue system converted a meaningful proportion of walk-in visitors who would previously have been told there was no availability and left. The menu system eliminated menu-related tableside complaints in the first week of operation. The kitchen team adopted real-time 86ing immediately, which they described as removing a significant source of tableside friction that had previously required runners between kitchen and floor.
More case studies
How we turned 2,400 unique physical products into a production-ready online store in eight weeks.
A platform that lets anyone create original music, own it outright, and distribute it to streaming services — without giving away rights.
A private members club replaced a PDF waiting list and email newsletter with a full membership platform — events, access tiers, and community in one place.
We build custom when off-the-shelf doesn't fit. Tell us what you need.