TL;DR: We thought we were too busy to take on new AI and software projects. So we pointed AI at our own operations to find where our capacity was leaking. It wasn't a workload problem. It was an oracle problem. This is how we found that out. What we did about it is in the next article.
If you've ever found yourself permanently busy in your own company while the work you actually want to do keeps getting pushed back, read on.
Last year we got better at telling people what else we could do. We talked more confidently about software, automation and AI, and showed people some of the things we'd already built. And, inconveniently enough, they started asking for them.
Of course, that was the whole point, but the problem was that the new work started to queue up. Nobody seemed to have enough time to get onto it. Everybody felt busy, the IT support work kept coming, the days disappeared, and the AI and software work we had deliberately gone out and won was sitting there waiting to be scoped, quoted and delivered.
I want to make one thing clear at the outset, because otherwise this article could give the wrong impression completely. The existing work was getting done. We weren't drowning in unanswered support calls and disappointed customers. The problem was that running the existing business seemed to require far more human attention than the visible workload could account for. We couldn't reconcile the amount of work we could see with how busy everybody felt, and that was what finally made us look properly.
Why we'd never looked before
The obvious question is why we hadn't done this years ago, and the honest answer is slightly uncomfortable. We were making money. We were busy. Things were happening. If we ever stopped being busy, our normal reaction was to go and look for more work, not to start examining ourselves.
We'd always had this nagging feeling that things got a bit stressed when we became really busy, but we assumed that's simply what busy feels like. There's work coming in, everybody is running around, you deal with it, and eventually things calm down again. Nothing about that seemed particularly mysterious.
There's a name for that, as it turns out: satisficing. You find an explanation that fits well enough and you stop looking.
"That's just what busy feels like" had been our explanation for years.
What then changed was access to the information rather than any new insight.
We recently moved away from our old PSA (our service and ticketing software) and onto one we've built ourselves. The underlying information existed in the old system too, so I'm not claiming we'd somehow invented data. The difference was that it suddenly sat somewhere I could interrogate directly. I could point AI at 15 years of our own operational history and start asking questions without turning the exercise into an IT project first.
One of the first numbers we looked at was utilisation.
Depending on how we measured it, it came out somewhere between 17 and 25 per cent. Wow.
Now, hours recorded against theoretical capacity are a diagnostic signal, not a performance target, and a lot of perfectly legitimate work never touches a support ticket. Finance doesn't raise a ticket. Neither does supplier administration, banking, correcting an old record or answering an internal question. So the number didn't mean people were working for a quarter of the day and spending the rest looking out of the window.
The size of what we found is what mattered. If that number had come back at 65 or 75 per cent, this would be a very different article. At 70 per cent you're hunting marginal gains. You start asking whether there's a bit of headroom, whether a few processes could be tidied up and where the remaining capacity might be hiding.
Under 25 per cent isn't a marginal-gains problem. It's a 😲 problem, because it means you can only account for a quarter of a company that simply never seems to stop. I'm busy. Like every small business owner in the country, I work quite hard, thank you very much. Everybody around me appears busy too.
So what on earth is going on?
That's a much more interesting question, and not one you can answer by simply managing people harder.
The irritation was the instrument
There was another clue which I'd managed to ignore for years.
In terms of working profiles, I'm the one who enjoys pulling things apart, following threads and trying to understand why things work the way they do. One of my colleagues, though, wants to come in, do her job properly, get something finished and go home knowing it is done. Neither is the wrong way to work. They're complementary but very different.
The friction between those two working styles was constant, low-level and almost entirely about information. Can I have this? Where were you yesterday? Can you give me your time for that job? Did we agree something with them? Why has this customer got that licence?
Both of us found it wearing, from opposite ends.
What neither of us had spotted was that those questions were the canary in the coal mine. They weren't interruptions caused by one person badgering another. They were occasions when the business itself couldn't answer a perfectly reasonable question, so a human being had to do it instead, and it happened for so long it became our established way of working.
The irritation wasn't the problem. It was the only instrument we had, and we were annoyed by doing it rather than looking at what it was telling us, if we'd only listened.
That was when I thought: we're constantly telling customers that we're good at using AI to analyse information, find patterns and automate processes. Why don't we point it at ourselves?
What I was actually trying to build
Years ago I worked with a contract project manager who spent his first few weeks doing almost nothing except asking very specific questions. Not "how's the project going", which nobody can answer usefully. What exactly do you do here? What happens when this fails? Who tells you when it does? He offered no theories and passed no judgement. He just collected. I remember thinking: this bloke is asking the right stuff.
That was what I wanted AI to do. Not hand me an answer after the first question, but keep asking questions and hold weeks of observations at once, dive deep so that whatever came out at the end was the whole picture rather than an evaluation of a Monday morning rant.
So the AI prompt wasn't a question. It was a standing instruction to keep asking me questions and not to diagnose anything yet. Which is the opposite of what I'd been doing on my own for fourteen years, because when a conveniently plausible answer turns up early you stop looking. Something that only asks and never concludes doesn't have that option. Just like that contract project manager.
Two ways of logging
Two people approached this exercise in completely different ways.
One kept a rough running account of what they actually did during the day. It wasn't a timesheet and there was no attempt to justify every six minutes. It was simply a record of where the time went: billing, invoices, email, queries, chasing information, fixing access problems, checking things, talking to colleagues. I asked for this rather tentatively because I expected resistance. Instead she just said, yes, all right, I'll do that for you. I suspect she welcomed the opportunity to be honest, which is indicative in itself.
The first few hours of her notes took the top of my head off. A surprisingly large amount of her morning wasn't the core job at all. It was obtaining information, resolving ambiguity, checking history and clearing obstacles before any actual work could continue. The notes were meticulous, which matters, because you can only see any of this when somebody records it honestly.
I did something much looser. Every time something at work was frustrating, confusing, surprising, or occasionally really rather good, I simply told the AI about it. Usually by voice. I didn't categorise it or try to make everything fit a theory. I just said: this happened. Sometimes, I admit, I had to go somewhere away from others to have a damn good rant.
The truth is, at this point I did have a theory.
My comments complained that I was being asked for information constantly. Can I have this? What happened with that? Did we agree on something? And I was thinking: I'm trying to deliver new projects, and somebody keeps asking me another bloody question.
So if I'm truthful, I started logging partly to build a case. Look how hard done by I am. Look at all these interruptions. No wonder I can't get anything done. Woe is me.
After a few weeks I handed the whole collection back to AI and asked one simple question: what patterns can you see?
It didn't say "poor Tim"
What came back was not sympathy, and it was not the answer I'd been fishing for.
I'd been quietly hoping to hear that I was being interrupted unreasonably. What it said instead was that the people asking had no choice. The information they needed genuinely wasn't anywhere they could get at it, so the only remaining route to it was me. Why couldn't they find it elsewhere? Why isn't this written down?
That is a very different outcome than the one I'd expected, and it took me a while for the penny to drop. Every interruption felt like a crisis, and the crisis was always the same: somebody didn't have information they should have been able to find in ten seconds.
I'd gone looking for a stick and been handed a mirror.
The oracle system
For years this company ran on two or three people who simply knew.
Why has that client got that licence? What happened on that job? Did we promise anything? You asked one of the oracles and you had the answer in thirty seconds.
It's a system, and a good one. It's fast, it costs nothing to run, and it needs no software whatsoever. Its only flaw is that it's invisible and lives inside people rather than inside the company. And because it worked, we never built the other kind.
Then the team became smaller and more specialised. Nobody left dramatically. The oracles just thinned out. And you don't notice an oracle disappearing until you ask a question and discover there is nobody left to ask.
An oracle system doesn't only fail when oracles leave. It heavily taxes the ones who remain.
If you're the person who knows the answer, simply by virtue of twenty-five years in the business, you become an internal search engine all day. The valuable queue of AI and software work I couldn't get near was sitting directly behind my own oracle duties.
There's a nasty cost too: if the only reliable way to get an answer is to ask the person who knows it, nobody else gets the opportunity to develop the judgement that would eventually allow them not to ask. You don't grow into a decision you're never in a position to make for yourself. Minions, not oracles.
What the logs showed: context recovery
Once we'd seen that pattern, we noticed it everywhere.
Mixed in with legitimate work was an extraordinary amount of activity whose only purpose was obtaining enough context to continue: hunting for an access code, checking why a licence existed, working out if a technical tweak affected billing, or cross-referencing two systems because neither told the full story.
All of it was real work, and almost none of it produced anything new. It was recovering context. We'd gone looking for a utilisation problem and found an information problem.
We weren't short on communication. Teams messages, calls and office chats were flying all day. The problem was that this communication was entirely ephemeral. A technical fix lived in a chat thread, an agreed outcome stayed in someone's head, and nobody recorded why a commercial decision had been made.
A ten-minute interruption isn't just ten minutes lost. It takes two people down, and both have to rebuild whatever mental context they were holding before the question was asked.
Testing 2,000 tickets back to 2011
To make sure we hadn't just constructed a convenient story out of a few frustrating weeks, we tested the theory against our history. We pulled a sample of 2,000 client tickets dating back to 2011.
The test was simple: if the person who did this job were unavailable tomorrow, could someone else understand enough from this record to answer the client?
Only one in four passed.
The work had been done, but the understanding it produced had stayed in the engineer's head. Length made no difference. Plenty of long tickets simply provided a tidy chronology of activity without ever explaining the diagnosis or the reasoning. Activity, yes. Understanding, no.
It turned out we weren't undocumented. We were documenting the wrong thing.
Our records had always been written to be customer-friendly rather than company-friendly. Clients don't need the messy internal reasoning. They just want the outcome. Because we had oracles to bridge the gap internally, there was never any pressure to capture the internal why.
Depending on exceptional people to carry the company in their heads is pride dressed up as a strategy. It feels like a compliment to the team right up until somebody goes on holiday.
The overdraft on clarity
Poor information capture doesn't remove work; it defers it.
Saving thirty seconds today by skipping the context simply borrows effort from the future. Later, somebody has to stop what they're doing, locate the person who knows, wait for an answer, and reconstruct the puzzle. It is an overdraft on clarity, and the interest is paid in daily interruptions.
Timing matters as much as content.
An engineer rings a client at half nine because their email has stopped working. They fix it, intending to update the ticket later. At eleven the client rings back and the engineer is on another call. The work may have been technically perfect, but at that exact moment only one person in the company knows what happened, and they're unavailable.
A perfect note written at four o'clock is no use to the person answering the phone at eleven. The metric that actually matters isn't logged information. It's time to logged information.
None of this was catastrophic and no client was ever let down by it. It was irritating, and quietly expensive in a way that never appeared on a report.
Our accountant told us in 2012
This wasn't a recent decline. Around 2012, our accountant looked at our recorded hours against our headcount and observed, politely, that the maths didn't produce a very impressive number. He suggested we weren't as efficient as we thought.
I remember thinking: well, we're all busy, so I'm not sure I agree with you.
I didn't say it out loud. I just ignored it. He's still our accountant, and I probably owe him an apology fourteen years late. He was right. But a plausible excuse, "that's just what busy feels like", stopped me looking further.
The test you can run today
You don't need a custom platform to test whether you have an oracle problem. If you're a surveying practice, look at your job files. If you're a contractor, look at your site handovers. If you're an accountancy firm, look at your client trails.
Pick a live job, any one, and ask: could somebody else pick this up tomorrow and carry on without asking a single question?
If yes, your company knows what its people know. If no, that work is trapped inside one person, and you'd better hope they're in on Monday.
Where that leaves us
We thought we had a utilisation problem. What we actually had was a clarity problem. It generated a constant background tax of questions, chasing and context recovery that never showed up on a balance sheet.
None of which, on its own, fixes anything. Knowing where the time goes isn't the same as getting it back.
In the next article I'll share the other half: what we changed, why the first version annoyed everybody, and what four weeks of the new system actually achieved, including the operational assumption I had got completely wrong for twenty-five years.
If you want to run this yourself
This is the prompt I actually used, not a tidied-up version. The important part is the last line of the first paragraph and the word ANALYSE. It is a standing instruction to collect and not conclude, and you release it only when you think there is enough evidence to be worth looking at. Everything else is scaffolding to stop it being helpful too early.
Paste it, then feed it incidents as they happen. Voice notes are fine, preferred even. It works better if you don't tidy them up.
I want to use this conversation as an observation log about how my business actually works. For now, you are not a consultant and you are not trying to solve anything. Your job is to listen, clarify and keep structured notes. I am going to tell you incidents, frustrations, examples, things that worked well, things that surprised me, and sometimes half-formed theories about what I think is going on. Until I explicitly say ANALYSE, do not: * diagnose the underlying problem * suggest solutions * tell me what pattern you think is emerging * agree with my theories merely because I have repeated them * turn one incident into a conclusion about a person * recommend management action Instead: * record what happened as factually as possible * separate what I observed from what I inferred or felt * ask clarification questions where important facts are missing * ask for dates, sequence, ownership, expected outcome and actual outcome when those matter * note counter-examples as carefully as negative examples * preserve uncertainty rather than filling gaps * notice when I am making an assumption, but don't try to resolve it unless a question would establish the facts * maintain running notes so that incidents don't disappear into the conversation If I rant, let me rant. Extract the useful facts from it and ask whatever question would make the incident clearer. Don't treat the emotional strength of what I say as evidence that my interpretation is correct. Ask questions naturally rather than interrogating me with a questionnaire. Usually ask one or two useful questions at a time. Keep an internal running record under roughly these headings: incident / what happened; what was expected; what actually happened; who knew what and where the information existed; ownership and next action; impact; my interpretation or theory; alternative explanations and missing facts; counter-evidence; anything worth checking later. Do not give me the running analysis unless I ask for it. You can occasionally give me a short factual recap if the conversation is becoming difficult to follow, but don't convert that recap into conclusions. When I eventually say ANALYSE, use the whole accumulated record rather than just the most recent incidents. Look for repeated patterns, contradictions, counter-evidence and alternative explanations. Tell me which conclusions are strongly supported, which are plausible, and which aren't supported. Most importantly: do not decide the answer before we've finished collecting the evidence.
One warning from experience. It will not flatter you. I went into this wanting to be told I was being interrupted unreasonably, and it told me the interruptions were avoidable and the information should already have existed. That is the whole value of it, and it is not a comfortable few weeks.
If your business feels permanently busy but you can't quite account for where the capacity is leaking, this is the operational problem we now use AI to diagnose. We tested it on ourselves first. If this sounds familiar, I'd be glad to compare notes.
This article first appeared on LinkedIn (opens in a new tab), which is where the discussion is.