How to Decline a Request
Refusing badly loses the argument and the relationship. Naming the reason that lands, and answering the concern underneath.
The boundary · Procedure
Someone will ask for one of the things in the refusal note, usually with a real worry behind it. How the conversation goes decides both the outcome and whether you are asked next time.
What does not work
Expressing discomfort, which reads as squeamishness and invites someone else to be asked.
Citing policy without explaining it, which invites a request to change the policy.
A flat no with no alternative, which gets routed around.
Overstating the legal position, which is checked and discredits the accurate parts.
Name the reason that will land
For a commercial audience: deducting pay for a technical failure is an unlawful deduction in most jurisdictions, and the claim costs more than the minutes.
For an operational audience: the record stops describing arrivals. People punch from the car park and absorb unpaid minutes, and both degrade the data you bought.
For a people audience: turnover in shift roles is expensive, and a clock-in system that punishes people for its own failures is consistently cited when people leave.
All three are true. Lead with the one that will be heard.
Answer the concern underneath
"People are clocking in from home" — a real question, answered by the boundary that already exists, or by a terminal.
"Someone is covering for a friend" — supervision answers it; a geofence does not.
"The fallback is overused" — a measurement of the primary method failing, answered by fixing the site.
"We need to know who's on site for fire" — a real need the punch cannot meet reliably, answered by a dedicated roll call.
Offering the real answer turns a refusal into a consultation.
Where not to help improve
Making the fallback harder to reach. Hiding what permission the app requests. Enabling background collection quietly after an update.
None is a partial improvement. A better-concealed version of the thing is still the thing, and saying so explicitly is better than leaving it implied.
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 rather than argued again.
If overruled
Say so to the people affected, which is honest and preserves what trust remains.
Insist on the mitigations: notice, a working fallback, payment for failures, retention, and a route to dispute.
Record your position in writing, dated.
Prepare the position in advance
Written before it is requested.
The categories you will not build, with the reason for each.
Who decides on an exception.
Agreed with whoever owns risk, before anyone asks.
Deciding calmly is much easier than inventing it during a week when a manager is frustrated about one person's punches.
Connect policy to configuration
The practical choices behind this note can be compared with the legal-services use case. Keep the written purpose in control and enable only the data needed for it.