Skip to content

The Shift

Your scheduling screen shows wages. The week costs more than that.

Every scheduling tool projects a labour cost while you build the week, and the figure it shows is wages — hours times rate. The employer side arrives afterwards, and it is usually several points of sales. That gap is why a manager can be inside target on screen and over it in the accounts.

· 6 min

Build next week’s schedule in any product in this category and it will show you a number as you go. That number is almost always wages: the hours you have drawn, multiplied by the rates on the roster.

It is a useful number. It is not what the week costs.

What the schedule screen leaves out

Three things arrive after the shift is worked, and none of them are visible while the decision is being made:

  • Employer payroll burden — payroll taxes, workers’ comp, benefits. Commonly ten to twenty percent on top of wages, depending on your state and your insurer
  • Employer tax on declared tips — small per person, and on a tipped floor it adds up to a real fraction of sales on its own
  • Fixed and salaried labour — which does not move at all when you trim a shift

Put those together and the gap between the wages figure and the true labour cost is typically four to six points of sales. On a room doing $80,000 a month, five points is $4,000 a month that the screen never mentioned — $48,000 a year.

Scheduled at 22%, believing target is 25% → feels like 3 points of room
Actual cost nearer 27% against that target → is 2 points OVER

The manager was not careless. The screen was wrong.

The half of labour a schedule cannot reach

There is a second thing the wages figure hides, and it reframes what schedule-level control can achieve at all.

In a lot of full-service rooms, salaried labour is a bigger share of sales than hourly. Every instinct about labour control points at the hourly line — cut a server, send somebody home at nine — and that line is the smaller half. You can send the whole floor home early and not touch the salaried portion.

This is not an argument against managing hourly labour. It is an argument that a venue trying to move total labour by two points cannot get there from the schedule alone, and that a manager who is only ever shown the hourly number is being asked to solve less than half the problem with all of the pressure.

Why it is a design problem rather than a knowledge problem

Operators know burden exists. The issue is where the knowledge lives: in a month-end P&L, five weeks after the decision, while the decision itself happens on a Tuesday afternoon in a scheduling screen.

Same shape as prime cost. The arithmetic is not hard and nobody disputes it — the problem is the tense.

:::key What a scheduling tool should do Put the burdened figure on the screen where the schedule is built, not on a report that arrives after the month closes. A projection that excludes the employer side is not a forecast of cost; it is a forecast of wages wearing a cost label. :::

Run it on your own last month

You do not need software to check this.

  1. Total wages, plus salaried allocation
  2. Add the employer side — payroll taxes, workers’ comp, benefits
  3. Add employer tax on declared tips
  4. Divide by net sales

Then compare that to the number your scheduling tool showed you while you were building those weeks. The difference is your gap. It will not be zero, and it will be larger than you expect.

If your tool has no burden rate configured, whatever it is showing you is wages — and the label on it is wrong.

The companion piece on how to measure labour so the figure means something covers the other half: pooling rather than averaging, and why two restaurants quoting the same percentage are usually measuring different things.