Skip to main content
Data & AI

Your business process is not ready for AI automation. Here’s how to change that.

AI can handle complex business processes end-to-end. Most organisations know this by now. What they underestimate is how well they actually know their own processes before automation begins. After thirteen years of operating in the AI field, we have seen the same pattern play out across industries: organisations that struggle with automation almost always struggle with process clarity first.


Gartner predicts that more than 40% of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. RAND Corporation research puts the broader AI project failure rate even higher, with some estimates exceeding 80%. The common thread in these failures is organisations automating processes they do not fully understand.

Why do most automation projects fail before they start?

Every organisation that comes to us with an automation project brings documentation. Process flows, procedure manuals, compliance checklists. On paper, the process exists. In practice, it is rarely what people actually do.

Employees develop their own methods over time. Rules nobody wrote down. Exceptions managed differently depending on who is handling the case.

"Every automation project surfaces the same surprise: the process on paper is not the process people actually run."

The gap between what is documented and what actually happens is almost always larger than expected. And that gap is where automation projects go to die.

How do you uncover how your process actually works?

Before automating anything, you need to extract the real process from the people who run it. There are three methods that consistently work.

Shadow work sessions. Sit with your operators for half a day. Watch them create three actual shipments, process three actual claims, handle three actual requests. Ask "why" at every step, including the steps that seem obvious. The obvious steps are where the undocumented rules live.

The "explain it to a five-year-old" method. Ask each person involved to walk through their process as if teaching someone who knows nothing. This forces them to surface every decision, every exception, every shortcut they have internalised. What they skip or struggle to explain is exactly what your documentation is missing.

Cross-check documented versus actual. Take your existing process documentation and test it against what you observed. Where the document says one thing and the operator does another, you have found an undocumented rule. Collect all of them before you write a single line of automation logic.

If you cannot write your process down completely and accurately after this exercise, you are not ready to automate it. Automating an incomplete process does not save time. It scales the problem.

What does process ambiguity actually cost in AI automation?

"The ambiguity in your own process will be repriced in tokens."

Every token consumed by your AI model is a cost, both financial and environmental. The more a system has to reason through unclear rules or undocumented exceptions, the more it retries, the more human handovers it triggers, and the higher the invoice.

Think of it this way: a well-documented, deterministic process can often be handled by a simple function or a small language model at near-zero token cost. An ambiguous process requires a powerful LLM to interpret, reason, and guess its way through every edge case. The difference in cost between the two can be orders of magnitude.

Process quality is only part of the equation. The model you choose has a direct impact on cost and energy consumption. Using a large language model for a task that could be solved with a simple script or a small model is like hiring a strategy consultant to sort your mail. It works, but the economics make no sense.

The organisations that control their automation costs are not the ones with the biggest AI budgets. They are the ones with the cleanest process documentation.

Why do off-the-shelf AI tools fall short for complex processes?

Choosing the wrong tool for your process is as costly as having an unclear one. Off-the-shelf AI products are built for general problems. When your process has specific rules, compliance requirements, and exceptions built up over years, they quickly reach their limits.

An import shipment from country A to country B looks simple on paper: create an import file for shipping. In reality, there can be hundreds of undocumented rules sitting in operators' heads. Custom rules, country-specific regulations, product type requirements, all varying by combination and context. No general-purpose tool can absorb that complexity without significant customisation.

Automating a complex process requires a level of control that general-purpose tools were not built for. The same input must produce the same output every time. Every decision needs to be traceable and auditable. When business rules change, the system needs to follow. This is what separates a production-grade automation system from a clever demo.

This level of control typically requires a multi-layered architecture: a catalogue of business rules for specific procedures, a semantic layer that optimises how the system queries its knowledge base, and a structured ontology that captures all the relationships between your organisational concepts. Off-the-shelf tools were not built for the complexity of your specific process, and this requires custom engineering to get right.

Building this architecture around your specific process is what we do. Explore enterprise architecture.

Is your business ready for AI automation? A readiness checklist

The answer depends on three things.

Process clarity. Can you document every step, every decision, and every exception in your process completely and accurately? If not, start there. The documentation exercise itself will reveal complexity you did not know existed.

Knowledge extraction. Is the knowledge needed to run your process captured in systems, or does it live in people's heads? If key operators left tomorrow, could someone else run the process from documentation alone?

Tool fit. Are you choosing tools based on your process requirements, or are you fitting your process to whatever tool is available? The right architecture depends on your specific rules, compliance needs, and exception handling, not on what a vendor demo showed you.

If the answer to any of these is unclear, that is where to start. The organisations that get this right do not just automate faster. They automate at lower cost, with fewer failures, and with systems that remain governable as the business evolves.

Automation reshapes how your organisation operates. See how we guide transformation and delivery.

If you are exploring process automation and want to understand where your business stands, explore our AI and data expertise.

By Kevin Françoisse