How These Deployments Fail
The recurring failures, each visible in the first month, each with a specific correction.
Putting it in · Analysis
Geofenced attendance fails in recognisable ways, and the diagnosis matters more than the product choice.
Radius set from a default
The symptom: a refusal rate that varies wildly between sites.
The cause: one number applied everywhere, chosen by the vendor.
The correction: measure each site and set per-site radii.
No fallback
The symptom: people standing at the door, and a grievance about unpaid time.
The correction: accept with a flag, plus a non-phone route for anyone without a working device.
Refusals not logged
The symptom: a dispute you cannot answer, because only successful punches were stored.
The correction: log failures with their accuracy figures, which costs nothing at procurement.
Punch time treated as arrival time
The symptom: lateness conversations about minutes that were queueing and fix delays.
The correction: a punch window, and checking the site's refusal rate before any conversation.
Background location enabled
The symptom: a workforce reaction out of proportion to a clock-in rollout.
The correction: request only while-in-use, verify what arrives when the app is closed, and say so in the notice.
Coordinates kept indefinitely
The symptom: a subject access request that produces a map of someone's year.
The correction: delete coordinates on a short schedule while keeping the attendance record.
Shift change not tested
The symptom: a queue, and people punching from the car park.
The correction: a terminal or a beacon at high-volume doors, and a punch window.
Personal phones assumed
The symptom: someone without a suitable phone is marked absent.
The correction: an alternative route, stated when the system is introduced.
Corrections piling up
The symptom: pay errors at period close.
The correction: a named approver with a deadline, and fixing the refusal rate that generated the volume.
The common thread
Every one of these is the employer's system failing and the worker carrying the cost.
Reversing that — the system fails, the worker is paid, the site gets fixed — is the whole design principle, and each correction above is an application of it.
The recovery move
For a deployment already generating complaints.
Publish the refusal rate by site.
Fix the worst one and say you did.
Turn on accept-with-flag if it is not on.
Approve outstanding corrections without scrutiny and pay them.
One fortnight of that, and a resented system becomes one people use as intended.
A concrete product reference
When translating this principle into a buying test, the design-team scenario provides a concrete workflow reference. Verify current behaviour in a trial and judge it against the purpose and limits above.