Labour percentage against sales
Daily labour cost calculated from actual clock-in and clock-out data against net sales for the same period, reported per site and per day part, refreshed the morning after trading closes.
Hospitality
Multi-site operations dashboard
A restaurant group running EPOS sales through Lightspeed, Toast, Square, Zonal or Tevalis, and rotas and stock through Fourth or Nory, already generates most of the data an operations director needs to run the estate well. The problem is rarely a lack of data; it is that labour percentage, wastage and stock variance sit in three or four systems that do not talk to each other, and by the time anyone assembles a group-wide view by hand, the week it describes is already over.
We build a reporting layer that pulls sales, labour and stock data out of the EPOS and workforce systems already in use and turns it into a daily flash report and a site-by-site league table, so a regional manager knows which sites need attention before lunch service the next day, not at the end of a month when the pattern has already cost the business money.
The workflow this replaces
How a group finds out it overspent on labour, currently
Before a same-day dashboard exists, the typical path from a poorly staffed shift to someone noticing looks like this.
Step 01
A rota is built against a sales forecast in Fourth or Nory
A site manager builds next week's rota against a forecast that is usually a reasonable estimate based on last year's comparable week, but the forecast is rarely revisited once trading starts, even if a local event or the weather changes expected footfall significantly.
Step 02
Actual sales and actual hours worked diverge from the plan during the week
Sales come in higher or lower than forecast, and hours worked drift from the rota through late finishes, cover shifts and no-shows, but nobody is comparing the two figures against each other in real time, so the labour percentage for the week is effectively unknown until it closes.
Step 03
Payroll closes the week and calculates the actual labour cost
Once payroll processes actual hours and pay rates, a real labour cost figure exists, but by this point the week described is finished and any overstaffing or understaffing that happened cannot be corrected, only learned from for the following week if anyone reviews it closely.
Step 04
Wastage and stock variance are reviewed on a separate, often slower cycle
Stock takes happen weekly or fortnightly at many sites, and variance against theoretical usage is calculated after the fact, meaning a wastage problem that started three weeks ago is only caught at the next stock take, by which point it has repeated several times.
Step 05
A monthly report reaches the operations director well after the fact
Finance assembles a monthly pack comparing sites on sales, labour and stock, built from exports out of the EPOS, payroll and stock systems, which is useful for the board but far too slow to change how a specific site is being run this week.
Step 06
The best-performing site managers are rarely visible early enough to learn from
A site consistently running a lower labour percentage or lower wastage than its peers is a useful case study for the rest of the group, but without a standing comparison across sites, that pattern is noticed only occasionally, usually anecdotally, rather than surfaced systematically.
A dashboard does not change how a manager runs the floor on the night. It changes how quickly the pattern in the numbers reaches someone who can act on it — the difference between finding out about an overstaffed shift the same week rather than a month later, and the difference between spotting a stock variance after three days rather than after the next scheduled stock take.
What we build
Modules in a typical operations dashboard build
Wastage and stock variance tracking
Theoretical usage calculated from EPOS sales against recipe and portion data, compared against recorded stock movement in Fourth or Nory, with daily variance flags rather than waiting for the next scheduled stock take.
Site league tables
Sites ranked against each other on labour percentage, wastage rate, sales against forecast and other chosen metrics, refreshed daily or weekly and configurable per group.
Daily flash reporting
An automated morning report per site and rolled up across the group, covering net sales, covers, average spend, labour percentage and stock or wastage flags from the previous day's trading.
Forecast versus actual tracking
Sales forecast used to build the rota compared against actual sales as the week progresses, so a rota can be adjusted mid-week where the forecast is clearly off, rather than only reviewed after the week closes.
Group and regional roll-up views
A configurable view for area and regional managers showing only the sites in their remit, and a group-wide view for finance and senior operations, built from the same underlying data rather than separate reports.
Integrations
Named systems and interfaces
EPOS
LightspeedToastSquareZonalTevalis
Stock and labour
FourthNory
Payroll
payroll export formatsclock-in and clock-out data
Communication and reporting
email delivery servicesgroup finance systems
Fourth and Nory both expose APIs and scheduled export options for rota, actual hours and stock data; which mechanism we use depends on which the group's existing contract and configuration supports. Where a group runs neither, we work with whatever workforce or stock system is in place.
Data and compliance
Requirements written into the build
- Labour percentage definition
- Wage cost, including employer's National Insurance and pension contributions where the group wants them included, expressed as a percentage of net sales for the same period, agreed and fixed per client rather than assumed.
- Theoretical usage calculation
- Derived from EPOS sales quantities against recipe and portion specifications held in the stock system, refreshed whenever a recipe or portion size changes so variance is measured against the current standard.
- Tronc and tips data feed
- Service charge and tip totals by site, shift and staff member, reconciled from EPOS and card processor data, provided as a feed to the group's tronc administration process in support of Employment (Allocation of Tips) Act 2023 obligations.
- PCI DSS boundary
- The dashboard consumes aggregated sales totals from the EPOS, not transaction-level card data, and sits outside PCI DSS scope for card data as a result.
- Data retention
- Daily flash and variance data retained long enough to support seasonal comparison and forecasting, with retention periods agreed per client and aligned to their existing data retention policy.
Architecture note
How the system is put together
Data is pulled from each source system on its own schedule — EPOS sales overnight, payroll hours as they are confirmed, stock movement as it is recorded — and normalised into a single reporting model keyed by site and date, so the dashboard is never waiting on the slowest system to refresh before showing anything.
Labour and variance calculations run as a scheduled overnight batch rather than live queries against source systems, both because EPOS and workforce system APIs are not built for high-frequency polling and because a daily figure, refreshed reliably, is what operations teams actually act on.
League table rankings and flash report composition are configuration, not code, so a group can adjust which metrics matter to them, and in what order, without a development cycle each time priorities shift.
Access control reflects the group's management hierarchy — a site manager sees their site, a regional manager sees their region, finance and senior operations see the whole group — built once against the group's existing organisational structure rather than hardcoded per report.
Timeline
Build phases in weeks
Discovery
Weeks 1-3
Audit of EPOS, payroll and stock systems in use, data quality assessment, and agreement on labour percentage and variance definitions with finance.
Data pipeline build
Weeks 4-8
Extraction and normalisation of sales, labour and stock data from source systems into a unified reporting model.
Labour and variance calculation engine
Weeks 9-12
Labour percentage, theoretical usage and stock variance calculations, tested against a sample of sites for accuracy before wider rollout.
Dashboard and flash reporting
Weeks 13-16
Site, regional and group-level dashboard views, league tables, and automated daily flash report delivery.
Rollout and stabilisation
Weeks 17-19
Site-by-site rollout, manager training, and a defined period of tuning report composition based on management feedback.
Indicative cost
Budget bands, not quotes
- Discovery and scoping
- £10,000 to £22,000, credited against the build.
- Core dashboard with labour percentage and flash reporting
- £220,000 to £300,000.
- Full build including stock variance and league tables
- £300,000 to £380,000.
- Tronc and tips data feed module
- £25,000 to £50,000, often bundled with the core build.
- 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 already running an EPOS and either Fourth or Nory. A group with inconsistent stock-take discipline across sites, needing more work to standardise input data, sits at the upper end.
Where this sits
Related pages
Questions
Frequently asked
Do you replace Fourth or Nory, or build reporting on top of them?
We build reporting and dashboard layers on top of Fourth or Nory, pulling rota, actual clock-in and stock data out through their APIs or scheduled exports rather than replacing the systems that already manage scheduling and stock. Replacing either is a significant undertaking that is rarely the actual gap; the gap is almost always that the data they hold never reaches management in a usable, timely form.
How quickly after a shift can labour percentage be reported?
Once EPOS sales data and actual clock-in and clock-out times are both flowing into the dashboard, labour percentage against sales is available the same day, typically calculated overnight for the previous day's trading, rather than waiting for a weekly payroll run to close before anyone sees the figure.
How is stock variance calculated, and does it need a full stock take?
Theoretical usage is calculated from EPOS sales against recipe and portion data, and compared against actual stock movement recorded through Fourth or Nory's stock module. A full physical stock take is still needed periodically to correct for drift, but the dashboard flags variance daily using theoretical-versus-recorded-usage, which surfaces a problem well before the next full stock take would catch it.
What goes into a daily flash report, and who sees it?
A flash report typically covers net sales, covers, average spend, labour percentage, and any stock or wastage flags for the previous day, per site and rolled up across the group, sent automatically each morning to site managers, area or regional managers, and finance. The exact composition is configured per client, since what a regional manager needs to see daily differs from what a finance director reviews weekly.
What is a site league table, and is it meant to create competition between managers?
It ranks sites against each other on chosen metrics — typically labour percentage, wastage rate and sales against forecast — refreshed daily or weekly. Some groups use it deliberately to create visible, low-stakes competition between site managers; others use it purely as a triage tool for where an operations director should focus attention first. We build the ranking; how a group chooses to present or use it internally is theirs to decide.
Does this dashboard need access to card payment data?
No. The dashboard consumes aggregated sales, labour and stock figures from the EPOS, payroll and stock systems, not transaction-level card data, so it sits outside PCI DSS scope for card data specifically, while still drawing on the sales totals those systems produce.
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