Restaurant inventory and labour costClient work · not named
Inventory drift and labour cost, out of the till system and in front of the operator
A restaurant runs on two levers, and both are already recorded every day. The problem is where they are recorded. This is the pipeline and the reporting that make them visible while there is still time to act on them.
Sample data, white-labelled. The client system is private.
A venue lives or dies on two numbers: what it bought against what it actually sold, and what it paid people to do it as a share of those sales. Both are recorded every day, by systems that already exist and are already paid for.
They are recorded inside a system built for taking orders and paying staff — not for running a business. Getting a usable picture out of it means someone exporting, someone assembling and someone interpreting, so the number arrives a month later, which is a point of margin too late to act on.
And when it does arrive, nobody can tell whether it is complete. A report built on four days of a seven-day week looks exactly like a report built on all seven, right up until a decision is made on it.
A small amount of reporting on top of a pipeline that has to be right every day, unattended.
Scheduled ingestion
Inventory and labour data is read out of the venue’s management system on a schedule and stored where it can actually be queried, instead of living inside a screen that has to be re-read by a person.
Drift, computed rather than eyeballed
What should have been used against what was actually used, per period — so a pattern becomes visible while it is still a pattern, rather than after it has become a quarter.
Labour against the sales it produced
Hours and cost lined up against the revenue of the same period, at the granularity the operator actually schedules in.
Reporting for the operator
Written for whoever is running the venue, not for a finance department: the two levers, current, in a form that supports a decision this week.
Diagnostics beside every pull
Checks run alongside every ingestion, so a broken or missing feed announces itself. A quiet failure that produces a clean-looking report built on half a week of data is the most expensive failure this kind of system has, and it is the one it is built to make impossible.
No vendor names, deliberately — what matters is the surfaces, not the parts.
- 01The venue’s existing management system, for sales, inventory and labour
- 02A scheduled ingestion path rather than a manual export
- 03A store the data can be queried from
- 04Operator-facing reporting on the two levers
- 05Diagnostics that run beside every pull
The reporting is the visible part and the smaller part. The cost sits in ingestion: a system built for orders does not hand its data over in a shape anyone would have designed, and every source that can change without warning has to be watched rather than trusted.
In the terms used on the cost guide this is scheduled collection plus a daily report — the band where effort is decided by how many sources there are and how badly they behave, not by how many screens end up on top.
This one runs on a venue’s own sales and cost data, so nothing measured by it is published here. The interactive demo runs on sample data.
Built and delivered. Private by nature — it runs on a venue’s own sales and cost data, which is why the demo is white-labelled and the client is not named.
Does this describe your operation?
Five to ten minutes on the phone is enough to tell whether the same shape of system fits what you are running — or whether it does not.
Free · 5–10 minutes · no obligation