Industries
A multi-site restaurant, bar or pub group runs on a stack of systems that were never designed to talk to each other: an EPOS platform per estate — often Lightspeed, Toast, Square, Zonal or Tevalis, sometimes a mix of two after an acquisition — a reservations system such as OpenTable, ResDiary or SevenRooms, order feeds from Deliveroo, Uber Eats and Just Eat arriving as separate tablets bolted to the pass, and stock and labour management in Fourth or Nory that rarely reconciles cleanly against what the till actually rang through. Each system is competent at its own job. None of them was built to give a general manager or an operations director a single, trustworthy view across a group of sites.
We build the software that sits across that stack: reservation and cover management platforms that handle table turn-time, deposits and waitlists properly; EPOS and aggregator integration layers that inject Deliveroo, Uber Eats and Just Eat orders into a single kitchen queue and keep menus and pricing in sync across sites; and multi-site operations dashboards that turn labour percentage, wastage, stock variance and daily sales into a flash report a regional manager can act on before lunch service the next day, not a fortnight later when the numbers are cold.
None of this replaces the EPOS or the reservation platform a site already runs. It connects them, normalises what comes out of them, and adds the layer of cover optimisation, order routing and group reporting that a single-site tool was never asked to provide. The regulatory context — PCI DSS scope on card data, Natasha's Law allergen labelling, licensing hours, and the Employment (Allocation of Tips) Act on tronc — is built into the data model rather than bolted on as an afterthought once an auditor asks a question nobody can answer quickly.
Where it breaks
A reservation comes in through OpenTable or ResDiary, a walk-in is logged on a paper waitlist at the host stand, and a deposit taken for a large party sits in a separate payment record that nobody reconciles against the no-show it was meant to protect against. Table turn-time — the single biggest lever on covers per shift — is never measured because the data needed to measure it lives in three places at once.
Deliveroo, Uber Eats and Just Eat each supply their own tablet at the pass, each with its own accept-and-print workflow, and kitchen staff during a busy Friday service are physically running between three screens rather than working from a single order queue. A site going offline on one aggregator because a tablet lost signal is common, and nobody notices until a customer complains that their order was never accepted.
A price change, a new allergen note, or a seasonal dish coming off the menu has to be updated in the EPOS, the online ordering site, and separately in the Deliveroo, Uber Eats and Just Eat merchant portals, each with its own item structure and its own delay before the change goes live. It is common for an item marked as sold out on the EPOS to still be orderable on an aggregator an hour later.
Rotas are built in Fourth or Nory against a sales forecast, but the actual labour percentage — wage cost as a proportion of net sales, the single figure that most directly drives site profitability — is only known once payroll closes the week, by which point an overstaffed Tuesday cannot be corrected, only noted for next time.
Some sites run a disciplined daily stock take against theoretical usage calculated from EPOS sales; others check stock weekly or not at all until a variance becomes large enough to notice. Without a consistent group-wide method, a head office finance team cannot compare site performance or spot a site with a systemic wastage or, less comfortably, a stock control problem.
Closing a site's till, matching card processor settlement against EPOS Z-reads, and accounting for aggregator commission deductions is done manually, per site, often by a duty manager staying late, and errors surface only when a bank reconciliation fails weeks later rather than the same night.
Regulatory context
Integration surface
EPOS
Reservations
Delivery aggregators
Stock and labour
Payments
Reporting and communication
Solutions
Cover management, table turn-time optimisation, deposit and no-show charging, waitlist handling and walk-in seating built around how a busy service actually runs.
Explore reservation platform developmentAggregator order injection from Deliveroo, Uber Eats and Just Eat, menu sync across sites, price banding by location and end-of-day reconciliation against card settlement.
Explore epos integrationLabour percentage against sales, wastage and stock variance, site league tables and a daily flash report a regional manager can act on the next morning.
Explore multi-site operations dashboardEngagement shapes
Questions
Most of our hospitality work is for operators running somewhere between four and forty sites — large enough that spreadsheets and a single EPOS dashboard no longer give management a reliable group-level view, but not so large that they run their own in-house engineering function. A single-site restaurant rarely needs bespoke software; a forty-plus site chain usually already has one. The gap in between is where we work.
In almost every engagement we integrate with the EPOS already in place — Lightspeed, Toast, Square, Zonal or Tevalis — rather than replacing it. Replacing an EPOS estate mid-service is disruptive and rarely justified when the actual gap is reporting, reservation handling or aggregator order routing sitting on top of the till, not the till itself.
Each aggregator exposes its own order webhook or polling API, its own menu format, and its own rules for rejecting an order when a site goes offline. We build an injection layer that normalises orders from all three into a single format before they reach the EPOS or kitchen display, so kitchen staff see one consistent order queue regardless of which platform it came from, and menu availability toggles push back out to all three consistently.
Natasha's Law (technically the Food Information (Amendment) (England) Regulations 2019, with equivalents across the UK) requires full ingredient labelling on food prepacked for direct sale. We build allergen and ingredient data as a structured, versioned part of the menu — held once and reused across EPOS, online ordering, aggregator menus and printed labels — so a recipe change to an allergen-bearing ingredient updates every surface it appears on rather than requiring someone to update four systems by hand.
We integrate with existing tronc administration and payroll processes rather than replacing statutory tronc schemes, but we do build the data feed a tronc system needs — service charge and tip totals by site, by shift and by staff member, reconciled from EPOS and card processor data — so the fair and transparent allocation required under the Employment (Allocation of Tips) Act 2023 is based on accurate underlying figures rather than an end-of-week manual count.
A single-module build such as a reservation platform or an EPOS integration layer for a group with four to ten sites typically starts at £250,000. A combined reservation, EPOS integration and multi-site operations dashboard programme for a larger group runs higher, delivered in phases so each module is live and earning its keep before the next is built.
Send the problem, not a brief. We will tell you whether it is a project we should be involved in.
Talk to us