Why most AI projects fail — and how we approach it differently

The statistic that gets quoted most often is that somewhere between 70–85% of AI and automation projects fail to deliver their intended value. The range varies depending on who you ask and how you define failure, but the direction is consistent: most initiatives that start with a business case do not end with one.

The reasons are not mysterious. They come up in the same patterns, across organisations of all sizes. Understanding them is useful whether you are running a 5-person business or a 500-person one.

What makes this particularly relevant to small businesses is that the failure modes compound. A tool chosen without a problem definition gets implemented without input from the right people, which means there is nothing useful to measure, which means nobody notices when it is not working, until eventually it gets quietly abandoned. The chain is predictable, and it is avoidable.

Reason 1: The solution was chosen before the problem was understood

The most common failure mode is starting with a tool or technology and working backwards to find a use case. "We should be using AI" is not a business requirement. It is a solution looking for a problem.

When the problem is defined first, specifically in terms of time lost, errors made, or revenue missed, the solution often turns out to be simpler than expected. Sometimes it is a three-step automation, not an AI model. Sometimes the right answer is a better-configured spreadsheet. The goal is the result, not the technology. Every recommendation we make starts from a documented problem, not a preferred tool.

Reason 2: The people doing the work were not involved

Automations built without input from the people who do the work tend to fail. Not because the logic is wrong, but because they do not match how the work actually happens. Processes on paper rarely match processes in practice. The person answering the phone has six workarounds that no one has documented. The process that looks clean in a flowchart has three exceptions that get handled differently on certain days of the week.

The workflow session we run at the start of every audit is specifically designed to surface this. We observe and ask, rather than assume. The findings from those sessions consistently differ from what the business owner expected, not because owners do not know their business, but because the granular daily reality of how work gets done is often invisible to anyone not doing it themselves. Capturing that reality is the most valuable part of the audit process.

Reason 3: There was no measurement in place

If you do not know what the process costs now, you cannot know whether the automation improved it. Many implementations are declared successful because they work technically: the data moves, the emails send, without anyone checking whether the underlying problem got better.

We agree on measurable outcomes before any retainer starts. Time saved per week. Error rate. Process completion rate. These get reviewed monthly. If the numbers are not moving in the right direction, something changes. The measurement is not a formality. It is the mechanism that keeps the work honest.

Reason 4: It was too complex

The bigger the automation, the more things that can break. A seven-step workflow connecting six tools has many more failure points than a two-step integration between two. In practice, the highest-return automations are almost always simple ones done well: reliable, maintainable, and not dependent on a specific person to keep them running.

We prioritise by impact per unit of complexity. A small automation that runs reliably for two years is worth considerably more than an ambitious one that needs constant attention or breaks whenever a connected tool updates its interface. Simple and reliable beats sophisticated and fragile every time.

Reason 5: There was no handover

Automations that live only in the head of the person who built them are fragile. If that person leaves, or is unavailable, the business loses the automation. A good implementation ends with documentation, a walkthrough, and the client able to make basic adjustments themselves.

We do not consider an implementation complete until the client understands what they have and can operate it independently. The retainer covers ongoing support, not ongoing dependency. A client who needs us to be available every time something changes has not been well served by the implementation.

Reason 6: The expectation was not set correctly

Many automation projects appear to fail not because the automation did not work, but because the person who commissioned it expected something different from what was built. An email automation that handles 95% of cases correctly and requires a manual review for the remaining 5% is a good automation. If the expectation was full hands-off operation, it will be perceived as a failure regardless of how much time it saves.

Setting clear, realistic expectations before implementation starts is part of our audit process. We do not promise that automation removes all human involvement. We promise it removes the right human involvement: the parts that are repetitive, low-value, and consistent enough to handle without judgement. The parts that require genuine human decision-making stay with the person who has that judgement, and that is how it should be.

What good implementation looks like

The common thread across successful implementations is that they are grounded in a specific, documented problem, built with the people who do the work, measured against agreed outcomes, kept as simple as the problem allows, and handed over in a way that the client owns. None of that is technically demanding. Most of it is discipline applied consistently.

The audit is where that discipline starts. Before any implementation decision is made, we want to know exactly what the problem is, what it is costing, and whether the available tools are genuinely the right answer. If they are not, we say so. If they are, we have everything we need to build something that will actually work.