The Constraints Your System Does Not Know

TL;DR

• The core decision: which of the constraints that shape your rota are actually in the system.
• When doing nothing is right: when generated rotas need almost no correction.
• What has to be true: somebody can name why each manual fix keeps happening.
• How the options split: by whether a constraint is recorded, recordable, or neither.
• Decision rule: read your manual corrections as a list of what the system was never told.
• Outcome to expect: fewer repeated fixes, and honesty about what can't be recorded.

The Rota Is Technically Valid and Obviously Wrong

The system produces a draft. Nobody is double-booked, everyone has the hours they should, every slot is covered. It's a correct rota, and somebody who has worked there a year looks at it for four seconds and says no.

They can't always explain why immediately. Then it comes: those two shouldn't be on together on a Friday. She can't do the early because of the school run, it's never been written down. He's the only one who can actually open up. That's a shift nobody has covered since the thing that happened last spring.

None of that was available to the system, and none of it is unreasonable. Every rota is the output of a set of constraints, and the constraints that decide whether a rota is any good are mostly not in the software. They're in the head of whoever has been there longest.

Recommended Tools

Best tools for Employee Scheduling

B BambooHR HR management system L Lattice Performance management D Deel Global payroll & EOR

View all recommended tools

The reframe that makes this tractable: stop thinking about constraints as a single category the system either has or hasn't got. Sort them by whether they're recorded, recordable but unrecorded, or genuinely not recordable at all. Those three need completely different responses, and lumping them together is why this problem never seems to get better.

The first group is a data quality question. The second is a decision nobody has made. The third is the honest limit of what any system can do, and recognising it stops you buying tools to solve something no tool addresses.

One boundary before we start. Where a constraint relates to somebody's health, caring responsibilities, beliefs or any protected characteristic, what you may ask, what you should record, and what you're obliged to accommodate differ by jurisdiction and by circumstance. Nothing here tells you what applies to you or advises you to record anything of that kind. Establish it with local advice. Everything below is about the mechanism of what a system can and can't hold.

When You Genuinely Do Not Need to Act Yet

Generated rotas need almost no correction. The draft comes out and goes out. That means your constraints are genuinely in the system, which is rarer than it sounds and worth recognising.

The same fixes happen every week. A correction you make repeatedly is a constraint the system doesn't know, and it's the cheapest kind to address because you've already identified it.

Nobody but one person can produce a usable rota. The knowledge that makes a rota work lives in an individual, which is a continuity problem as much as a scheduling one.

The edge case that forces it. That person left, or was away, and the rota that went out was technically valid and wrong in ways nobody could anticipate. That's the moment the unrecorded constraints become visible, usually to everybody at once.

Five Questions This Reader Asks at 11pm

Why does every generated rota need fixing? Because it's built from what's recorded, and what's recorded is a fraction of what matters. The system optimises against the constraints it holds and produces something valid in those terms, while the constraints that would have made it good were never supplied.

What's the difference between availability and preference? Availability is when somebody can work. Preference is when they'd rather. Systems usually hold the first and not the second, and people fill in availability as though it were preference, which means your availability data is quietly a mixture of both and nobody can tell which is which.

Should we record informal arrangements? Usually yes for the operational ones, and carefully. An arrangement a previous manager agreed is a real constraint that currently survives only in somebody's memory, which means it will be broken the week that person is away. Recording the arrangement is different from recording the reason for it, and the second raises questions worth taking advice on.

What about things people haven't told us? Some constraints exist and nobody has mentioned them, because people don't volunteer difficulties or because they've quietly worked around it. You'll find these when a rota breaks, and the useful response is to make it easy to say something rather than to go looking.

Can we just get better data? Partly, and it's worth doing. The limit is that some constraints genuinely can't be held in a system, either because nobody will write them down or because they're judgements rather than facts. Knowing which category you're in stops you buying a solution to an unsolvable part.

Recorded, Recordable and Neither

The third row is the one that distorts everything above it. Because systems hold availability and not preference, people enter preferences as availability, marking themselves unavailable when they mean they'd rather not. Your availability data is therefore an unknown mixture, and nobody can separate the two, which makes it less useful than it looks and explains a lot of apparently unreasonable constraints.

The sixth row is the one everybody has and nobody records. Two people who shouldn't be on together is a real operational constraint, it's usually obvious to whoever runs the rota, and writing it down feels like creating a document you wouldn't want anybody to read. So it stays in one person's head, and the rota breaks when they're away.

The last row is the honest limit. Somebody dealing with something they haven't mentioned is not a data problem, and no amount of system configuration reaches it. What helps is that saying something is easy and low-stakes, which is a management question rather than a scheduling one.

Five Diagnostic Questions You Can Self-Assess Against

What did you change by hand last week, and why? Write down each correction and the reason. That list is the single most useful artefact in this whole area and almost nobody has one.

Which of those fixes repeat? A correction made every week is a constraint that exists, is stable, and isn't recorded. Those are the cheapest wins available.

When was availability last reviewed? Availability entered at induction describes a life somebody may no longer have. Nothing prompts an update, so it drifts while continuing to look current.

Could somebody else build your rota? If the honest answer is no, the constraints that matter are in a person rather than a system, and that's a continuity risk regardless of what tooling you have.

What happened the last time that person was away? Trace it. The rota produced in their absence is a live demonstration of exactly which constraints were never recorded.

Run these five with whoever actually makes the corrections. They hold the entire list in their head already, and the only thing missing is somebody asking them to say it out loud, one fix at a time.

Six Kinds of Constraint, Reviewed

Availability somebody has formally declared

The person has stated when they can and can't work. It earns its place as the foundation: without it there's no rota at all, and collecting it systematically beats asking by message every week.

Where it falls short is currency and honesty. It's entered once and rarely revisited, so it describes somebody's circumstances at a moment that may be years past. And because there's nowhere to express preference, it collects preferences too, which means it overstates genuine constraint.

Keep it and review it. Asking people to confirm their availability periodically is a small piece of work that keeps the foundation sound.

The review is also the natural moment to catch the preference problem. Somebody confirming their availability will frequently volunteer that one of the blocks is a would-rather-not rather than a cannot, which is information you had no other route to.

Be careful what the confirmation asks for. A form that only offers can and cannot will collect the same mixture as before, and the opportunity is wasted for another year.

A skill or certification the work requires

Somebody is qualified to do a particular thing, and the shift needs it. It earns its place because it's a hard constraint with a clear consequence: a slot covered by nobody qualified is a real operational failure rather than a preference.

Where it falls short is maintenance. Certifications expire, people acquire new ones, and the record only reflects reality if somebody owns updating it. An expired qualification the system still believes in is worse than no record at all.

Record it and name who maintains it. Also worth checking what the system does as an expiry approaches, because a silent lapse is the failure mode here.

The ownership question is the one that determines whether any of this works. Certification records maintained by nobody in particular drift within months, because the people acquiring qualifications have no reason to think about the rota and the person building the rota has no way to know.

It's also worth knowing which of your slots genuinely require a qualification and which have simply always been covered by somebody who has one. The two get conflated, and the second is an unnecessary constraint narrowing your options every week.

A preference somebody has expressed but never formalised

They'd rather not do Mondays, they like the late shift, they prefer to be on with a particular team. It earns its place because accommodating preferences costs very little when the rota has slack and it's the cheapest goodwill available in this whole area.

Where it falls short is that most systems have nowhere to put it, so it either lives in somebody's memory or gets entered as unavailability, which is worse. It also raises the question of whose preferences get accommodated when they conflict.

Worth capturing separately from availability if the system allows it. Where it doesn't, a simple list held alongside is better than the current arrangement of remembering some of it.

The conflict question needs an answer before you start collecting. Preferences will clash, somebody has to decide whose is accommodated this week, and if there's no stated approach it becomes whoever asked most recently or most persistently.

Be honest with people about what a preference buys them. Recorded preferences that are visibly ignored are worse than no collection at all, because people conclude that being asked was a formality.

An informal arrangement a previous manager agreed

Somebody has an accommodation that was agreed verbally, possibly years ago, and everybody who knows about it has been there a while. It earns its place because it's a genuine commitment and breaking it damages a relationship that took time to build.

Where it falls short is fragility and opacity. It survives in memory, it breaks whenever the memory is absent, and nobody new can distinguish it from a preference. New joiners also see an arrangement they can't account for, which reads as favouritism.

Record that the arrangement exists. Whether and how to record why is a different question, and where the reason concerns health or caring responsibilities it needs local advice rather than a default.

The favouritism problem is the practical reason to hold something rather than nothing. A newer colleague who can see that somebody never works Sundays, and can see no reason for it, will reasonably conclude that arrangements are available to people who ask. A note saying an agreed arrangement exists, without the reason, addresses most of that.

Worth reviewing them occasionally too. Arrangements agreed for a situation years ago sometimes outlive the situation, and neither side raises it because neither side wants to.

A pairing or separation between people

Two people who work well together, or two who shouldn't be scheduled together. It earns its place because the operational effect is real and obvious to anybody who has watched a shift go badly.

Where it falls short is that the separation half is almost never written down, for understandable reasons. Recording that two colleagues shouldn't work together creates a document nobody wants to exist, so it stays with one person and the constraint is invisible.

The pairing half is easy to record and worth doing. The separation half needs judgement about what it's reasonable to hold and how, and where a separation stems from a complaint or conduct matter it belongs with whatever process owns that, not in a scheduling note.

That distinction matters more than it might seem. A note in a scheduling tool saying two people shouldn't work together, with no context and no process behind it, is a record that could be read by people who have no idea what it refers to, and it sits outside whatever handling the underlying matter deserved.

Where the separation is an ordinary working-style question rather than anything serious, it's usually fine to hold and helps everybody. The two cases need telling apart before anything is written down.

A constraint the person has not told you about at all

Something in somebody's circumstances that affects what they can do and that they haven't raised. It earns its place on this list because it's real and common, not because there's anything to configure.

Where it falls short is that no system reaches it. People don't volunteer difficulties, especially where they suspect it will cost them hours, and the constraint usually surfaces as a refusal, a pattern of declining certain shifts, or a departure.

Nothing to record. What helps is that raising something is easy, routine and doesn't visibly cost the person anything, which is about how the team is run rather than about the rota.

The pattern to watch for is declining rather than explaining. Somebody who consistently turns down a particular kind of shift, without ever saying why, is telling you something, and a conversation started from curiosity rather than from a concern about their availability will usually get further.

It also matters whether saying something has visibly cost anybody else hours. People watch what happened to the last person who raised a constraint, and they calibrate accordingly.

The Decision Table

The second row is the best return available in this entire area and it's free. A correction you make every single week is a stable, known constraint that nobody has written down, and moving it into the system removes that work permanently. Most operations have several.

The fifth row is the one that's a bigger problem than it appears. A rota that only one person can produce isn't a scheduling arrangement, it's a dependency, and the week that person is unavailable is when everybody finds out how much was never recorded.

The fourth row is the one quietly shrinking your options. Every preference recorded as unavailability removes somebody from a slot they would actually have taken, and the effect accumulates across a team until covering a Saturday looks harder than it is.

The Rota That Gets Fixed by Hand

Every manual correction is information. It's the system telling you about a constraint it doesn't hold. Treated as an annoyance, it repeats forever. Treated as a finding, it converts into a permanent fix.

Repeats are the priority. A correction made once may be a one-off. One made weekly is stable, known, and recordable, and there's no reason for it to keep costing somebody time.

Count them during any trial. The number of hand corrections on a generated rota is the most honest measure of whether a system fits your operation, and it's more informative than any feature comparison.

And compare it against your current arrangement. A generated rota needing six fixes is only a problem if your spreadsheet needed none, which it probably didn't.

Some corrections reveal missing data, others reveal missing capability. A fix you could avoid by recording something is a data gap. A fix you couldn't record even if you wanted to is a product limit. Sorting them tells you which conversation to have.

The person making the fixes knows why. They may not have articulated it, and they can tell you if asked directly, correction by correction. That conversation takes an hour and produces most of the list.

Some of it genuinely can't be fixed. Judgement about who can cope with a difficult shift, a separation that nobody will formalise, something somebody hasn't disclosed. Accepting that a portion of rota-building is irreducibly human stops you looking for a tool that removes it.

Which is an argument for the reviewer, not against the system. A generated draft checked by somebody who knows the team is a good arrangement. A generated draft published unchecked is where the missing constraints reach people.

The useful consequence is that this stops being a vague complaint about software and becomes a list. Once you have the list, each item is either recordable, not recordable, or a product gap, and all three of those are actionable in a way that a general sense of the rota being wrong is not.

It also changes who can have the conversation. A general complaint can only be raised by the person who feels it; a list of specific missing constraints can be worked through by anybody, including whoever covers during an absence.

Where These Arrangements Go Wrong

The third row quietly costs you coverage. When the only way to say I'd rather not is to mark yourself unavailable, people do, and your pool of available staff is smaller than your actual pool. Giving preference somewhere to live frequently reveals availability nobody knew about.

The last row is the expensive misdiagnosis. Teams replace scheduling systems because the generated rotas are poor, when the constraints that would have made them good were never entered, and the new system produces equally poor rotas for exactly the same reason.

The fifth row is the one that does relational damage rather than operational damage. An arrangement quietly honoured for years and broken during one absence tells the person concerned that it was never really an agreement, which is a hard impression to reverse.

What to Put in Writing

The first row is the whole exercise in one line. A log of corrections and reasons, kept for a few weeks, converts an unbounded complaint into a finite list, and most of that list turns out to be cheaply fixable.

The sixth row belongs before any of the others that involve collecting personal information. What you may ask and hold differs by jurisdiction and by what the information is, and it's considerably easier to establish that before designing a form than after people have filled one in.

Questions to Ask Before You Commit

On preference. Can we record preference separately from availability? A bad answer is that they can mark themselves unavailable.

On arrangements. Can we hold a standing exception for one person? A bad answer is with a note.

On skills. What happens when a certification expires? A bad answer is that it shows in a report.

On pairing. Can we express that two people should or shouldn't be scheduled together? A bad answer is manually.

On freshness. Can we prompt people to confirm availability? A bad answer is that they can update it any time.

On corrections. Can we see what was changed after generation? A bad answer is in the audit log.

What Getting This Wrong Costs

The first cost is a fix that repeats forever. Somebody makes the same correction every week because the system doesn't know something stable and knowable, and the time spent is never counted because each individual instance is small. Over a year it's substantial, and the whole of it was avoidable by writing one thing down.

The repetition also wears on whoever does it. Making the same correction indefinitely, knowing it will be needed again next week, is the kind of work that makes a job feel pointless in a way the time cost alone does not capture.

The second cost is coverage you don't know you have. When preference has nowhere to live, it gets entered as unavailability, and your pool of people available on a Saturday is smaller than the pool of people who could actually work a Saturday. You then struggle to cover shifts that people would have taken if asked in the right way, and you conclude that availability is tight.

The conclusion then shapes decisions well beyond the rota. Operations that believe availability is tight recruit differently, plan differently and accept worse patterns, all on the basis of a constraint that was partly an artefact of where preferences had to be entered.

The third cost arrives during an absence. The constraints that make a rota work are frequently held by one person, and the week they're away the rota that goes out is technically valid and wrong in several ways nobody could have predicted. People notice, the arrangements that were quietly being honoured get broken, and some of the goodwill that took years to build goes with them.

It also lands badly on whoever covered. Somebody stepping in to build a rota with none of the context is set up to fail, gets the complaints, and usually concludes that rota building is thankless rather than that the information was missing.

So do three things, and the first is most of the value. Keep a log of every correction you make to a generated rota and why, for a few weeks. Sort the list into what could be recorded and what genuinely can't. And ask directly whether preference can live somewhere other than availability, because that single change frequently uncovers coverage you already had.

None of the three requires a purchase or a project, and the log costs seconds per correction. The only real requirement is doing it at the moment of the fix rather than trying to remember at the end of the week.

When You Are Ready to Go Further

Start with the correction log, because it's free, it takes seconds per fix, and it turns a vague problem into a list. A few weeks of it will show you which corrections repeat, and the repeating ones are stable constraints that somebody is paying for weekly and that could be recorded once.

Then separate the list into three piles: things that could be recorded and aren't, things the product can't hold, and things that genuinely can't be written down. The first pile is work you can do immediately, the second is a real conversation with a vendor with evidence behind it, and the third is the honest limit that stops you looking for a tool that doesn't exist.

The second pile is also worth taking to a vendor as a list rather than as a complaint. A specific request to hold a standing exception, or a pairing, gets a much better answer than a general observation that the generated rotas need work.

Finally, get the arrangements out of one person's head, at least to the extent of recording that they exist. You don't necessarily need to record why, and where the reason touches health or caring responsibilities that's a question for local advice rather than a default. But an operation where the accommodations only survive in somebody's memory is one absence away from breaking several of them at once.

HROpsLab publishes independent comparison work across HR tooling and workforce systems. We sell nothing, we take no vendor money, and we publish no paid placements. If the next step is understanding what your current tooling can hold, our comparison work is one place to start.

Frequently Asked Questions

The rota is built from what you wrote down. The good rota needs what you didn't.