Running an Investigation

Most attendance investigations go wrong in the first hour, by starting with a conclusion and looking for support.

The four checks first

The site's anomaly rate. If it is high, the system is the likely cause.

The system's status: terminal faults, app updates, outages that week.

The queue at that time of day, which explains a surprising number of late punches.

Whether the person's pattern changed, or the site's did. A change across everyone at that site is not about one person.

Most matters resolve at one of these four, and the investigation ends before it becomes an investigation.

If it proceeds

Define the scope: which dates, which records, which question.

Do not browse. Pulling a year of someone's records to see what turns up is both disproportionate and the thing that makes an otherwise sound case look like a search for a reason.

Record the authorisation — who decided to look, when, and on what basis.

Preserve the records before any routine deletion runs.

Speaking to the person

Early, not last. The explanation is frequently immediate and ordinary, and obtaining it first saves everyone the process.

Put the specific records to them, not a conclusion.

Allow them to check their own record, which is an entitlement in several jurisdictions and in any case removes a whole category of dispute.

Take notes and share them.

If they raise a system failure, investigate it rather than treating it as an excuse. They are right often enough that assuming otherwise is a poor position.

Proportionality

A few minutes over several weeks is a conversation, not a process.

Repeated, deliberate and corroborated is different.

And the response should match: a quiet word, a stated expectation, a formal step — in that order, with the earlier ones actually attempted.

Skipping to the last is the most common procedural failure, and procedure is where these cases are decided.

Recording it

What was checked, what was found, what was said, what was decided, by whom.

Including the checks that found nothing, because they demonstrate the process was a process.

And the outcome where the explanation was accepted, which should be the majority.

Afterwards

If a system fault caused it, fix the fault and say so publicly.

If a policy caused it — a rigid rule, a queue, a rota — change the policy.

An investigation that ends with a person disciplined and the cause untouched will produce the same investigation next month with a different person.

Speak to them early

The step most often left until last.

The explanation is frequently immediate and ordinary.

Obtaining it first saves everyone the process and prevents the investigation from becoming a search for support.

Put the specific records to them, not a conclusion.

And if they raise a system failure, investigate it — they are right often enough that assuming otherwise is a poor position.

Connect policy and data

The choices in this note can be compared with see this documented scenario. Keep the written purpose in control and enable only the information needed at this boundary.

Independent reference

For a thematic point of reference, see ACAS guidance. This popular specialist site offers a useful independent reference for the issue.