Restaurant Benchmarking: The Number Can Be Right and the Decision Still Wrong

HOSPITALITY INSIGHTS · REVENUE & COSTS

Restaurant benchmarking can tell you that your labour cost is 34% while another operation is running at 28%.

It can tell you that your food cost is above an industry reference point.

It can tell you that your revenue per labour hour is lower than somebody else’s.

All of those numbers can be perfectly correct.

And you can still make the wrong decision because of them.

That is the problem I have with the way benchmarking is sometimes used in hospitality.

Not the benchmark itself.

The leap from measurement to explanation.

34% labour. Too high. Cut hours.

Food cost above benchmark. Purchasing problem. Squeeze the supplier.

Revenue per employee below average. Productivity problem. Push the team harder.

A measurement has suddenly become an explanation.

It isn't.

A benchmark is a reference point. It shows you where a difference exists. It does not tell you what created that difference, whether the difference is harmful, or what you should do about it.

If you skip that distinction, an accurate number can become the starting point for a very expensive mistake.

The Benchmark Is Not the Problem

I use numbers.

I need numbers.

Running hospitality operations without them would be like driving at night with the lights switched off.

But I also know what happens when the spreadsheet and the floor are allowed to become the same thing.

They aren't.

Imagine your labour cost is running at 34%.

Your benchmark says comparable restaurants operate at 28–30%.

There is a gap.

That is real.

But what exactly have you learned?

You have learned that your labour percentage is higher than the reference point.

Nothing more has been established yet.

• Maybe you are overstaffed.
• Maybe your scheduling is poor.
• Maybe your sales volume is too low for the labour structure you are carrying.
• Maybe your kitchen layout is forcing unnecessary movement.
• Maybe experienced employees are spending half their shift correcting information that should have arrived correctly the first time.
• Maybe your delivery platforms have created an additional workload that the headline revenue figure doesn't expose.
• Maybe your service model deliberately requires more labour than the businesses inside the comparison group.
• Or maybe 34% really is simply too high.

All of those remain possible.

The benchmark has shown you where to look.

It has not yet told you what you are looking at.

That difference matters.

A Benchmark Is a Readout, Not an Instruction

This is where operators can get into trouble.

We see a number outside the expected range and immediately feel pressure to act.

That is understandable.

Hospitality doesn't give us unlimited time to investigate everything.

Wages are due.

Suppliers need paying.

Margins are tight.

The next service is coming whether yesterday made sense or not.

So a clean number is attractive.

It feels solid.

34% versus 28%.

There it is.

Something to fix.

But a benchmark is closer to a weighing machine than an instruction manual.

If the machine says 94 kg, it has done its job.

It does not know why you weigh 94 kg.

It does not know whether 94 kg is appropriate for you.

And it certainly cannot tell you what you should remove to make the number smaller.

The danger begins when we ask the measuring tool to do a job it was never designed to do.

Before You Benchmark, Ask: Compared With What?

There is another problem hiding behind the number.

The comparison itself.

A restaurant is not simply a restaurant.

A counter-service operation and a full-service restaurant may sell food, employ people and process payments, but their labour structures are not automatically comparable.

A beach operation dealing with weather-driven peaks is not mechanically identical to a city-centre restaurant with relatively predictable covers.

A venue carrying event capacity may look inefficient on a normal day and completely different when 2,000 people arrive inside a compressed period.

A business with a large delivery share may carry work that another restaurant never performs.

Even two apparently similar restaurants can have different opening hours, menu complexity, service expectations, purchasing structures and revenue mixes.

So before I react to a benchmark, I want to know:

• Who am I being compared with?
• What exactly is being measured?
• Are the operating conditions comparable?
• What has been excluded from the number?

If those questions aren't clear, the benchmark may still be mathematically correct.

But the read can already be moving in the wrong direction.

The Number Is the Signal

This is where I approach benchmarking differently.

I don't want to ignore the number.

I want to stop it from becoming a story too early.

If labour moves from 29% to 34%, that interests me.

Something changed.

But instead of immediately saying:

«“Labour is the problem.”»

I would rather ask:

«“What changed in the operation that produced this number?”»

Now we have somewhere useful to go.

• Did sales fall while scheduled hours stayed constant?
• Did preparation time increase?
• Did menu complexity change?
• Did a new ordering platform add work?
• Did opening hours expand without producing equivalent revenue?
• Did a handover fail, causing employees to repeat work?
• Did one experienced person become the Senior Anchor everyone now depends on?
• Are employees compensating for a process that no longer carries its own weight?

Those questions do not reject the benchmark.

They put it to work.

The number becomes a signal.

And signals need tracing before they need fixing.

Right Number. Wrong Read. Expensive Intervention.

Let's return to the 34% labour example.

Suppose management decides the benchmark proves the restaurant is overstaffed.

Hours are cut.

The percentage comes down.

Success?

Maybe.

But now watch the operation under load.

Tickets begin waiting longer.

Tables turn more slowly.

One experienced employee starts covering three decision points.

Preparation slips into service.

Managers jump onto stations instead of managing the floor.

Guests wait longer to order another drink.

Small corrections start becoming normal.

Nobody records those corrections because everyone is too busy making service work.

The labour percentage improved.

The operation weakened.

And several weeks later revenue starts moving in the wrong direction.

Now the operator has another number to investigate.

This is why I don't believe operational performance can be managed by chasing isolated percentages.

You can improve a metric and damage the mechanism that produced the revenue behind it.

The spreadsheet may congratulate you before the floor sends the bill.

Benchmark the Difference. Trace the Cause.

Restaurant benchmarking becomes much more useful when we give it a defined job.

Use the benchmark to identify the gap.

Then stop.

Don't explain it yet.

Take the gap back into the operation.

• If labour is high, trace where labour is actually being consumed.
• If food cost is high, trace where product becomes cost.
• If revenue per labour hour is weak, trace what people are doing during those hours.
• If technology was supposed to save time, trace what work remained after the technology was introduced.
• If throughput is below the reference point, follow the order rather than immediately blaming the kitchen.

You are looking for the point where expected performance and actual behaviour separate.

Sometimes the explanation will be exactly what you suspected.

Fine.

But now you have evidence.

Other times, the signal will lead somewhere completely different.

That is why I separate the signal from my interpretation of it.

The signal tells me what changed.

The explanation still needs evidence.

Don't Make the Team Pay for a Number You Haven't Traced

This matters particularly when the benchmark involves people.

Labour is visible.

That makes it easy to attack.

You can see the rota.

You can see the hours.

You can calculate the percentage.

What is harder to see is the work the team is doing because something else isn't working.

• An employee re-entering information between two systems appears as labour cost.
• A supervisor repeatedly answering the same operational question appears as labour cost.
• A bartender walking unnecessarily because the station is badly configured appears as labour cost.
• A kitchen employee correcting unclear tickets appears as labour cost.
• A manager rescuing failed handovers appears as labour cost.

The payroll records the person.

It doesn't record the friction that consumed the person's time.

Cutting the person may reduce the visible number while leaving the invisible work exactly where it was.

Now fewer people are carrying the same friction.

That isn't efficiency.

That's compression.

And compression eventually shows itself somewhere else.

Benchmarking Should Create a Question, Not Close One

This is the part I would change in the way many operators use restaurant benchmarking.

Don't finish with:

«“We're six points above benchmark.”»

Start there.

Ask:

«What would have to be happening inside this operation for this number to make sense?»

Then go and look.

Not during the quietest hour of Tuesday afternoon if the problem appears Friday at 20:15.

Put the assumption under representative load.

Watch the handovers.

Follow the information.

Follow the product.

Follow the decision.

Follow the money.

And pay particular attention to the moments where somebody has to compensate for the system.

That is often where the spreadsheet loses sight of what the operation is actually doing.

The Benchmark Doesn't Owe You an Explanation

This is why I don't blame benchmarking tools when operators misuse their output.

If a benchmark accurately shows that your number differs from a reference group, it has done its job.

The tool doesn't owe you the cause.

That wasn't necessarily the job you gave it.

The mistake happens when we silently expand its authority:

Measurement becomes interpretation.

Interpretation becomes explanation.

Explanation becomes intervention.

And somewhere between those steps, nobody went back to the floor to check whether the story was true.

That is where I want the operator to interrupt the sequence.

Read the Signal Before You Fix the System

The next time a benchmark tells you that something is outside the expected range, resist the urge to immediately bring the number back into line.

First ask what the number actually proves.

Then ask what it doesn't prove.

Then trace the work that produced it.

A good benchmark can tell you that something deserves attention.

That is valuable.

But the benchmark is not standing beside your pass when the printer starts screaming.

It isn't watching the bartender repeat an order entry.

It doesn't see the manager becoming the decision point for every exception.

It doesn't know why one apparently simple task requires six handovers.

You do.

Or at least you can find out.

And that is where the real work starts.

The numbers can be right.

The read can still be dead wrong.

Before You Act on the Number, Trace the Signal

A benchmark has shown you a difference.

Before turning that difference into an intervention, follow one signal through the operation and see where the story changes.

Use the Signal Trace Lens →

The Lens is designed to help you separate what you observed from what you assumed, trace where the signal travelled, and identify what still needs to be established before deciding what comes next.

SEE WHERE THIS IS GOING->

READ THE SIGNAL →

Article by

Amos J. Amolo

Amos Jactone Amolo is the founder of 6th Sense Hospitality and an Operations System Designer with more than 30 years of experience across food & beverage, live events, catering and venue operations. He still actively owns and operates hospitality and event businesses, so his observations are not based on what the industry used to look like. They are being tested on the floor today.

His perspective was built — and continues to be tested — in live operating environments where decisions happen in real time. He watches what changes when an operation comes under pressure: where timing slips, information stops moving, responsibility becomes unclear and people begin compensating for a system that is no longer helping them.

Just as importantly, he watches the customer. Changing drinking habits, new expectations around food, shorter attention spans and the increasingly visual way guests make buying decisions are already changing how hospitality needs to operate.

That thinking forms the foundation of 6th Sense Hospitality: look beyond the obvious symptom and find where people, process, technology, money and decision-making have stopped working together.

His core philosophy is simple:

“If your team starts to guess, the money has already left the building.”

Through 6th Sense Hospitality, Amos develops practical diagnostics and operational systems that help operators see what is actually happening inside their businesses — before workarounds become accepted as normal.

Not theory. Still operating. Still observing. Still testing what actually works.