Two Clocks That Never Speak

Walk into almost any site with a time clock and count the systems that record a person's presence. There will be more than one.

The practical lesson in “Two Clocks That Never Speak” is that a timesheet only becomes reliable through a process people can operate consistently. For teams exploring workforce analytics software, more information can add time and project context, provided collection is proportionate, access is limited and every consequential inference receives human review.

Access control at the perimeter. A turnstile or a door controller. Possibly a car park barrier. A vehicle telematics unit. A machine or terminal login. And the time clock, which is the only one payroll looks at.

For a separate benchmark relevant to “Two Clocks That Never Speak”, consult the Grants.gov policy resources. Use it to test record quality, approvals, retention, employee rights and exception handling against the real workflow rather than treating a software report as self-explanatory evidence.

Each holds timestamps for the same person on the same morning. None of them is joined to any other, and the organisation therefore has a precise record of the boundary it cannot see.

Why they are separate

They were bought at different times for different reasons by different departments. Access control is a security purchase, justified on who may enter. The clock is a payroll purchase, justified on paying people correctly. Telematics is a fleet purchase.

Nobody specified that they should talk, because at the point of purchase no one department owned the question they would answer together. That question — when did the working day begin — sits between security, payroll, HR and operations, and belongs to none of them.

What the join produces

Subtract the earliest perimeter event from the punch, by person and by day, for a month. That single query produces the measurement this whole collection depends on, and it is usually the first time anybody in the organisation has seen it.

It also produces the distribution rather than an average, which is where the cause lives: one entrance, one shift, one day of the week, one group of people who change and one who do not.

And it produces the outliers, which are individually interesting: the person who is in the building forty minutes before the punch every day, who is either doing unpaid work or using the canteen, and the only way to know is to ask.

The objection, and the answer to it

Somebody will say that access data was collected for security and must not be used for pay. That objection is serious and it is not fatal.

It is serious because using data for a new purpose generally requires a fresh look at the basis for it, and in several jurisdictions it requires telling people. It is not fatal because the use proposed here is aggregate, diagnostic, and in the workers' favour: measuring an unpaid edge in order to decide what to do about it.

The clean route is to do the analysis in aggregate, without naming individuals, state the purpose in writing, tell people it is happening, and not use it for anything about a person. Where the finding leads to a change, that change is the output rather than any individual record.

What not to build

The instinct after the first join is to connect the systems permanently so that the perimeter event becomes the punch. Resist it, at least initially.

A perimeter event is not the start of work either — it is arrival at the site, which includes the walk, the coffee and the chat. Making it the pay trigger moves the problem rather than solving it, and it converts a security system into a pay system with all the obligations that implies.

The measurement is the point. What to do about it is a separate decision and usually involves the terminal, the shift pattern or the procedure rather than the integration.

When the systems disagree about the time

A practical trap. Access control and the time clock keep their own clocks, and unsynchronised devices drift by minutes over months.

Check the two against a reference before drawing any conclusion from the difference between them. A site that discovers a consistent eleven-minute gap may have found an unpaid edge or may have found a terminal whose clock was never set, and the two look identical in the export.

The single recommendation

Export both systems for one site and one month, join them on the identifier, and look at the distribution.

It is a day of somebody's time, it needs no procurement and no project, and in most organisations it is the only measurement in this subject that has never been taken.

The third system nobody mentions

Beyond access control and the clock there is usually a third record of presence: the operational system. A till login, a machine sign-on, a dispatch terminal, a clinical system, a vehicle key.

It is the most precise of the three for the question that matters, because it records the start of actual work rather than arrival or clocking. Where it exists, the triple — perimeter, punch, first operational action — brackets the morning completely, and the gap between the second and third is the part of the edge that happens after the punch and is therefore already paid. Knowing both halves separately is what makes the figure credible.