The Record Describes the Wrong Event

Open any absence system and the record is a person, a date range, and a reason code. That is the personnel event and it is a legitimate thing to record.

The record in “The Record Describes the Wrong Event” becomes more useful when the original time entry, later correction and reviewer decision remain distinguishable. If this implementation resource supports how to calculate idle time, administrators should test exports, amendments, permissions and retention before launch so a dashboard does not replace the underlying evidence.

It is not what happened. What happened is that a shift that needed six ran with five for ninety minutes, that a capability was uncovered during that window, that four people spent an hour on the phone, that a client visit moved, and that an agency worker was booked at a premium. None of that is anywhere.

For an independent benchmark relevant to “The Record Describes the Wrong Event”, consult the SAM.gov federal award resources. Use it to test scheduling, working-time limits, attendance records, employee rights and exception handling against the real operation rather than treating a software report as self-explanatory evidence.

Why the two diverged

The absence system was bought by HR to administer entitlement, pay and triggers. It does an adequate job of that and it was never asked to describe an operation.

The operational facts, where they exist at all, are scattered: agency spend in finance, the rota change in scheduling, the deferred work in a day book, the morning itself in nobody's system.

So the organisation holds a complete record of a thing that does not cost much and no record of the thing that does.

What the operational record should contain

Which shift, and what it required.

What it actually ran with, in people and in capabilities.

How long it was short for, which is often much less than the shift.

What was done: routes tried, who covered, at what cost.

What was deferred, dropped or reduced, and who was told.

Who decided, under what authority.

Seven fields. It fits on one line of a spreadsheet and it takes two minutes at the end of the shift.

Where to put it

Not in the absence system, which has no fields for any of it and should not be made to.

A simple log — a shared sheet, a form, a line in the shift record — owned by operations rather than HR. The two are joined later by date and team when anybody wants to look at both, which is rarely and is fine.

Resist the urge to build something. A spreadsheet with seven columns, filled in for three months, will answer more questions than a system procured for the purpose and populated by nobody.

What it makes answerable

How many shifts ran below requirement last quarter, and in what.

What cover actually cost, joined to what caused it.

Which routes work: how often the call-out list produced somebody, how often agency was the only option.

How long the morning takes, and whether the changes made are shortening it.

Which teams absorb the most, and which capabilities keep failing.

Every one of these is a question somebody senior will eventually ask, and none of them is answerable from an absence rate.

The objection

That it is more paperwork for people who are already stretched, which is true and is the reason most attempts at this fail.

The answer is to keep it to one line, to make it part of the shift record rather than a separate task, and to show it back. A log that disappears into a drawer will stop being filled in within a month. One whose quarterly summary visibly produced a second trained person, or a float post, or a working call-out list, keeps being filled in because the people writing it saw what it bought.

Keeping the two records apart

The operational log and the absence record should not be merged, and the instinct to merge them should be resisted.

They have different subjects, different readers, different retention and, for anything clinical, different legal handling. A log about shifts can be open to the people who run shifts. A record about individuals cannot. Joining them for analysis, by date and team, gives you everything a merged system would and none of the access problem.

What the absence record is still for

None of this is an argument against the absence record. It does its own job properly: entitlement, pay, statutory obligations, the trigger process, and the evidence required if an individual matter ever arises.

The mistake is only in asking it to describe the operation, which it was never built to do and which nobody designing it intended. Two records, each doing what it is for, joined when somebody needs both — that is the whole arrangement, and the reason it is unusual is that it requires two owners to agree rather than one system to be bought.