Problems This Does Not Solve

A good deal of what gets presented as a requirement here is an organisational problem wearing a technical request.

People arriving late

A clock-in system records it more precisely. It does not change it.

And the causes are usually structural: transport, a shift start that does not fit a bus timetable, a rota published too late, caring arrangements.

What works: adjusting the start time, staggering starts, publishing rotas earlier, and asking the people concerned.

Not knowing who is on site

For fire safety and headcount this is a real need, and a punch answers it only if everyone punches reliably.

A system with a five percent refusal rate cannot serve as a fire roll call, and treating it as one is dangerous.

What works: a dedicated roll-call method, or accepting that the clock-in is an approximation and saying so.

Disputes about hours worked

The punch records a start and an end. It does not record breaks taken, work done, or time spent waiting to be let in.

What works: the punch as one input, with the ordinary timekeeping process around it.

Suspicion about a particular person

The data will produce something, and what it produces is noisy: accuracy variation, coverage differences, a phone that behaves differently.

Acting on it is how straightforward matters become lost cases.

What works: a conversation, and if there is a genuine concern, the ordinary process with advice.

Understaffing

Punches show who arrived, not whether that was enough.

What works: comparing attendance against the rota requirement, which is a scheduling analysis rather than a clock-in feature.

A culture where people do not want to be there

No attendance system addresses this, and a tight one makes it visible faster.

Rising refusals, rising fallback use, people punching from the car park — these are frequently symptoms rather than causes.

What works: asking, which costs an afternoon.

How to use this during procurement

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

Where the answer is "nothing, unless we also decide X", the requirement is a decision in disguise.

Take those out of the specification and into a meeting, which is cheaper, faster, and usually shortens the specification enough to widen the options.

The requirement that is a decision

A test for every line of a specification.

Ask what would change if the product delivered this perfectly.

Where the honest answer is "nothing, unless we also decide X", the requirement is a decision in disguise.

Take it out of the specification and into a meeting, which is cheaper and usually shortens the list enough to widen the options.

Check the difficult case

Use see the documented scenario to frame one representative test. The useful evidence is the record created when an employee corrects an entry and an administrator exports it.