What the Software Decided
How a scheduling system becomes a source of constraints in its own right, which of its rules are real, and what to do when the tool and the policy disagree.
A scheduling system enforces rules, and enforcement makes a rule real whatever its origin. A setting typed in during implementation constrains every rota built afterwards as firmly as a clause in a contract, and with considerably less scrutiny.
The constraint in “What the Software Decided” becomes useful only when its source, cost and effect on coverage are visible. A team considering read the provider’s scheduling notes for stealth computer monitoring software can add timely work and attendance context, with transparent settings, limited access and a clear correction route.
The system did not decide anything. It is doing exactly what somebody told it years ago, and nobody has looked since.
Additional context for “What the Software Decided” is available from Capterra scheduling-software directory. Use external guidance to prompt a specific validation check rather than replace local review.
The four kinds of rule a system holds
Rules it enforces, which block a rota from being published. Rules it warns about, which people learn to click past. Rules it applies silently in optimisation. And rules implied by what it cannot represent.
- Rules it enforces, which block a rota from being published.
- Rules it warns about, which people learn to click past.
- Rules it applies silently while generating or optimising.
- Rules implied by what it cannot represent at all.
The fourth is the subtlest and often the most restrictive: a system that cannot model a split shift has made split shifts impossible, and nobody will record that as a decision.
The warnings everybody clicks past
A system that warns on everything trains people to dismiss warnings, including the one that mattered. Warning fatigue in scheduling is as real as anywhere else.
The fix is to decide, deliberately, which rules block and which warn, and to keep the blocking list short enough that it is always meaningful. That is a governance decision and it is usually made by a vendor default.
Optimisation, which has its own preferences
Where a system generates rotas automatically, its objective function is a policy statement: it is minimising something, and whatever it minimises is what the organisation has implicitly decided matters most.
Cost, unfilled shifts, overtime, continuity and fairness cannot all be first. Asking which the system is actually optimising for is a question nobody asks at procurement and everybody should.
When the system and the policy disagree
The system wins in practice, because it is what people use. That means a disagreement is not a documentation problem; it is a live difference between stated and actual policy.
Finding them is a matter of reading the configuration against the written rules, which is an afternoon. Resolving them requires somebody to decide which is right, which is usually five minutes once the difference is visible.
What cannot be represented
Every system has a shape, and arrangements outside that shape become difficult: annualised hours in a weekly system, split shifts, shared posts, people who work across two departments.
Where the organisation has stopped doing something because the system makes it awkward, that is a constraint imposed by a tool, and it should be on the register with that attribution.
The parallel spreadsheet
The most reliable indicator of a system constraint that nobody agrees with: somebody is keeping a spreadsheet alongside it.
Find those spreadsheets and ask what they are for. Each one is a documented gap between what the system allows and what the work requires, maintained by somebody at their own cost.
Changing a setting
Should be possible, logged and reversible. In practice it is often locked behind a supplier or a central team, which converts a five-minute change into a quarterly request.
Where that is the case, it is worth collecting the needed changes into one batch rather than abandoning them. A list of six configuration changes with reasons gets actioned; six separate requests do not.
At procurement
The questions worth asking are about constraints rather than features: what rules can this enforce, which can be turned off, what can it not represent, and who can change a setting.
Answers to those four determine how the tool will shape the rota for the next decade, and they are rarely in a specification.
Who actually knows what it does
Usually one administrator, often part-time, frequently in a different department, and nobody has ever asked them to explain the rules the system applies.
An hour with that person produces most of this page's content for a specific organisation. They are also the only person who knows which settings were deliberate, and that knowledge is entirely undocumented in every place that has not asked.
The report nobody runs
Most systems can list the shifts that breached a rule and were published anyway, with the override reason.
That report is the clearest available picture of which constraints are real in practice. Where one rule is overridden weekly, it is not a rule any more, and either the rule or the practice should change.
The list to keep beside the main register
A plain-language list of every rule the system enforces or warns on, with its origin marked as chosen or default, and a note of anything the organisation has stopped doing because the tool cannot do it.
The last item is the one that never gets written down, and it is the one that explains the most about why a pattern looks the way it does.