Requests to Refuse

Once the system exists, it becomes the most convenient source of information about where staff are. That is not what it is for.

When requests to refuse also depends on reliable work records, read more can support time, attendance and workload review without being treated as the emergency response itself. Compare any workflow with Suzy Lamplugh Trust resources and keep alarm ownership, escalation and dispatch responsibilities explicit.

"Show me where everyone is right now"

Why to refuse: the justification was locating someone who needs help. A live view of everyone serves supervision, which is a different purpose with a different basis.

Offer instead: the schedule, which answers the operational question.

"Use the check-in times to see who's running late"

Why to refuse: it converts a safety mechanism into a timekeeping one, and workers will start checking in on time rather than accurately — which destroys the signal.

Offer instead: whatever system records working time.

"Turn on continuous tracking, it's the same device"

Why to refuse: it collects a complete record of the day for a purpose the schedule plus an alarm position already serves, and it is the change that makes people leave the device behind.

Offer instead: position on alarm, and a review of why the schedule is insufficient.

"Enable always-on audio so we can hear what's happening"

Why to refuse: it records third parties in their own homes, continuously, without their knowledge. Activation-only is defensible; ambient is not.

Offer instead: activation-only with a stated retention.

"Pull her location history for last month"

Why to refuse: browsing a person's movements without a defined incident is disproportionate, and it is the use that ends the workforce's trust in the system permanently.

Offer instead: a scoped, recorded review of a specific incident window.

"Give the client the worker's live position"

Why to refuse: it is a transfer of an employee's personal data to a third party for their convenience, and it exposes the worker to whoever at the client can see it.

Offer instead: an arrival notification, which is what they actually want.

"Skip the two-worker visit this once, we're short"

Why to refuse: the two-worker requirement came from an assessment of that address. Being short-staffed does not change the hazard.

Offer instead: reschedule, or send nobody.

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.

Why these requests arrive

Not from bad intent.

A manager wanting to know where somebody is has an operational problem and sees a system that knows.

A client asking for live position is anxious about a visit.

A scheduler dropping a two-worker requirement is short-staffed and trying to deliver a service.

Treating any of them as a bad actor produces a defensive conversation and a workaround, which is worse than the request.

Answering the need instead

"Where is she?" is usually "will she arrive?" — which the schedule answers, and an arrival notification answers better.

"Is he running late?" is a workload question, answered by whatever records working time.

"I want to hear what is happening" is anxiety about a specific situation, answered by a call to the worker or a check-in rather than by ambient audio.

"We're short today" is a staffing problem, answered by rescheduling rather than by sending one person to a two-person visit.

Offering the real answer converts a refusal into a solution, which is also how the second request gets framed better.

The purpose limitation, written down

One paragraph: what the system is for, and what it will not be used for.

Agreed at deployment, published to the workforce, and referenced when a request arrives.

Which means a refusal is a reference to an agreement rather than one person's judgement, and that difference determines whether it holds.

Where the answer is genuinely yes

A serious safeguarding concern, a missing person, a credible threat to somebody.

These exist, and a blanket refusal is as wrong as a blanket yes.

Define them narrowly, require them to be authorised by a named role, and record every instance — what was asked, what was provided, and why.

A log of three such instances over five years is evidence of a controlled system.

No log at all is evidence of nothing, whichever way it went.

If overruled

Say so to the workforce, which preserves what credibility remains.

Insist on the mitigations: a stated purpose, a time limit, access logging, and a review date.

Record your position in writing, dated.

Keeping the record

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

Findable, so the second identical request is answered by reference rather than re-argued.

And reviewed annually, because a pattern of the same request from the same direction is telling you about a genuine operational need that has not been met.

That review is where a refusal turns into a fix, which is the outcome worth aiming at.