OPSICLE ← Back to the site

Proving you gave notice: what your rota has to record

Written 30 August 2026 · about a 6 minute read

The shift notice rules are not in force and the notice period has not been set. None of that changes what you should be doing now, because the part that will decide cases is not the number. It is whether you can show what you told somebody, and when. That is a record, and records cannot be made retrospectively.

Not legal advice. The legal background is set out under reasonable notice of shifts, with links to the legislation.

Compliance here is an evidence problem

Read the mechanism in the Act and this becomes obvious. Under s.27BJ(4) notice is presumed unreasonable if given less than a specified period ahead, unless the contrary is shown. The phrase that matters is unless the contrary is shown.

The presumption runs against the employer. You will not be asked whether you gave reasonable notice; you will be asked to show it. An employer with good records rebuts the presumption. An employer with a WhatsApp group and a good memory does not.

What has to be captured

Six things. Audit yourself against this list — most operators fail on three or four.

WhatWhy it matters
When the rota was publishedThe actual timestamp, not the day you meant to do it. This is the clock the notice period runs from.
Who it was sent toA rota published to a noticeboard nobody photographed is not evidence that a specific person was told.
What changed after publicationThe right attaches to changes and cancellations too. A change is a fresh notice event.
When each change was made, and by whomAttribution matters when the account is disputed.
Both start times on a moveShort notice on a moved shift is measured from the earlier of old and new. One timestamp is not enough.
CurtailmentsSending someone home early is an event with consequences. Almost nobody records it.

Why a spreadsheet cannot do this

Not because spreadsheets are informal. Plenty of well-run businesses use them and the objection is not tidiness. It is that a spreadsheet records the current state and not the history.

When somebody edits a cell, the previous value is gone. So the question “what did the rota say on Tuesday the 14th, before it was changed?” is unanswerable from a file that has been edited two hundred times since. That is precisely the question this regime asks, and it is the one question a spreadsheet is structurally incapable of answering.

The same objection applies to plenty of rota software. A system that stores the current rota and overwrites it on each save has the identical problem behind a nicer interface. The test is not whether it is a spreadsheet. The test is whether last week’s answer survives this week’s edit.

A worked example

A shift is moved 36 hours before it was due to start. To defend that later you need: the original rota with its publication timestamp; the original start time; the new start time; the timestamp of the change; who made it; and evidence the worker was notified.

Six facts, of which most systems retain two. And 36 hours may or may not be short notice — that depends on regulations not yet made — which is exactly why you record the facts now and apply the threshold later.

Where the group chat fails

Shift changes get communicated in group chats because it is fast and everybody is already there. As evidence it is poor: messages are editable and deletable, membership changes, people leave and take the history with them, and “posted in the group” does not establish that a particular person was given notice.

None of that means stop using it. It means the chat is the convenience and the system of record is somewhere else — and the notification that carries evidential weight should come from the same place that holds the rota.

How long to keep it

There is no retention period attached to shift notice yet. But these records overlap heavily with ones that do have periods, and the longest governs how you store things in practice: holiday and pay records run six years, and working time records two.

If your rota history is being pruned at twelve months to keep a system fast, that is a decision worth revisiting before it becomes a decision somebody else examines.

What good looks like

  1. Publishing a rota is a recorded event with a timestamp, not a state change.
  2. Every subsequent edit is recorded against that published version rather than replacing it.
  3. Changes are attributed to a person.
  4. Notifications go from the same system that holds the rota, so “we told them” and “the rota changed” are one record.
  5. History survives migrations — including the migration to whatever you buy next.

OPSICLE is built this way, which is why we can write this page with any authority. But the principle is not proprietary, and the right question to put to any vendor is the plain one: show me what the rota said before that change, and who made it. If the demo cannot, the installation will not.

What to do this month

None of this needs a purchase decision. It needs an hour and some honesty.

  1. Pick a shift that was changed last month. Try to reconstruct what the rota said before the change, when it changed, and who changed it. Time yourself.
  2. Find out how long your current system keeps rota history, and whether anyone chose that number deliberately or it is just the default.
  3. Check whether a change made in the rota actually notifies the affected person, or whether somebody has to remember to message them separately.
  4. Count how many shift changes last month were communicated only in a chat group.
  5. Ask what happens to all of this if you change rota software next year.

The point of doing it now, while none of it is in force, is that the answers are cheap to act on today and expensive to act on in front of somebody official.

Sources