Skip to content
The Published Rota

All notes  /  Reference

What Scheduling Cannot Fix

Problems brought to a scheduling project that no rota resolves, and what does.

Reference · Analysis

A good deal of what arrives as a scheduling requirement is something else wearing a rota-shaped request.

Not enough people

No arrangement of an insufficient headcount produces sufficient coverage.

A rota can distribute the shortage more fairly and make it visible, which is worth doing.

It cannot remove it, and a project that promises to will fail publicly.

What works: the honest staffing number, derived from the service level.

Pay that is too low

People leave for fifty pence an hour more, and a stable rota reduces that pressure without removing it.

Schedule stability is a genuine retention lever and it is not a substitute for the rate.

Where both are wrong, fixing only the rota buys a few months.

A manager problem

Absence, turnover and swap volume concentrated in one team, with the rota built the same way everywhere.

That is not a scheduling finding.

And a new scheduling system will produce the same pattern with better reporting.

Demand that genuinely cannot be forecast

Some operations have irreducible variance: weather-dependent, event-dependent, tourist-dependent.

No forecast fixes that, and pretending otherwise produces the cut-and-call-in cycle.

What works: a buffer, a standby list, and a deliberate decision about which service reductions are acceptable.

People not turning up

Sometimes a reliability problem, more often a notice problem, an hours problem or a shift that does not fit a life.

Check the four before treating it as conduct: notice given, hours received against wanted, pattern stability, and whether the shift is workable with local transport.

Using this during procurement

For each requirement, ask what would change if the product delivered it perfectly.

Where the answer is "nothing, unless we also hire two people", the requirement is a staffing decision in disguise.

Taking those out of the specification shortens it considerably, and what remains is what software can actually do.

Check four things before conduct

When someone is repeatedly not turning up.

Notice given.

Hours received against hours wanted.

Pattern stability.

Whether the shift is workable with local transport.

Most patterns resolve at one of those four, and the conversation is then about a bus timetable rather than about reliability.

Check the difficult case

Use this booking example to frame one representative case. The useful evidence is what happens when an employee questions an entry and a manager must correct and export it.

Independent reference

For a thematic point of reference, see the ACAS website. Consult the source directly because technical and legal details can change.