Rotas and routes: the tools that actually solve them

A different kind of problem

Everything else in this course is a language problem. A rota is not.

“Two people on every shift, Ana cannot work Tuesdays, nobody more than five days, Miguel and Sofia not paired, everyone gets one weekend off in three” is a constraint satisfaction problem. Solving it means searching through possible arrangements until one satisfies every rule: a procedure, run by a computer, that either finds a valid answer or proves there is not one.

A language model does not search. It writes a rota-shaped document, and rota-shaped is not the same as valid. Ask it to check its own work and it will confidently confirm the rota it just broke.

The same applies to delivery routes, packing a van, fitting appointments around travel time, and allocating machines to jobs. If your problem has hard rules that must all hold at once, you want a solver.

What to use instead

Your existing software. Booking systems, rota apps and delivery platforms very often have a scheduling feature already. Check before installing anything.

A spreadsheet solver. Both LibreOffice Calc and Excel ship with one, free, and it handles a small rota or an allocation problem well. Set up the cells, state the constraints, press solve.

OR-Tools, released free and open source by Google, is a serious constraint solver with worked examples for staff rostering and vehicle routing. It needs a little Python, and “a little” is genuine: the rostering example is about eighty lines and is designed to be adapted.

Dedicated route planners. For deliveries, tools starting free for a handful of stops. Routing well is a hard problem and worth not solving yourself.

Where the model earns its place

Three real jobs, and they are not the scheduling.

Turning what is in your head into a written list of constraints. Most owners have never written the rules down, and half the rules are unstated. Interview me about how we build the rota. Ask one question at a time until you have a complete list of rules, and tell me where two of them conflict. This is a good exercise and it frequently finds the contradiction that made the rota impossible.

Writing the solver code from the constraint list. Given a clear list, generating an OR-Tools model is code generation, which it does reasonably. You then run it, and the solver, not the model, guarantees the answer.

Explaining the result. “No valid rota exists” is unhelpful. “There is no solution because Thursday needs two people and only Ana and Miguel are available, and they cannot be paired” is actionable, and turning solver output into that sentence is language work.

Writing the awkward message to the person who did not get the weekend they wanted.

The check that catches everything

Whatever produced the rota, verify it with a rule that is not the thing that made it.

A spreadsheet with one row per constraint and a formula returning TRUE or FALSE. Ana on a Tuesday? FALSE. Anyone over five days? FALSE. Every shift covered? TRUE.

Ten minutes to build, reusable every week, and it catches the failure whether it came from a model, a solver misconfigured, or a tired person at ten at night. The verification is cheap even where the solving is hard, which is true of most constraint problems and is the practical reason this check is always worth building.

When to stop

If your rota takes twenty minutes a week and works, leave it alone. This lesson is for the business where scheduling hurts: many staff, many rules, or routes that waste real fuel. Below that, a solver is a project you do not need.

Start by writing the rules down

Before any tool, get the constraints onto paper and mark each one hard or soft.

Hard rules cannot be broken: legal rest periods, the qualified person who must be on site, the two-person minimum. Soft rules are preferences: Ana would rather not work Mondays, people like alternating weekends.

Most rota misery comes from treating a preference as a rule. Once separated, a problem that seemed impossible usually has several answers, and you can rank them by how many preferences they satisfy rather than searching for a perfect arrangement that does not exist.

Show the list to whoever actually builds the rota now. They will add three rules nobody wrote down, and those three are usually the reason previous attempts to automate it failed.

What good looks like

A rota you can defend. When somebody asks why they got two weekends in a row, you can point at the rules and show that no arrangement satisfying the hard constraints gave them anything else.

That is worth more than the time saved. Rota disputes in small teams are rarely about the hours; they are about the suspicion that the allocation was arbitrary. A written rule set and a check that everybody can read removes the suspicion, whichever tool produced the schedule.