“The more eagerly a man struggles to reach it, the further he departs from it if he takes the wrong road; for, since this leads in the opposite direction, his very swiftness carries him all the further away.” – Seneca, De Vita Beata (On the Happy Life), c.AD58, Book I
There is a particular sequence that plays out in a number of business automation projects, and it tends to follow a recognisable pattern. The decision to automate is taken seriously. A credible vendor is appointed following a thorough selection process. The budget is approved, the implementation is managed well and the system goes live. Early metrics are encouraging. The team adapts to the new processes.
And yet, several months later, there’s a feeling of disappointment. The business is not obviously worse – in many respects it is objectively better. Information moves more quickly and some manual effort has disappeared as certain administrative tasks now happen automatically. Yet the organisation itself feels surprisingly much as it did before. The same people still seem to sit at the centre of important decisions. The same bottlenecks continue to appear. The same frustrations arise, albeit in slightly different forms.
The technology appears to have worked, yet the outcome often feels largely unchanged. It’s a pattern that appears often enough in business automation projects to be worth looking at, because it raises a question that is more interesting than it first appears. If the technology worked, why didn’t the outcome change in the way everyone expected?
The Technology Takes the Blame
As organisations grow, complexity accumulates, often faster than structure. Processes that once worked perfectly well begin to strain under increasing volume. Information takes longer to move. Decisions require more coordination. Work starts to gather around particular individuals simply because they have become the easiest route through the complexity.
Business automation appeals to founders and leadership teams carrying this increasing complexity because its promise is not really about technology, but about relief. Fewer manual handovers. Less dependence on individuals who are already stretched. Fewer decisions landing on the same desks they always have. The technology is incidental to that ambition – it is simply the mechanism through which relief is expected to arrive.
When it doesn’t arrive, the conversation usually returns to the implementation. The platform wasn’t the right fit. The integration with existing systems was more complicated than anticipated. The vendor’s promises didn’t survive first contact with the business. The team needed more support than was provided. These observations are sometimes accurate, at least in part, and they shouldn’t be dismissed too quickly.
But there is a pattern that sits beneath them, and it is something less comfortable. In many of the cases where the technology is blamed, the technology was performing correctly. It was processing what it was given, at the speed it was designed to operate, in exactly the way it had been configured. The expectation of improvement had become attached to the tool, rather than to the underlying conditions into which it was introduced. And those conditions, in most cases, had not changed at all.
What a system processes matters at least as much as how efficiently it processes it. That sounds obvious when stated plainly. It is considerably less obvious in the months before go-live, when attention is concentrated on configuration, training, and deployment.
The Process That Was Already There
Most automation in growing SMEs is applied to the processes that already exist in the business – which are often a very different thing to clean, well-defined ones.
Processes in established businesses tend to just accumulate over time. An original approach gets modified to handle an exception. The modification becomes standard. Someone leaves, and their particular way of managing a step becomes embedded in how the business actually operates, undocumented and largely invisible until the moment it needs to be replicated. By the time automation is considered, what looks like a process from the outside is often a layered set of informal arrangements, workarounds, and individual approaches that have solidified over time into something that functions, but only because the people involved understand its unwritten logic.
Business process automation has an interesting habit of exposing those imperfections.
A workflow that appears straightforward suddenly requires precise definitions. Decisions that were previously handled through experience now need explicit rules. Approval paths that were loosely understood have to be mapped. Exceptions that once lived comfortably inside conversations must somehow be translated into logic.
Consider, for example, a handover process that depends heavily on one experienced individual. The process may appear entirely functional while that person remains involved because much of the judgement sits in their head. They know which exceptions matter, which requests can be expedited, and which situations require a different response. Once business process automation enters the picture, that hidden judgement must either be defined or ignored.
If it is ignored, the process becomes more consistent but less complete. If it is defined poorly, the process becomes consistently problematic. Either way, the ambiguity itself remains. The technology did not create the problem, it simply made the problem easier to see.
Questions of ownership often emerge in a similar way. Many growing businesses operate successfully despite relatively vague decision boundaries. People compensate. Conversations fill the gaps. Someone steps in when required. The absence of clear ownership was tolerable when the process was slow enough to allow informal resolution. Speed removes that tolerance. When authority is unclear in a growing business, the consequences tend to become apparent gradually – and automation has a way of accelerating the timeline.
The Tools That Got Installed and Didn’t Stick
There is a version of business process automation disappointment that is more subtle than outright failure, and it may be the most common one in SMEs. The system goes live and training is completed. There is genuine enthusiasm in the first few weeks. And then, slowly, the old habits reassert themselves.
The spreadsheet that was meant to be retired is still open on someone’s screen six months later, because “the system doesn’t quite handle” a particular category of transaction. The approval that was meant to go through the platform is still being processed by email, because it is faster that way. The reporting that automation was supposed to generate is still being compiled manually, because the data in the system isn’t trusted entirely.
This is not resistance to technology. It is something more revealing. Each of these workarounds represents a point where the automated process encountered a decision that had not been made, an exception that had not been resolved, or an ownership gap that had not been addressed. Rather than stopping and forcing the resolution, the business moved around the problem. The tool was left to handle the parts of the process that were clear. The parts that weren’t clear continued to be handled the way they always had been.
In effect, the technology remains in place, but the organisation has only partially moved with it.
This is one of the more recognisable patterns in growing SMEs because it’s rarely dramatic. There is no catastrophic failure. No abandoned project. No formal declaration that the initiative was unsuccessful. Instead, expectations gradually deflate.
The execution gap in growing SMEs – the distance between decisions that are made in principle and actions that actually change – often shows up in exactly these situations. Over time, people adapt around unresolved issues. Informal workarounds emerge, and new habits develop. The system continues to function, but the business gradually rebuilds many of the behaviours it was hoping to leave behind.
Systems don’t make decisions. They just execute the ones that have already been made. When those decisions are absent, the gap simply persists, and the parallel workaround becomes, over time, the actual process.
In many respects, this is simply another version of a pattern that appears in broader discussions about execution. Organisations rarely struggle because they lack activity, but because ambiguity survives long enough to dilute the intended outcome. The same dynamic often sits beneath automation projects as well.
What Successful Business Automation Seems to Have in Common
It would be too convenient to suggest that successful business automation follows a formula. But certain patterns appear often enough to be worth noting, not as a set of requirements but as observations from cases where the investment actually delivered what it was meant to.
The processes that were automated successfully tended to be ones that were already understood clearly by the people responsible for them. Not perfect – no business process is – but well enough understood and documented that the people running them could describe what happened at each stage, who was responsible for each decision, and what constituted an exception. Ownership was unambiguous before the technology arrived. The exceptions were genuinely rare rather than a constant feature of daily operations. And in a number of the cleaner cases, the decision to automate came after a period of process clarification and redefinition, not instead of one.
McKinsey’s most recent Global Survey on AI notes that organisations beginning to see bottom-line impact from workflow automation and AI deployment are those redesigning workflows as they deploy – not those just layering technology onto existing processes. The finding is consistent with what tends to be visible at the SME level: the technology is rarely the differentiating factor. The organisational conditions into which it is inserted are.
The businesses where automation delivered were not, in most cases, more technologically sophisticated than the ones where it disappointed. They had greater organisational clarity. That clarity pre-dated the automation decision. It was not created by it.
What Was Really Being Scaled?
Most business automation projects are presented internally as business efficiency initiatives. The language is about speed, reduction of manual effort, freeing up time. That framing is understandable, but it can obscure what founders are usually seeking beneath the efficiency argument. What they tend to be seeking is capacity – more ability to grow without adding proportional complexity, more consistency without depending on specific individuals, more freedom from the constant requirement to intervene. Efficiency is the mechanism. Capacity is the goal.
That distinction becomes important because efficiency and capacity are not the same thing.
A business can process information more quickly while remaining dependent on exactly the same individuals. Reports may be generated faster while decision-making remains concentrated in the same places. Workflows may become more sophisticated while accountability remains ambiguous. The organisation becomes more efficient without becoming meaningfully more self-sufficient. And this is where automation starts to reveal something deeper about the business itself.
A business where decisions are concentrated in a small number of people, where authority is assumed rather than defined, and where the operating model depends heavily on individual knowledge and habit – that business, when it automates, tends to formalise precisely those conditions. The decision concentration becomes faster. The authority ambiguity becomes embedded in systems. The dependence on individual knowledge is either replicated in the configuration or lost when it isn’t. Structural problems in a growing business don’t disappear when a system is placed over them. They simply become more consistent, while the old bottlenecks remain.
A business where ownership is reasonably clear, where the operating rhythm is established and understood, and where decisions are made at the appropriate level rather than escalated by default – that business tends to find that automation creates genuine organisational leverage. The capacity it was looking for is actually available, because the conditions for it already existed.
The technology in both scenarios may be identical. The outcomes are not.
The Real Question
Most founders who invest in business automation do so with entirely reasonable intentions. The complexity is real. The pressure is genuine. The promise of relief is compelling. None of that is in question.
And sometimes the automation does reduce complexity. What it often does, however, is reveal which parts of that complexity were structural all along. The technology removes friction from the process and, in doing so, makes the underlying reality easier to see. That reality may be encouraging. It may reveal a business that is already clearer, more consistent and more scalable than its leaders realised. Or it may reveal something else.
Because if automation in business is fundamentally an amplifier rather than a corrective, the more pertinent question may not be whether the technology worked at all, but whether the business was ready for what the technology would reveal.
And if you looked closely at the processes your organisation has already automated, would you find examples of clarity being scaled, or the same bottlenecks simply being experienced more quickly?
If you enjoyed this article you can subscribe here to receive future articles.
—
0 Comments