A restaurant KPI system works as a tree, not a list. Net profit sits at the root; below it are four levers — revenue, cost of goods, labour and fixed cost; below those sit the daily numbers that move each lever. A metric with no lever above it and no decision below it does not belong on the tree.
Why a list of KPIs fails and a tree does not
Every guide to restaurant metrics you will find is a flat list: food cost, labour cost, average check, table turns, covers, prime cost, waste, no-shows. Twenty names in a column. The list is not wrong. It is unusable, and for one reason: it does not tell you what to do when two numbers move in opposite directions on the same day.
Each row below is a component of the row above
Your average check goes up and your covers go down. Is that good? The list cannot answer. A tree can, because on a tree those two numbers are multiplied together and both sit under the same parent — revenue. You look one level up, and the question stops being philosophical.
A tree does three things a list cannot do. It tells you where a number belongs, so you stop collecting metrics that answer nothing. It tells you what a number is worth, because you can trace the arithmetic from a leaf all the way to profit. And it tells you who owns it, because ownership follows the branch, not the alphabet.
This page is the map for the whole restaurant cluster on this site. Each branch below links to the page that unpacks it. Start at the root and walk down; do not start with the metric that happens to be easiest to measure.
The root: one number every other number exists to serve
KPI — a measure tied to a decision someone actually makes, not every number a system can produce.
KPI tree — a hierarchy whose spine is arithmetic: every metric on the main line is joined by a formula to the one above it, all the way to the root. Causal leaves hang off the branches as well — the ones that explain a branch's movement without appearing in its formula. The difference between the two is unpacked below, at the full tree, because it decides what comes off the tree and what stays on it.
The root of the tree is net profit. Not revenue, not gross margin, not "covers last night". Written out in full, so you can see every branch that hangs off it:
Net profit = Sales − COGS − Labour − Occupancy − Opex − Depreciation − Interest − Tax
Sales— net revenue for the period, excluding VAT, discounts and voided checks, PLN;COGS— cost of goods sold in the same period, PLN;Labour— total labour cost including employer contributions, PLN;Occupancy— rent, service charge and utilities for the premises, PLN;Opex— other operating expenses: marketing, cleaning, small equipment, software, PLN;Depreciation— the period's write-down of fit-out and equipment, PLN;Interest— cost of debt for the period, PLN;Tax— income tax on the result, PLN.
Two remarks that matter more than they look. First, depreciation belongs in the equation. A tree that stops at "revenue minus prime cost minus rent" does not close, and the owner who builds it will spend a year wondering where the money went — it went into the kitchen fit-out, one month at a time. Second, only the first five terms are managed weekly. Depreciation, interest and tax are consequences of decisions you already made; they sit in the root line but they are not levers, and putting them on a weekly screen creates noise, not control.
Net profit is not the money in the bank
Worth saying plainly, because a great many places founder on this confusion. The root of the tree counts the result, not the balance. A wedding deposit, a supplier's payment terms, a security deposit, the instalment on the oven, VAT due — none of them sits in the net profit line, and every one of them moves your bank account. Having a positive result and a liquidity gap in the same month is not a contradiction; they are two different questions.
That is why the result and the cash are tracked separately. The tree on this page answers "is this worth doing". The question "will there be money to pay on Friday" is answered by lining up money in against money out over time — that is what our finance module is for, and predicting the money in is what forecast does. Confusing the two usually costs a lot of sleep and not one extra PLN of profit.
The second level: four levers, and only four
Everything you can change this month lives in one of four places.
| Lever | What it is | Direction that helps | Where it is unpacked |
|---|---|---|---|
| Revenue | how much money the room brings in | up | this page, then RevPASH |
| Cost of goods | what the food and drink cost you | down, without cutting the guest's plate | prime cost |
| Labour | what the people cost you, fully loaded | down per unit of output, not per head | prime cost |
| Fixed cost | rent, utilities, subscriptions | down, but rarely and slowly | this page |
The fourth lever is the one owners underestimate. Fixed cost does not respond to effort, only to renegotiation and to volume — which is why a restaurant with the wrong rent cannot be saved by a better menu, and why the first honest question about a struggling site is arithmetic, not culinary.
Two of these levers are usually managed as one number, because they move together and because staff cuts and portion cuts trade off against each other:
Prime cost % = (COGS + Labour) ÷ Sales × 100
COGS— cost of goods sold for the period, PLN;Labour— total labour cost for the same period, PLN;Sales— net sales for the same period, PLN;- result — a percentage of sales.
All three quantities have to come from the same period. Cost of goods for a month divided by sales for a week is not an imprecision; it is a number with no meaning.
The third level: the daily numbers, and which lever each one hangs from
Revenue splits first, and it splits into two numbers that pull against each other:
Sales = Covers × Average spend per cover
Covers— number of guests served in the period, guests;Average spend per cover— net sales divided by guests, PLN per guest;- result — PLN.
Covers — the number of guests served in a period. Not the number of checks, and not measured in seat-hours.
Average spend per cover — net sales divided by the number of guests. If you calculate it per check instead of per guest, that is a different quantity; say which one you mean every time, because in a room laid out for twos the gap between the two can be twofold.
These two are not independently controllable, and any page that tells you they are is wrong. A full room with a small check and a half-empty room with a large one produce identical revenue. The trade-off between them is the whole subject of RevPASH and of table turnover; this page only puts them in their place on the tree.
Covers splits once more, into capacity and how often that capacity is reused:
Covers = Seats × Turns
Seats— number of guest seats available in the period, seats;Turns— average number of times one seat is occupied by a new party in the period, dimensionless;- result — guests.
A warning about this line, because a previous version of this page got it wrong and the error is instructive. Covers = available seat-hours × seat occupancy is dimensionally broken: seat-hours multiplied by a share gives you occupied seat-hours, and guests are not measured in seat-hours. If a formula's units do not resolve to the unit of the thing on the left, the formula is decoration.
The full tree, level by level
| Level | Metric | Where it comes from | Hangs under | Owner | Frequency |
|---|---|---|---|---|---|
| 0 | Net profit | Sales − all cost lines | — | owner | month |
| 1 | Revenue | Covers × Average spend per cover | Net profit | owner | week |
| 1 | Cost of goods | purchases ± stock movement | Net profit | head chef | week |
| 1 | Labour | wages + employer contributions | Net profit | shift manager | week |
| 1 | Fixed cost | rent + utilities + subscriptions | Net profit | owner | quarter |
| 2 | Covers | Seats × Turns | Revenue | shift manager | shift |
| 2 | Average spend per cover | Sales ÷ Covers | Revenue | shift manager | shift |
| 2 | Prime cost % | (COGS + Labour) ÷ Sales × 100 | two branches at once | owner | week |
| 3 | Turns | counted on the floor: how many times a seat took a new party | Covers — as an input multiplier, not a quotient | shift manager | shift |
| 3 | Waste | value written off ÷ COGS | Cost of goods | head chef | week |
| 3 | Stockouts | count of items unavailable | Cost of goods and Revenue — causally | head chef | shift |
| 3 | Hours scheduled vs worked | difference in hours | Labour — causally | shift manager | shift |
Read it as arithmetic, not as a wish list. But before you apply this page's own test to this page's own table, one thing has to be named that most guides leave unsaid: two different kinds of row hang under a parent here, and only one of them hangs there arithmetically.
Arithmetic leaf — it enters the parent's formula as a term or a multiplier. Covers and average spend multiply into revenue; cost of goods and labour subtract from sales. For a leaf like that you can trace the path to the root by arithmetic alone.
Causal leaf — it appears in no formula of the parent, but it explains the parent's movement. Stockouts enter neither the revenue formula nor the cost-of-goods formula; they enter the explanation of why both moved. Hours scheduled against hours worked is measured in hours while its parent is measured in PLN, and that difference does not reduce to PLN on its own until you multiply it by the loaded hourly cost.
Both kinds belong on the tree, but the ticket is different. An arithmetic leaf passes this test: "I can write the equation that links it to its parent." A causal leaf passes a stricter one, precisely because there is no equation: "I can name which branch it moves, in which direction, and what I do at what value." A metric that passes neither comes off the tree — "it is interesting to look at" is not a ticket.
And one more case, separate from both, because other people's tables copy it wrong: turns is an input multiplier, not a quotient. If Covers = Seats × Turns, then writing Turns = Covers ÷ Seats is the same equation moved to the other side. If you compute turns by dividing covers by seats you have measured nothing new — you have re-derived your own input, and a child derived from its parent carries not one gram of information. Turns is counted on the floor: how many times one seat took a new party during the service. The division is a check on that count, not its source.
Leading and lagging: the distinction people get backwards
Leading indicator — a measure that moves before the outcome does: bookings on the book, staffing gap, stockouts.
Lagging indicator — a measure that confirms the outcome after the fact: net margin, monthly food cost.
| Metric | Leading or lagging | Fires before which event | Confirmed later by |
|---|---|---|---|
| Bookings on the book | leading | the shift itself | covers |
| Staffing gap for the shift | leading | the service | labour cost, guest complaints |
| Stockouts | leading | lost sales and substitutions | average spend per cover |
| Covers | lagging for the shift, leading for the month | monthly revenue | revenue |
| Prime cost % | lagging | — | net profit |
| Net margin | lagging | — | — |
You will notice there is no column saying how many days earlier each leading indicator fires. There is no such column on this page on purpose: filling it honestly requires a number of days, and no source produces that number for restaurants. An invented column looks more precise than an absent one and is worth less.
The practical rule is simpler than the taxonomy. Leading indicators belong on the shift screen, because someone can still act on them. Lagging indicators belong in the monthly conversation, because by the time they exist the shift is over. A restaurant that only watches lagging numbers is not managing; it is doing an autopsy every four weeks.
The leading indicator owners underrate most is the state of the reservation book together with how many of those bookings are confirmed. An unconfirmed booking and a confirmed one are two different numbers, even though most systems display them identically — the no-show confirmation chain takes that apart in full. The book itself is kept by our bookings module.
Frequency: what is worth looking at, and how often
| Metric | Shift | Week | Month | Who reads it |
|---|---|---|---|---|
| Covers | yes | yes | yes | shift manager, then owner |
| Average spend per cover | yes | yes | yes | shift manager |
| Stockouts | yes | yes | — | head chef |
| Hours worked vs scheduled | yes | yes | — | shift manager |
| Bookings on the book | yes | yes | — | shift manager |
| Food cost % | — | yes | yes | head chef, owner |
| Labour cost % | — | yes | yes | owner |
| Prime cost % | — | yes | yes | owner |
| Fixed cost | — | — | quarterly | owner |
| Net profit | — | — | yes | owner |
Reading a metric more often than you can act on it is not diligence, it is noise. Food cost measured daily on a restaurant that receives deliveries three times a week will swing wildly for reasons that have nothing to do with the kitchen — the stock arrived on Tuesday and was eaten by Friday. Match the reading interval to the interval at which the underlying thing actually changes.
Setting a target when no benchmark exists for your format
This is the section most guides skip, and it is the one you will need first.
Target — a value the operation commits to, with a named owner and a review date.
There is no official statistic for restaurant food cost, prime cost, table turns or covers per seat in Poland. That is not a figure of speech but the result of checking both places where such a statistic for Poland is produced at all — and you can repeat the check:
- Eurostat, dataset
sbs_ovw_act(databrowser, updated 10 March 2026) defines forty-eight indicators; for the Polish NACE I56 division and reference year 2023, forty of them carry a value and eight come back from the query empty (EMP_MFG_PC,GRW_EMP_PC,AV_MFG_PC,VAL_OUT_MFG_PC,PUR_NRG_MEUR,STK_CHG_GD_FIN_MEUR,GM_GD_RS_MEUR,NETTUR_MFG_PC). Among those forty: net turnover, purchases of goods and services, employee benefits expense, value added, gross operating surplus, gross operating rate, hours worked, investment, the number of enterprises and the number of persons employed. Food cost, prime cost, table turns and covers per seat are not among them — checked indicator by indicator on 26 August 2026. - GUS, "Rynek wewnetrzny w 2024 r." (published 3 November 2025) gives food service exactly two tables: Table 6, the count of catering establishments, and Table 7, revenue from catering activity. Neither carries a cost structure or a table turn — cost lines in that publication are broken out for trade, not for food service.
The percentage ranges that circulate in the industry anyway — one for prime cost, another for food cost — come from vendor blogs quoting each other. You do not have to take that sentence on trust: open one such document by name. The 2024 Restaurateur Benchmark Guide, published by Leverage Buying Group in October 2024 prints prime cost, food cost, labour cost and margin ranges by restaurant format, and on its own citations page for those ranges it lists: Restaurant365, TheForkCPAs, ZocaloSac, TouchBistro, ToastTab, Jalebi, GetBento, Solink, LineUp.AI, UpMenu — and alongside them the National Restaurant Association. Most of that list is the marketing pages of companies selling software to restaurants; not all of it, because the National Restaurant Association is a trade association, not a software vendor. None of them is a statistical office, though, and not one range carries a sample, a method or a year of measurement. So you will not find those ranges printed as norms anywhere on this page, and you should distrust any page that prints them.
The same dataset does describe the shape of the sector, and one number out of it matters for your tree.
sbs_ovw_act, updated 10 March 2026, reference year 2023).The conclusion for your labour branch is worth this one line: it looks cheap not because labour in Poland is cheap, but because so much of it happens outside payroll — that is, outside this very number. Your own tree has to count that work, unpaid owner hours included, because the statistic cannot see it and your result can.
The full table — turnover, purchases of goods and services, both shares, and the three-part caveat on why those percentages must not be added together and called prime cost — is not repeated here. It stands in full on the page about prime cost, which is where that table belongs: one table in two places starts to differ sooner or later.
So you set targets from your own history. The method has three steps and no statistics in it.
Step one: establish your own baseline
Take the metric over the last N comparable periods — comparable meaning same day of week, same season, same trading hours — and take the median, not the average. The median survives one catastrophic Saturday; the average does not.
If you do not have N comparable periods yet, then you do not have a baseline, and no trick gets around that. Keep collecting, and in the meantime run the metric with no target at all — that is more honest than a target pulled out of the air.
Step two: decide the size of the step, and say out loud that it is a decision
Gap to target = Target − Own baseline
Own baseline— median of the metric over N comparable periods, in the metric's own unit;Target— the committed value, same unit;Gap to target— same unit.
The arithmetic is trivial. The honest part is admitting that the size of the step is a management decision, not a statistic: nothing in any dataset tells you whether your food cost should improve by one point or three. What the tree gives you is the ability to price the step, which is step three.
Step three: price one point of movement before you chase it
Profit impact of 1 pp = Sales × 0.01
Sales— net sales for the period, PLN;0.01— one percentage point expressed as a share, dimensionless;- result — PLN of profit per percentage point of any cost line expressed as a share of sales.
Worked through: on 400 000 PLN of monthly net sales, one percentage point is 4 000 PLN a month. That single number decides whether a two-week project to shave food cost is worth doing, and it is the reason this page insists on the tree — you cannot price a leaf whose path to the root you cannot draw.
One caution, and it is the kind of mistake that quietly inflates every business case: these impacts are not additive across overlapping metrics. Food cost and labour cost are both inside prime cost. Add the impact of improving food cost to the impact of improving prime cost and you have counted the same PLN twice. Price each branch once, at the level you intend to act on.
The one branch where the number is official: the Polish minimum wage
There is exactly one input on this tree that Polish law fixes and publishes, and it belongs to the labour lever. Under the Council of Ministers regulation of 11 September 2025, published in Dziennik Ustaw of 15 September 2025, item 1242 (Dziennik Ustaw 2025 poz. 1242), the Polish minimum wage from 1 January 2026 is 4806 PLN and the minimum hourly rate is 31.40 PLN. As at 1 January 2026. Both figures are gross for the employee, and neither is your cost per hour: employer social contributions sit on top, and the multiplier depends on the contract type and the insurance code, so no single official coefficient exists. Calculate your loaded hourly cost from your own payroll and use that in the tree:
Loaded hourly cost = (Gross wages + Employer contributions + Other staff charges) ÷ Hours worked
Gross wages— gross pay accrued for the period, PLN;Employer contributions— employer-side contributions and levies for the same period, PLN;Other staff charges— staff meals, uniforms, medical checks, training, PLN;Hours worked— hours actually worked in that same period, hours;- result — PLN per hour.
Both of those are Polish national figures, they cover a section wider than restaurants alone — hotels sit inside it — and they come from preliminary data. Context, not your cook's rate.
Two trees from one root: the shift manager's and the owner's
The tree is the same; the visible portion is not.
The shift manager sees leaves and only leaves — covers so far tonight, bookings still to arrive, stockouts, hours scheduled against hours worked. Every one of them is actionable within the next two hours. None of them is a percentage of anything, because percentages of monthly totals cannot be acted on during a service.
The owner sees the root and the four levers, plus one composite — prime cost — that spans two of them. The owner's screen answers a different question: not "what do I do now" but "which branch is drifting". If those two screens are the same screen, one of the two people is reading numbers they cannot use.
Between them sits the head chef, whose branch is cost of goods, and whose leaves are waste, stockouts and recipe adherence. That third tree is the one most often missing entirely, which is why food cost variance so often has no owner and therefore no explanation. The mechanics of building those screens are a separate subject — our article on reporting automation covers how the numbers get shown; this page is about which numbers deserve a place.
Comparing locations: normalise first, or the comparison lies
Normalisation — adjusting for seat count, trading hours, price level or currency before comparing locations.
Two sites in the same brand, one with 60 seats open twelve hours, one with 90 seats open nine hours. Raw revenue says the second is stronger. Raw revenue is comparing a different amount of capacity for a different amount of time and calling the difference performance.
Normalise on the dimension that actually differs. Different seat counts: divide by seats. Different trading hours: divide by hours. Both: divide by seat-hours, which is exactly what RevPASH does, and which Cornell's Sheryl Kimes introduced for this reason — in her words, RevPASH "indicates the rate at which revenue is generated and captures the trade-off between average check and facility use" (Sheryl E. Kimes, "Restaurant Revenue Management", Cornell Center for Hospitality Research, 1 February 2004 — PDF). Different price levels between a city-centre site and a suburban one: compare movements, not levels, because the levels were never comparable.
The single most common error in chain reporting is ranking sites on a metric whose denominator differs between them. If you do nothing else from this section, check the denominator before you rank. Running several sites off one screen is its own discipline; we wrote about the practical side of it in managing a chain from one screen.
Give every metric an owner and a decision, or delete it
Here is the test that keeps the tree from growing back into a list. For each metric, write two sentences: who is accountable for it, and what they will do differently at what value. If either sentence cannot be written, the metric comes off the tree.
Alert threshold — the deviation at which a number stops waiting to be read and calls a person. How thresholds are set, and why a single percentage deviation cannot serve every metric, belongs to the page on the AI layer, which owns that subject in full.
The ownership rule also settles the question of how many KPIs are too many, which is usually answered with an invented number. The right answer is not a count. It is: as many as have both an owner and a decision, and not one more. In a small independent restaurant that is a short list. In a group with a head office it is longer, because there are more people to own things — the constraint is the number of decision-makers, not the number of measurements.
Where the data comes from, before you build anything
A tree without data is a drawing. Before you start, check which branches you can already feed.
Revenue, covers and average spend per cover usually arrive on their own, out of the till and the point-of-sale system, with nobody doing anything. Bookings and no-shows arrive from the reservation system — if you have one and if the floor staff actually keep it. Cost of goods needs invoices and stock counts, which means a discipline the kitchen may not have yet. Labour cost sits in payroll, but attributing it to particular shifts and to output is work. Fixed cost you know from your contracts, and it is the one branch nobody has to measure.
The rest depends on how the whole place is organised — on whether orders, bookings and enquiries are recorded anywhere at all, or merely pass through the phone and vanish. Sorting that out is the subject of restaurant automation, and the question of which system layer to add next is unpacked in CRM or ERP. Guest records and contact history live in the CRM module, and the reservation side in bookings.
One channel is worth checking separately, because owners most often do not count it at all: what happens to your restaurant online before a guest ever crosses the threshold. Who keeps the hours, the menu and the prices current in search and on the portals is covered in restaurant data in Google; what stays with you out of an order placed online and what the intermediary takes is covered in online orders.
Where to cut the tree first
If you are starting from nothing, do not build all three levels. Build the root, the four levers, and exactly the leaves that connect to a decision you already make.
Start with the branch where you already have data you trust. For most independents that is revenue, because the point-of-sale system produces covers and average spend per cover without anyone doing anything. Cost of goods usually comes second and hurts more, because it requires stock counts and those require a discipline the kitchen may not have yet. Labour is third — the payroll numbers exist, but attributing them to shifts and to output takes work. Fixed cost is last, not because it is unimportant but because you look at it once a quarter and then renegotiate or move.
Do not start with the metrics that are fashionable. Waste percentage, guest satisfaction score and marketing attribution are real, but each of them sits three levels down and needs the levels above it to be readable first. Pulling data together across systems is a prerequisite, not a KPI — if you are still deciding which system layer to add, CRM or ERP is the more useful question, and the wider picture of what to automate in a restaurant is covered in restaurant automation.
What KPIs will never show you
The tree is arithmetic, and arithmetic has a boundary. It will not tell you that the head chef is about to resign, that the landlord is talking to another tenant, or that the neighbourhood is changing. It shows the consequences of those things one to three months late, in the lagging leaves, which is precisely too late.
It will also not tell you why a number moved. Covers fell twelve percent; the tree tells you which lever that hit and what it cost. Whether it was the weather, a road closure, a competitor opening or a bad review is not in the data, and the temptation to guess and then act on the guess is the single most expensive habit in restaurant management. If demand is what you want to anticipate rather than explain after the fact, that is a separate discipline with its own method and its own error measurement — see demand forecasting.
And it will not make the decision. A KPI narrows the question from "what is wrong with my restaurant" to "the labour branch drifted two points in three weeks and the shift where it happened is Friday dinner". That is the whole promise. The rest is management.
Aura is the management layer over these numbers — where the tree gets assembled from your own systems and the branches get owners. If you want to see what it looks like on your own data, our dashboards and analytics build the tree, AI reports narrate the movements, finance closes the root line, forecast and what-if work on the branches that have not happened yet, external signals supply the context the tree cannot see on its own, and decision engine, team and tasks turn a drifting branch into something a named person is doing on Monday.
Frequently asked questions
What are the most important KPIs for a restaurant?
Net profit at the root, and beneath it four levers: revenue, cost of goods, labour and fixed cost. Below those, the daily numbers that move each lever — covers, average spend per cover, waste, stockouts, and hours scheduled against hours worked. Importance is not a property of a metric in isolation; it comes from the metric's position on the tree and from whether anyone acts on it.
What is a KPI tree and why is it better than a KPI list?
A KPI tree is a hierarchy with an arithmetic spine: every metric on the main line is joined by a formula to the one above it, ending at net profit at the root, while causal leaves hang off the branches as well — they explain a branch's movement without appearing in its formula. A list tells you what to measure; a tree tells you what each measurement is worth and what it belongs to. When two metrics move in opposite directions, a list cannot resolve the conflict and a tree can, because you look one level up to the parent that contains both.
What is the difference between leading and lagging indicators in a restaurant?
A leading indicator moves before the outcome does — bookings on the book, staffing gaps, stockouts — and can still be acted on. A lagging indicator confirms the outcome after the fact: net margin, monthly food cost. Leading indicators belong on the shift screen, lagging ones in the monthly review. A restaurant that watches only lagging numbers is performing an autopsy, not managing.
How many KPIs should a restaurant manager track?
As many as have both a named owner and a decision attached, and not one more. There is no correct count, and any specific number you see quoted has no source behind it. The binding constraint is the number of people who can act, not the number of things a system can measure — which is why a single-site independent tracks far fewer metrics than a group with a head office, and is right to.
How often should restaurant KPIs be reviewed?
At the interval at which the underlying quantity actually changes, and no more often. Covers, stockouts and hours worked are shift-level. Food cost, labour cost and prime cost are weekly and monthly. Fixed cost is quarterly. Net profit is monthly. Reading food cost daily in a restaurant that takes deliveries three times a week produces swings caused by delivery schedules, not by the kitchen.
How do I set a KPI target without an industry benchmark?
From your own history, because for restaurant food cost, prime cost and table turns no official benchmark exists in Poland — the circulating ranges come from vendor publications citing each other. Take the median of the metric over comparable periods, set the target as a step from that median, and be explicit that the size of the step is a management decision rather than a statistic. Then price the step before committing to it.
How do I compare KPIs across restaurant locations fairly?
Normalise on whatever differs between the sites before you compare. Different seat counts: divide by seats. Different trading hours: divide by hours. Both: divide by seat-hours. Different price levels: compare movements rather than levels, because the levels were never comparable. The most common error in chain reporting is ranking locations on a metric whose denominator is not the same for all of them.
Which KPIs belong on a shift screen rather than in a monthly report?
Anything a person on shift can still change: covers so far, bookings still to arrive, stockouts, hours scheduled against hours worked, and the tables currently held. Percentages of monthly totals do not belong there, because nobody can act on a month during a service. The test is whether the number can change a decision in the next two hours.
Start at the root of your own tree: write down net profit, the four levers under it, and the leaves you can already measure — then see which branches have no owner. That gap is usually the answer. The restaurant section of this site unpacks each branch in turn.