I did the work myself. Followed the shifts, sat with the supervisors, and reported back on the business as it stood: here is where the labour hours go, here is where our own team is stymied, here is where we disappoint clients, here is what has to change, here is what it is worth.
Nobody argued with the analysis. What came back was the weekly report. Labour hours are a fast number, visible every Monday. A team working around a broken process and a client quietly deciding you are hard work are slow ones, and they surface in a quarter or a renewal or an exit interview. The fast number wins every argument that gets held weekly.
Rebuilding a roster makes it worse before it makes it better: four to six weeks of uglier numbers on the way to a cheaper year. The annual result would have carried that dip comfortably. The quarter probably would have. The week could not, and the week was what got read.
So the ask was for consistent short-term gains, and the structural change went in anyway, in pieces small enough that no single week showed a dip we could not defend. It took two years. After a decade flat, the division grew close to twenty per cent.
The lesson stayed with me, and it is not that the constraint was wrong. A weekly report is a reasonable thing for a business to run on. The lesson is that the constraint sets the maximum size of any single change, and almost nobody works that out before they start. A diagnostic rarely dies of being wrong. It dies in the gap between the weekly number and the annual one.
So when a business tells me it needs AI, my first question has nothing to do with AI. It is: what processes are slowing your people down?
Here is how I answer that. The whole method is below. You can run it yourself, and for a lot of businesses you should.
One: map how the work actually moves
The org chart tells you who reports to whom. It tells you nothing about where the time goes. What you want is the sequence: who touches the work, in what order, what they wait on, and where a decision gets made by someone holding half the information.
To do this yourself, pick one process that crosses at least three people and follow a single real instance of it end to end. Not the process in general. One job, one invoice, one shift, one order. Write down every handover, every wait, and every time somebody types in information that already exists somewhere else. Put rough times against each step on the same day you watch it, because your memory of how long things took is generous by about half.
Where this goes wrong on your own: you will map the process as designed rather than as run. People describe the version of their job that makes them look competent, and they are not lying, they have stopped noticing the workarounds. The only cure is watching one live instance instead of asking for a description.
Two: talk to the people doing the work
They know where it breaks. They have known for years. They are rarely asked, and that still surprises me every time.
Ask better questions than “what’s broken?” That invites a complaint, and complaints get filed. Ask what they worked around this week. Ask what they do twice. Ask what they would stop doing tomorrow if nobody noticed, and then ask what would break if they did. Those three questions get you further than an hour of open-ended interview, and you can run them in ten minutes at a bench.
Write down the exact words. “I export it, fix the dates, then paste it into the other one” is a workflow. “Reporting is a bit clunky” is a mood.
Where this goes wrong on your own: they are talking to their manager. Some of it gets filtered, and the filtered parts are usually the expensive ones. There is nothing mystical about the outsider’s advantage here. Nobody’s performance review is attached to me, so the answers arrive unedited.
Three: separate the technology problem from the process problem
A good share of “we need AI” turns out to be “we need a decision rule.” Sometimes fixing the process is the whole fix. Knowing which one you have before you spend anything is the point of the exercise.
There is a test you can run on every friction point you found, and it costs nothing. Ask which of these four it is:
Nobody owns the decision.
Nobody agrees on what the number means.
The information exists, but it is somewhere else.
The information does not exist.
Only three and four are candidates for software. One and two are governance, and buying a tool to fix them gives you the same argument with a dashboard attached. If two people disagree about what “labour cost” includes, an AI that calculates it in four seconds instead of four hours has bought you a faster disagreement.
Where this goes wrong on your own: sunk cost. If you have already paid for two subscriptions and a stalled pilot, the internal answer bends towards “we need to use them better.” It is very hard to run this test on a tool you have already defended in a budget meeting.
Four: put a number on it before you price a fix
Value first, cost second. For each friction point, work out what it is worth: hours per week, times the loaded rate of the person losing them, times fifty-two. Crude is fine. You are separating the twelve-thousand-dollar problems from the two-hundred-thousand-dollar ones, and crude numbers do that.
Then sort by that number and ignore the bottom half. Most improvement plans fail because they have nineteen items and no order. The plan that works has three things on it and a date against each.
Then cost the dip. Every structural fix worth doing gets worse before it gets better, and you should know roughly how deep and how long before you start. Four weeks of a five per cent worse number is a survivable answer. Nobody having decided in advance that it was survivable is how the work stops in week three.
So name who absorbs it, in writing, before anything moves. Which report will look worse, who reads that report, and who has agreed to hold the line while it does. If the answer is that the weekly number cannot dip, that is not a reason to abandon the plan. It is the size of your increments, handed to you on day one instead of discovered halfway through a roster rebuild. Cut the change into pieces small enough that no single week shows a dip anyone has to defend, then accept that it will take you two years instead of two months.
Where this goes wrong on your own: the plan gets written, everyone agrees with it, and then Monday happens.
What we do, and what we do not
We run this for people, and then we build what it found.
The build is the part most diagnostics hand off. I understand why. The usual way to prove you are independent is to refuse to implement, so that nobody can accuse you of recommending your own next invoice. It works, and it charges the client for the proof: they buy a plan, then go looking for someone to make it real, and that someone arrives with no memory of the interviews and a commercial interest in the answer being large.
Independence comes from the money, not the distance. Ours is demonstrable: no reseller agreements, no partner tiers, no referral fees, no percentage of anyone’s licence spend. If the answer is a fortnightly meeting and one agreed definition, great, and we will say so in writing. If you need us to build or deploy a platform, we will help design a solution that matches the size of the problem, you own the code outright, and we stay until it runs without us.
Somebody has to be in the room in week three, when the change is in and the number has gone the wrong way and it is far too early to tell whether that is the dip or a mistake. That is the week the work is actually decided.
In the division I ran, it took two years of pieces small enough to survive a Monday, and it worked, and no part of that was in the analysis.