Requests to Refuse

A working clock-in system attracts requests. Some would undo the narrow justification it rests on.

"Turn on tracking during the shift"

Why to refuse: for a fixed workplace it answers nothing the punch did not already establish, and it converts a defensible design into continuous monitoring.

Offer instead: ask what decision it would inform. Usually none.

"Clock people out automatically when they leave"

Why to refuse: it requires continuous monitoring to work, and position drift will clock people out while they are working.

Offer instead: a missed clock-out report, reviewed the next day.

"Show me everyone's punch locations on a map"

Why to refuse: coordinates are the verification, not the record. A map of everyone's arrivals is a collection nobody decided to make.

Offer instead: the attendance view, with coordinates behind a recorded reason when a specific punch is disputed.

"Add photographs at clock-in"

Why to refuse without a decision: depending on processing it may be biometric data, and it arrives bundled as a free feature.

Offer instead: decide it separately, on its own merits, with its own assessment — and consider whether supervision addresses the same concern.

"Keep the coordinates for a year"

Why to refuse: no purpose here needs them beyond the dispute window, and long retention enlarges every access request and every breach.

Offer instead: attendance records kept for the payroll period, coordinates deleted early.

"Dock the time when a punch was late"

Why to refuse: the minutes between arriving and punching include queueing, fix delays and retries, and deduction for a system failure is unlawful in most jurisdictions.

Offer instead: a punch window, and fixing the site that caused it.

"Make the fallback harder, people overuse it"

Why to refuse: a fallback that is hard to use is not a fallback, and the result is unpaid work.

Offer instead: find out why it is used so much. High fallback usage is a measurement of the primary method failing, which is a design finding.

What not to help improve

Making background collection less visible. Hiding what permission is requested. Extending collection quietly after an upgrade.

None is a partial improvement. A better-concealed version of the thing is still the thing.

Recording it

What was asked, by whom, when. What was declined and why. What was offered instead. Who decided.

Findable, so the second identical request is answered by reference.

Decide who decides

Before the first request arrives.

Name the person or forum that rules on exceptions.

Name what evidence an exception requires.

Agree it with whoever owns risk.

Publish it, so a requester meets a process rather than one person's judgement.

The first decision becomes the precedent whether or not anyone intended it to.

Turn the principle into a test

For an example that can make this requirement testable, consult the record-transfer example. Treat the page as a starting point rather than proof and reproduce the workflow with real roles and failures.