Requests to Refuse

A capable scheduling system attracts requests it should not fulfil, usually from someone under cost pressure.

"Schedule tighter to the forecast"

Why to refuse: the forecast is not that precise at shift granularity, and the difference is paid for in cuts, call-ins and premiums.

Offer instead: measure forecast error and size the buffer from it, which is the same conversation with a number in it.

"Put everyone on fully flexible hours"

Why to refuse: it transfers all demand uncertainty onto the workforce and produces the turnover that costs more than the flexibility saves.

Offer instead: a fixed core plus a smaller flexible layer, sized from the annual minimum.

"Rank people by how often they accept short-notice shifts"

Why to refuse: it measures whose life has the least slack, not who is committed, and it is the kind of practice that becomes a discrimination claim.

Offer instead: a voluntary standby list, rotated.

"Use the scheduling data in performance reviews"

Why to refuse: swap requests, declines and availability reflect circumstances rather than performance, and using them teaches people to conceal constraints — which then produces missed shifts.

Offer instead: performance measures about the work.

"Give the awkward shifts to the new starters permanently"

Why to refuse: it is a stated rule at least, and it produces a permanent underclass and predictable early turnover.

Offer instead: rotation, or compensation, with the distribution published.

"Skip the rest gap this once, they agreed"

Why to refuse: where a rest rule applies, agreement usually does not waive it, and the liability sits with the employer.

Offer instead: find the cover, run short, or reduce service — all of which are decisions rather than breaches.

"Announce the fourteen-day rule but keep changing things"

Why to refuse: in covered jurisdictions the changes cost money, and everywhere the announcement becomes evidence that the policy is decorative.

Offer instead: move to the notice period you can actually hold, then extend it.

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 internally, so a requester meets a process rather than one person's judgement — and so the first decision does not silently become the precedent.

A practical implementation prompt

During configuration, use the record-transfer example to prompt questions about fields, ownership and output. Keep the written scheduling purpose in control and document every assumption.