There had to be an easier way.
RotaBot was not built because scheduling looked like a good market. It was built because somebody had to produce a staff rota every week, by hand, and the job was consuming an unreasonable amount of a manager's week for a problem a computer ought to be able to solve.
Written by Dylan Langmead, founder of RotaBot and general manager of Rustington Golf Centre.
A rota looks simple until you have to build one.
From the outside it is a grid. From the inside it is a set of constraints that all touch each other, and you are holding every one of them in your head at the same time.
- Annual leave
- Availability
- Contracts
- Legal shifts
- Opening hours
- Skills
- Role requirements
- Demand
- Shift limits
- Coverage
- Labour hours
Move one shift and you have to re-check the others. Give somebody a Saturday off and somebody else has to be qualified, available, under their hours and not already working a shift that makes the day illegal. Every answer changes the question. That is why staff scheduling swallows an evening: not because any single decision is hard, but because no decision can be made on its own.
And then it happens again next week. Same puzzle, different pieces — a holiday request, a new starter, a change of opening hours — and the whole reconciliation starts from the beginning. Nothing you worked out last week is reusable, because the inputs moved.
Built in a real business, not a lab.
RotaBot was written by a general manager at Rustington Golf Centre in West Sussex, against that operation's actual rota — not a tidy scheduling example with three staff and one role.
Real constraints, from the first week
Multiple roles and the areas they cover. Contracted staff whose availability is contractual, and casual staff with no guaranteed hours. Approved leave. Fixed shifts that never move. Opening hours that differ by day, and staffing requirements that differ with them.
Tested by having to use it
Every awkward case turned up on its own: the shift nobody was qualified for, the week that could not be covered legally, the day a rota that looked saved had not actually been stored. Problems found by relying on something are different from problems found by imagining it.
Answerable to real staff
A rota that is wrong is not a failed test — it is somebody turning up on the wrong day. That is the standard the software had to meet before it was worth showing anybody.
From a script that helped, to software that runs the week.
The order things were built in is the order the problem revealed them. Nothing here was designed up front.
- 01
Understand the week
How many people the business needs, doing what, at which hours — the thing every other decision is measured against.
- 02
Model the people
Contracted and casual hours, who is trained for what, availability, approved leave, shift limits, the shifts that never move.
- 03
Build legal shifts
Not a list of names against slots — whole shifts a person can lawfully and practically work.
- 04
Measure the coverage
Against the requirements, honestly. A week that is short says which requirement it could not fill, and why.
- 05
Keep what the manager changed
What was generated, what was published, and every difference between them — recorded change by change.
The week stopped being built by hand.
The honest version, without invented numbers.
The rota stopped being assembled from a blank grid and started being reviewed. That is the actual change, and it is a bigger one than it sounds: reading a finished week and adjusting two shifts is a different job from reconciling ten constraints across seven days from nothing. The evening it used to take is not spent that way any more.
We have not published a saved-hours figure, because we have not measured one properly and would rather say nothing than print a number we cannot stand behind. What we can point at is what the software does: it generates the week against the requirements, measures coverage against them, and when it falls short it names the requirement it could not fill instead of quietly reporting a percentage.
The first solve is the start.
When a manager changes a generated rota, the change contains information: they knew something the solver did not. That was the whole reason to keep building after the week came out.
It keeps the difference
TodayWhat RotaBot generated, what was published, and every difference between them — kept as the input to what RotaBot suggests next. Each one is tested against the inputs that solve actually had, so a change RotaBot could not legally have made itself is filed as a gap in the model rather than as something to copy.
It uses it, once you say so
TodayThe same correction across three published weeks is put to you as a pattern to confirm or dismiss. Confirmed, it informs the next solve — the ordinary weekly generate as much as a repair when a week is short — and it never moves a hard constraint. Availability, approved leave, qualifications and legal shift limits are the boundary, not preferences, and a confirmed pattern is too small to trade away required coverage or contracted hours.
Managers should be managing.
Nobody was ever promoted for reconciling availability against contracted hours by hand.
A general manager's time is worth more on the floor than in a spreadsheet: leading a team, serving customers, training somebody new, fixing the problem that only turned up this morning. The weekly rota is real work, but it is the kind of work software is genuinely good at — a large set of hard constraints, solved against each other, the same way every week.
It is not only the hours. It is the attention. Holding an entire operation's staffing in your head every week is a real cost, and it is paid by the person you least want distracted.
It solved a problem we had ourselves. If it takes the same repetitive week off somebody else's desk, it should not stay an internal tool.
That is the whole reason RotaBot is a product. Not a market opportunity — a job we already had to do, done properly, and worth handing to anybody else doing it by hand.