The best rota came at 40 seconds

One store of a large supermarket chain runs home delivery with its own drivers. Its week has 294 shifts to fill, and the drivers who fill them work to rules: how long a day can run, how much rest comes between shifts, which shifts may be joined, how far anyone can go over their contract, and notes drivers have made about their own availability.

The store’s rota was built by hand. It covered every shift, so on paper the week worked. Checked rule by rule, it broke 73 of them: long days joined the wrong way, too many hours’ work inside a day, evening shifts joined to another, drivers too far over their contracts, and one driver’s own note missed.

The tool took about four hours of working with AI to build. It reads the store’s own spreadsheet and turns every driver, day and shift into a yes or a no. The rules become sums that any answer has to keep. What it minimises is a score built from paid hours, plus penalties for things we’d rather avoid, like asking someone to move their availability. A solver called CBC then searches for the rota with the lowest score that keeps every rule.

Everything specific to the store lives in one config file, so the code doesn’t change for another store. When the solver is done, separate code checks its answer again, from scratch. If that check fails, the tool refuses to build anything, including the copy of the store’s spreadsheet it writes the rota into.

We gave the solver a long run, capped at 40 minutes, and kept its log. Lower scores are better. Here is what it says:

• At 3.4 seconds, the first complete rota, scoring 134.25.
• At 3.7 seconds, the solver also knows that no rota can score below 117.08. That’s the floor.
• Better rotas follow quickly: 129.75, 125.25, 122.5, 119.75, 119 and 118.75, the last of them at 20 seconds.
• At 40.51 seconds, a rota scoring 118.5.

Then nothing. For the next 39 minutes it found no better rota. It stopped on its time limit at 2,411 seconds, with 118.5 still the best it had.

They didn’t buy a better rota. They bought a better floor. As the solver searches, it rules out more of the possible rotas, and what it can rule out lifts the floor. Over those 39 minutes it rose from 117.08 to 117.64. By the end we knew no rota could beat ours by more than about 0.7%.

That is the honest claim, and the case study makes no bigger one: it says the solver spent 39 more minutes “proving nothing could beat it by more than 1%”. It is not proof that 118.5 is the best rota there is. A slightly better one might exist. The solver didn’t find it in 40 minutes, and it could promise it wouldn’t be much better.

The log has a small trap at the end. Our own wrapper script printed “STATUS: Optimal”. Thirteen lines above it, the solver’s own result line says “Stopped on time limit”. When the two disagree, the solver’s line is the one to believe, and it’s the one the case study goes by.

For the store, the rota that mattered existed 40 seconds in. This run was capped at 40 minutes; the tool’s normal setting caps a solve well short of that. The time limit is one of the settings we can turn: a longer run gets closer to a proven best, at the cost of waiting for it.

The rota itself covers all 294 shifts with no rules broken, checked twice: once by the sums, then by the separate code. Against the rule-clean proposal it replaced, it saves the store about £3,000 a month and needs two new part-time roles rather than a bigger hiring drive.

What we take from it: here, the best answer came early, and nearly all the waiting went on certainty. It’s worth knowing which of the two you’re paying for. A store needs a rota by the end of the week, not a proof. But when someone asks whether this is the best we can do, the floor lets us answer with a number.