❝ Most operational bottlenecks look like a software problem and are actually a documentation problem. The rules governing when work can happen sit in notes fields, email threads and one long-serving employee's memory, in a form no system can read. Firms buy scheduling software, discover it cannot honour rules it was never told, and conclude that automation does not work for a business like theirs. The cheap fix is to write the rules down first, which nobody wants to do because it is dull and takes about a fortnight.
A commercial cleaning company in Birmingham holds 74 site contracts and employs 38 cleaners, most of them part time. The rota is built every Wednesday by a supervisor called Marie, on paper, and then typed up.
Two years ago the company bought workforce scheduling software. It cost £9,400 to implement. It is still paid for monthly. Nobody uses it.
The story of why nobody uses it is the whole of this article. The software worked. It could allocate 38 people across 74 sites in under a second and it produced, on its first attempt, a rota that was almost perfect and completely unusable. It put a cleaner without a DBS check into a primary school. It scheduled the solicitor's office for 6pm on a Friday, when the building alarms at 5:30. It sent someone to a site where the client had asked, eighteen months earlier and by telephone, that a particular cleaner never return.
Marie's rota accounts for all three of those things. It has always accounted for them. She has simply never been asked to say how.
The rules exist. They are just not anywhere a computer can look
Every recurring operational decision in a small business is governed by constraints, and those constraints fall into two groups: the ones somebody typed into a field with a name, and the ones somebody wrote in prose or agreed on a phone call or simply learned.
The second group is almost always larger. In the pest control company we mapped this week, an average job carried around nine constraints on when it could be performed. Exactly one of them, the contracted service frequency, existed as structured data. The remaining eight lived in a free-text notes field, written by fourteen different people over six years.
This ratio holds with remarkable consistency across the businesses we look at. The manufacturing firm where the changeover sequence depends on which press was running last, recorded nowhere. The dental practice where three clinicians have preferences about appointment length that no booking system knows. The accountancy firm where certain clients are always, always called before their letters go out, for reasons that predate two members of staff.
These are not edge cases. They are the operating system of the business, and it is undocumented.
Why buying software makes it worse
Here is the sequence that plays out, and it is so consistent you could set a watch by it.
The owner recognises a bottleneck. Somebody is spending a day and a half a week doing something a computer should do. They research tools, sit through demonstrations, and buy the one that demonstrated best. Implementation goes fine, because implementation means importing sites, staff and frequencies, all of which are structured data and all of which import cleanly.
Then the system produces its first output, and the output is wrong in ways that are obvious to everyone in the building and invisible to the system. Marie is asked to correct it. Correcting it takes longer than building the rota from scratch, because now she is both applying her knowledge and arguing with a machine about it.
Within three weeks the software is background expenditure and Marie is back on paper. The conclusion drawn is that scheduling software does not work for a business like this one, which is a reasonable conclusion from the available evidence and entirely wrong. The software was never given the rules. Nobody asked it to guess, and it did anyway, because that is what it was built to do.
This is one of the more expensive versions of what process bottlenecks actually cost, and it is worth reading the arithmetic on hidden costs alongside it, because the £9,400 implementation is the smallest number in the story. The larger one is the two years of Marie's Wednesdays that followed.
What changed, and why this is now worth doing
Extracting rules from prose used to be a manual job. Somebody sat with Marie for a week and wrote things down, which cost more than the software and produced a document that went out of date immediately.
Language models are genuinely good at this specific task, and it is worth being precise about what the task is. A model reading 2,400 site notes and returning structured constraints is doing translation, not judgement. It is turning "only after 5pm, ring Kevin first" into an access window and a notification flag. That is a narrow, checkable, boring job, and boring jobs are where these tools are reliable. Ask the same model to decide the rota and it will produce something confident and slightly mad.
The design that works splits those two things apart. The model reads the prose and proposes constraints. Deterministic code checks them. A solver, which is decades-old mathematics available for a few pounds a month, does the allocation. A human approves the result and their corrections are captured as new constraints rather than being repeated every week. There is more on how agents actually work if the division of labour is unfamiliar.
The pest control company that ran this design cut average travel between jobs from 37 minutes to 24, and stopped needing the two technicians it had budgeted to hire. Neither number came from better routing software. Both came from the fortnight spent turning a notes field into a constraint list.
The part nobody wants to hear
The documentation fortnight is not optional and cannot be skipped by buying something more capable. Every tool on the market will schedule around constraints it has been given. None of them can schedule around constraints held in a supervisor's memory, and no amount of model capability changes that, because the information is not in the building's systems at all.
There is a version of this article that ends by recommending a product. This one ends by recommending a fortnight of dull work that costs nothing, after which several products would have worked fine, including the one already being paid for.
This week
Take the recurring job in your business that gets rescheduled most often. One job, not a category.
Write down every rule that governs when it can happen: who can do it, when it can start, what has to be true first, who has to be told, what makes it impossible. Keep going until you cannot think of another one. Then go through your list and mark which rules exist in a field, in a system, with a name.
Whatever that fraction turns out to be, it is also the fraction of your scheduling problem that software could currently solve.
Marie's list ran to 31 rules across 74 sites. Four of them were in the software.
The AdAI newsletter maps one of these bottlenecks end to end every week, free to read. Subscribe here.
Automation did not fail at the Birmingham cleaning company. It was asked to work from a rota that only existed in one person's handwriting.
