ai as amplifier
Fix it first. Then amplify it.
Every promoter in the country is being sold AI this year. It’s in every pitch, every board conversation, every vendor email. And a great deal of it is genuinely useful. But underneath the noise sits a quiet, expensive misunderstanding that is about to cost a lot of mid-market businesses a lot of money — and it’s worth naming plainly before you sign the cheque.
Here it is: automation is an amplifier, not a cure. It takes whatever process you already have and makes it faster, cheaper, and larger. If the process underneath is sound, that’s transformative. If the process underneath is broken, you have just built a machine that produces broken outcomes at scale — and does it faster than a human could, so you notice the damage later and at greater volume.
AI doesn’t fix a bad process. It industrialises it.
Why this trap is so easy to fall into
The appeal of automation is precisely that it promises to skip the hard part. You have a messy, manual, frustrating process — invoice matching, lead qualification, customer support, quality checks — and someone offers to make the mess disappear behind a layer of software. It’s a seductive offer, because it lets you avoid the genuinely difficult work of understanding why the process is messy in the first place.
But the mess is usually not a technology problem. It’s a design problem. The process is slow because responsibilities are unclear, or because three departments each hold a piece of it, or because the rules are inconsistent and everyone has learned to work around them. Automate that and you don’t remove the confusion — you encode it. The unclear responsibilities are now unclear in code. The inconsistent rules are now inconsistently enforced at machine speed. And the workarounds people used to apply with judgement are gone, because the machine doesn’t improvise.
The result is a familiar pattern: a large investment, an impressive demo, and six months later a system nobody quite trusts, quietly worked around by the same people it was meant to free.
The question to ask before you automate anything
There is a simple test that saves an enormous amount of money, and almost nobody applies it before buying: if you had to run this process perfectly, by hand, could you write down exactly how?
If the answer is yes — if you can describe the steps, the rules, the decisions, and the exceptions clearly enough that a competent new joiner could follow them — then your process is a candidate for automation. You know what “good” looks like, so a machine can be built to produce it.
If the answer is no — if the honest description is “it depends,” or “you’d have to ask Ramesh,” or “well, it varies” — then you are not ready to automate. Not because the technology can’t handle it, but because you’d be asking the technology to make decisions you haven’t made yourself. Automating an undefined process doesn’t define it. It just hides the fact that it was never defined, until the day it produces a result nobody can explain.
The uncomfortable truth is that the work of getting a process ready to automate — clarifying the rules, resolving the exceptions, deciding who owns what — is most of the value. Do that work and you’ll often find the process runs dramatically better even before any software touches it. The automation, when it comes, is then the easy final step rather than a gamble.
Fix first, then amplify
None of this is an argument against AI. It’s an argument for sequence. The right order is: understand the process, fix its design, and then automate the version that works. The businesses getting real returns from AI are almost always the ones who did the boring middle step. The ones who are disappointed almost always skipped it.
This is the same logic we apply to any tool, and it’s worth stating as a principle: the tool is never the transformation. A capable automation platform, a language model, an analytics suite — these are components. What makes them valuable is the well-designed process they run on top of. Buy the component without doing the design work and you’ve bought an amplifier with nothing worth amplifying.
That reframe changes what you should be shopping for. The question is not “which AI tool should we buy?” It’s “which of our processes is well-designed enough to be worth automating — and which ones do we need to fix before we go anywhere near a vendor?” That’s a harder question, and a far more valuable one, because it points you at the work that actually determines whether the investment pays off.
The businesses that will win with AI
They won’t be the ones who bought the most, or the earliest, or the flashiest. They’ll be the ones who were honest about the state of their processes first — who resisted the temptation to paper over a design problem with a technology purchase, did the unglamorous work of making their operations legible, and then automated something that was already sound.
Everyone else will spend the next two years discovering, expensively, that a faster broken process is still a broken process. It just breaks more of your business, more quickly, and with a bigger invoice attached.
Fix it first. Then amplify it. In that order, AI is one of the best investments you can make. In the other order, it’s one of the most expensive mistakes.
If you’re being pitched AI and you’re not sure which of your processes are actually ready for it, that question is worth answering before you buy. See how our Operations practice gets processes ready to scale → — or read why we build the method before the tool →
