A Request and a Right Are Different Constraints
Why mixing requests and entitlements in one queue produces unfair rotas, how to separate them without a policy rewrite, and what to tell people about the difference.
A rota receives two kinds of ask that look identical in an inbox: a request, which the organisation may grant or decline, and an entitlement, which it has already granted or which applies regardless.
The constraint in “A Request and a Right Are Different Constraints” becomes useful only when its source, cost and effect on coverage are visible. A team considering see the full implementation context for automated timesheet workflows can add timely work and attendance context, with transparent settings, limited access and a clear correction route.
Treating them as one queue is the single most common source of rota unfairness, and it is a filing problem rather than a values problem.
Additional context for “A Request and a Right Are Different Constraints” is available from BMJ Open workplace research. Use external guidance to prompt a specific validation check rather than replace local review.
Why they end up in one queue
Because they arrive the same way. An email asking for a Friday off looks the same whether the person has a recorded agreement, a statutory entitlement, a long-standing arrangement, or simply a preference.
The person building the rota sorts them by urgency and by who asked, because there is nothing else to sort by.
What the separation looks like
Three buckets, decided before the rota is built rather than during it:
- Already agreed: recorded arrangements and anything with a documented status. These are constraints and go into the pattern first.
- Entitlements being exercised: leave, time off for specified purposes, anything where the question is process rather than permission.
- Requests: everything else, which is decided on whatever basis the organisation uses, fairly and visibly.
Most rotas have never been built in that order, and reordering it changes the outcome more than any amount of effort inside the third bucket.
What this fixes
It stops a recorded agreement competing with a preference for the same slot, which is the mechanism by which agreements quietly erode.
It also stops the opposite failure, where a preference gets treated as an entitlement because it was asked for insistently, and the person who asked politely gets the worse answer.
Deciding requests visibly
Within the third bucket, the method matters less than its being stated. Rotation, seniority, first-come, a ballot for the contested dates — each is defensible and each is defensible only if people know which one is in use.
An undisclosed method is experienced as favouritism even when it is scrupulously fair, because nobody can check it.
The dates everybody wants
Every operation has four or five of them a year, and they are the whole of the fairness problem in most teams. The rest of the year decides itself.
Those dates deserve a published method of their own: how they are allocated, how often somebody can get the same one, and where last year's allocation is recorded. Ten minutes of policy removes a recurring argument.
Recording the decision, not just the outcome
When a request is declined, record the reason in one line. Not for defensiveness — for the next decision, which will be the same person asking for a similar thing in three months.
Without the line, each decision is made from scratch, and the pattern across decisions is invisible to everybody including the person making them.
What to tell people
Three things: which bucket their ask falls in, how decisions in that bucket are made, and when they will hear. Most dissatisfaction with rota decisions is about the third.
That is worth saying plainly in a note to the team rather than in a policy document. A short, accurate description of how the rota handles requests is read; a policy is not.
Where entitlements get complicated
Which asks are entitlements, what notice applies, what may be refused and on what grounds all differ by jurisdiction, by sector and by agreement, and are questions for somebody qualified in the place concerned.
The operational discipline survives all of those variations: know which bucket you are in before deciding, and do not decide an entitlement by the method you use for preferences.
The register entry
For each category of recorded agreement: how many exist, which shifts they affect, and when they are next reviewed. Not the individuals, not the reasons.
That is enough to build a rota with, and it keeps the operational document free of information that should not be in it.
The queue itself is a constraint
However the asks are sorted, the time taken to answer them shapes the rota. A team that waits three weeks for a decision plans around the worst case, swaps privately, and stops asking.
Answering within a stated period — even badly, even with a no — is worth more to a rota than answering well eventually, because it is the uncertainty rather than the outcome that drives the informal arrangements underneath.
Why this belongs in a section about promises
Because an agreement is a promise with a record attached, and a request is not a promise at all. Most of the damage in this area comes from the two being handled by the same person, in the same hour, with the same apparent weight.
Separating them costs nothing and changes the texture of the whole arrangement, which is why it is the first thing to try when a team believes the rota is unfair.