Buying a biometric reader and running a biometric system are different projects. The reader is a week of procurement; the system is enrolment for everybody, an exception path for the reads that fail, a decision about where templates live, and a deletion process somebody performs when people leave.
Enrolment is the project
Every person has to be enrolled, which means a scheduled session, a fallback for anyone the sensor cannot read, and a written notice handed to each of them. For a workforce of a hundred this is days rather than hours, and doing it badly produces months of failed reads that supervisors resolve by overriding, which quietly reinstates the problem you bought the system to remove.
The exception queue nobody budgets for
A small share of any workforce produces unreliable reads, and in trades where hands are wet, cold or worn that share is much larger. Each failure becomes a supervisor override, and an override that is not logged is indistinguishable from the buddy punching the system exists to prevent. Insist that overrides are recorded against a named person.
Where the templates live
Matching on the device keeps biometric data in your building and makes your retention duty entirely local. Cloud matching sends it to a vendor, which is a different conversation with staff and a different set of contractual terms. Neither is wrong and the choice should be deliberate, documented and stated in the notice you give people.
Questions people ask about biometric time clock systems
How many people fail to enrol?
A small percentage in office work and considerably more in trades. Ask the vendor for a failure to enrol rate and measure your own during a pilot.
Should matching happen on the device?
It is usually the safer arrangement for data protection and it limits what a vendor holds. Confirm in writing which one you are buying.
What if a reader breaks?
A single terminal on a single door is a single point of failure. Agree the answer, including how punches are recorded that morning, before it happens.