Here is how most rotas get built. Open last week's. Copy it. Adjust for who is off, and for anything you happen to remember about next week. Publish.

It works, in the sense that the shifts get filled. What it cannot do is tell you whether the number of people on any given day is right, because it contains no information about the week you are actually staffing for. It is a forecast of the past.

The fix is not a forecasting system. It is knowing what your demand unit is, and deriving the rota from that instead.

The demand unit is rarely headcount

Every operation has one thing that genuinely drives how much work there is. It is usually not the number of people you had on last Tuesday, and it is usually not revenue either - revenue is the result of doing the work, so staffing against it means you find out you were wrong afterwards.

Hotels - occupied rooms, split by departures and stayovers. This is the one where the wrong unit costs the most, because "14 rooms per attendant" is a number that ignores the only distinction that matters. A departure clean is a strip, a deep clean and a full reset. A stayover is a fraction of that. Two days with identical occupancy can differ by hours of housekeeping labour depending on the departure mix, and the rota that treats them the same is over on one and short on the other. Reception has a different unit again: arrivals per hour, not rooms sold.

Health and social care - dependency, not bed count. Required cover is driven by the acuity of the people you are caring for and by the roles that must be present regardless. A home at full occupancy with three high-dependency residents and one at the same occupancy with none are not the same rota, and staffing both against beds means one is unsafe and one is expensive.

Logistics and warehousing - units picked or lines shipped, by hour. Not orders, because orders vary enormously in size, and not people, because the whole question is how many you need. The useful figure is throughput per labour hour by task - goods-in, pick, pack, dispatch - because each moves on a different curve during the day and they are usually staffed as though they move together.

Retail - footfall, with conversion as the check. Transactions tell you what you sold; footfall tells you who came in. Staffing against transactions guarantees you never see the customers you lost, which is the entire cost of understaffing.

Bars and restaurants - covers per fifteen minutes. Per service is too coarse. Two hundred covers spread evenly over four hours and two hundred arriving in ninety minutes need different rotas, and only one of them is a bad night.

Contract cleaning - specification and frequency per site, plus travel. The work is defined by the contract, so it is unusually knowable in advance. The variable is travel between sites, cover, and access - which means the thing worth forecasting is not the cleaning but the movement between it.

Two failure modes this exposes

Averaging across a unit that is not uniform. The hotel one above is the clearest, but the same shape appears everywhere: a warehouse that staffs against total units without separating a pallet of one SKU from a hundred singles, or a care rota built on headcount when the dependency has changed since the last review.

Staffing against a lagging unit. Revenue, transactions, completed jobs. All of them tell you how much work you managed to do, which on a day you were short is a smaller number than the demand that arrived - so the data quietly confirms that your understaffing was correct.

How to start, without buying anything

You do not need a forecasting product to do this. You need four weeks of two numbers.

  1. Pick your unit. One of the above, or the equivalent for your operation. If you are not sure, pick the thing you would ask about first if you walked in and someone said today was hard.
  2. Get it by hour and by day of week, for four weeks. Most of it is already in the till, the PMS, the WMS or the care system.
  3. Put labour hours worked next to it, in the same buckets.
  4. Calculate units per labour hour for each bucket, and look at where it is far above and far below the average.

That ratio is the whole exercise. Where it spikes, you were short. Where it collapses, you were paying for hours the day did not need. Neither is visible in the daily total, which is why a rota copied forward can be wrong every single day and still look reasonable every single week.

Then use it to size the shift, not just count it

The output is not "we need one more person on Thursday". It is a shape: how much cover the day needs, hour by hour. Shift patterns then get built to fit that shape - which is usually the point at which someone discovers their standard eight-hour blocks cannot express it, and that a couple of shorter shifts placed over the peak do the job for fewer paid hours.

That is the same conclusion the retail understaffing research reached from the other direction. The forecast and the shift pattern are one problem, not two. Getting the forecast right and then pouring it into shift shapes that cannot hold it just relocates the error.