Senthil Info

automating business processes, honestly

The Technology Is Rarely It

Every failed automation project has a post-mortem, and a striking share of them name the platform. The tool was too rigid, the vendor oversold it, the licences cost more than expected.

The evidence points somewhere less satisfying: successful and failed projects largely use the same tools. What separates them is organisational and it is cheap. A product-side example of how workforce software approaches this topic is available in this overview.

What the sources say

Gartner's account of the successful minority in AI infrastructure projects names two factors: integrating the automation into existing workflows rather than bolting it on as a parallel process, and securing full executive support before and during the rollout rather than only at launch. For broader background and an independent point of comparison, see Zapier.

Neither is a technology choice. Gartner's own summary is blunt about it — neither factor requires a different vendor.

On the failure side, the dominant root cause reported was misaligned expectations: leadership assumed the technology would immediately automate complex tasks or produce cost reductions on a timeline it was never going to meet.

Deloitte's 2025 figure points the same way: 37% of RPA failures attributed to inadequate change management.

Note who is saying this. Gartner sells research to buyers, not tools. Deloitte sells implementation services and could plausibly blame products instead. Both name organisational causes.

Why the technology gets blamed

Not stupidity — three structural reasons.

It is the only variable anyone chose deliberately. The process, the exception rate and the executive attention were inherited. The platform was selected in a meeting with a decision document, so it feels like the decision that could have gone differently.

It is nobody's fault internally. "The tool was inflexible" implicates a vendor. "We automated a process nobody owned" implicates the room.

And it suggests a remedy. Change the platform and try again — which is actionable, budgetable, and reproduces the failure with different licences.

What actually goes wrong, in order

From the pattern across sources rather than from any single study.

The wrong process was chosen. Judgement work with a clerical wrapper, or a process with a 30% exception rate. Decided before any tool was involved.

Nobody owned it. Three departments touched the process, none was accountable, and the project stalled on decisions nobody could make.

Expectations were set by a demo. A clean path, curated data, no exceptions. Then production arrives.

Change management was assumed. The people doing the work were told after the design was fixed, and their knowledge of the exceptions — the most valuable input available — was never collected.

And maintenance was not budgeted. The cost arrives in year two, by which point the project is closed and the sponsor has moved on.

What follows

Spend the effort before selection, not after. Mapping the process and measuring the exception rate costs a week and predicts the outcome better than any platform comparison.

Get one owner. Not a steering committee — a person who can decide.

Ask the people who do the work what breaks. They know the exception list, and it is usually longer than the process documentation says.

And treat platform selection as the smaller decision. It matters, it is not where the outcome is determined, and treating it as the main event is itself a symptom.

The uncomfortable part

If the technology is rarely the problem, then changing vendors after a failure is usually treating the visible symptom.

That is an expensive conclusion to reach, because the alternative — the process was wrong, ownership was absent, expectations were never managed — implicates decisions rather than purchases. It is also the one the evidence supports, from sources with no reason to say it.

The short version