TL;DR
- The leading causes of failure are organisational, not technical. Weak change management affects 35% of projects, insufficient training 31%, choosing the wrong processes 28%, and optimistic timelines 24% (2025 industry compilation).
- McKinsey has reported that 30% to 50% of automation initiatives do not deliver expected results.
- The documented process is not the real process. Post-mortems repeatedly find that everyone agreed on what the workflow looked like, while the version that runs daily is full of workarounds and judgement calls nobody wrote down.
- A readiness test you can apply today: if you cannot describe the process in under ten steps without saying "it depends", it is not ready to automate.
- Most teams pick the process they find most annoying. The right selection is volume multiplied by time multiplied by error rate, which frequently points somewhere duller.
This guide covers which process to automate. Which platform to build it on is a separate decision, and our comparison of n8n vs Zapier vs Make covers that one.
What is business process automation?
Business process automation is the use of software to run a repeatable business process from start to finish with little or no human intervention. A person defines the steps once, and software performs them every time the trigger occurs.
Three plain-English terms:
- A process is a sequence of steps that produces a result. Taking an order, onboarding an employee, approving an invoice.
- A trigger is the event that starts it. A form submission, an email arriving, a date passing.
- An integration is a connection between two systems so information can move without a person copying it.
What it is not. It is not artificial intelligence, though the two get sold together. Automation follows steps you wrote. AI makes judgement calls. If your process has a fixed sequence, you want automation, and paying for intelligence you cannot use is a common and expensive mistake. That distinction is set out in AI agents for business.
What can actually be automated?
Work that is repeatable, rule-based and high volume. The test is whether you can write the rule down without hedging.
| Well suited | Poorly suited | |
|---|---|---|
| Sales | Routing leads, updating the CRM, sending follow-up sequences | Deciding which deals to prioritise |
| Finance | Extracting invoice data, chasing approvals, reconciling records | Judging whether an unusual expense is legitimate |
| HR | Onboarding checklists, document generation, leave requests | Assessing a candidate |
| Operations | Order processing, inventory alerts, status updates between systems | Handling a genuinely novel exception |
| Support | Ticket routing, acknowledgements, escalation timers | Resolving an angry customer |
The pattern in the right-hand column is judgement. Where a step currently gets resolved by someone experienced deciding, automation either forces a crude default or stops. Neither is what you wanted.
63% of organisations rely on an external partner to implement robotic process automation, reflecting a widespread shortage of in-house specialist skills (2025 industry compilation)
Why do most automation projects disappoint?
Because the causes are organisational and the solutions on offer are technical. This is the finding that should reorganise how you plan a programme.
A 2025 compilation of business process automation statistics ranks the reasons implementations fall short:
| Cause | Share of projects affected |
|---|---|
| Weak change management | 35% |
| Insufficient training | 31% |
| Choosing the wrong processes to automate | 28% |
| Overly optimistic timelines | 24% |
Three of the four have nothing to do with software. McKinsey has separately reported that 30% to 50% of automation initiatives do not deliver expected results.
Now hold that next to what the entire vendor market sells. Every guide on this SERP is organised around capabilities, integrations and pricing tiers. None of those addresses change management, training or process selection.
The second failure pattern is subtler and more expensive. Writing on automation post-mortems describes a recurring finding: everyone agreed on what the process looked like. The documented version is the happy path. The version that runs daily contains workarounds, informal judgement calls and exception handling that nobody recorded, because the people doing it stopped noticing years ago.
Automation codifies whatever you hand it. Hand it the documented process and you automate a fiction, then spend the next year discovering the difference one exception at a time.
Which process should you automate first?
Not the one that annoys you most. That is the default selection method and it is wrong often enough to matter.
The process that irritates people is usually the one with visible friction, which is not the same as the one with the highest return. A weekly report that takes an hour and everyone complains about costs 52 hours a year. An invoice check that takes four minutes and nobody mentions, running 2,000 times a month, costs 1,600 hours a year.
The scoring method
Score each candidate process on four numbers you can gather in a morning.
| How to get it | |
|---|---|
| Volume | How many times per month does this run? Count it, do not estimate |
| Time | How long does one instance take, end to end? Time it three times |
| Error rate | How often is it done wrong, and how do you find out? |
| Loaded cost per hour | Salary plus employer costs plus overhead, not salary |
Annual cost = volume × 12 × time in hours × loaded cost per hour
Worked example: two candidates
Illustrative figures. Substitute your own.
| Weekly report | Invoice check | |
|---|---|---|
| Runs per month | 4 | 2,000 |
| Minutes each | 60 | 4 |
| Hours per year | 48 | 1,600 |
| Loaded cost at $35/hour | $1,680 | $56,000 |
| Error rate | Low | 3% |
| How often anyone complains | Constantly | Never |
The invoice check is worth 33 times more and nobody was asking for it. That gap between what is annoying and what is expensive is the single most useful thing in this article, and it takes a morning of counting to find.
Then apply one filter. Of your top-scoring candidates, automate the one that also passes the readiness test in the next section. A high-value process that is not ready will fail, and failing first destroys the appetite for the programme.
Is your process ready to be automated?
Apply this test: if you cannot describe the process in under ten steps without saying "it depends", it is not ready.
That single sentence filters out most doomed projects. Here is what it is detecting.
Undefined decision points. Any step currently resolved by "it depends" is a rule nobody has written. Automate it and the workflow either forces a default that is sometimes wrong, or halts and waits for a human, which was the thing you were removing.
Inconsistent execution. If three people run the process three ways, there is no process to automate. There are three processes, and you must choose one before building anything.
Single points of knowledge. If one person knows how a step works and it has never been written down, that step is not automatable until it is. It is also a risk you had regardless.
Frequent exceptions. A process where a fifth of cases go off the main path is not a process with exceptions. It is several processes wearing a trench coat, and it needs splitting before it needs automating.
What to do when the test fails. Fix the process first. Reported experience suggests organisations that redesign before automating reach positive returns considerably sooner than those that automate first and repair afterwards, and that re-architecting a badly automated process costs several times the original build. Treat those figures as directional rather than precise, but the direction is consistent across every source.
A broken process running automatically is a broken process running faster, at scale, with fewer people watching it.
How do you map the process that actually exists?
Six steps, about a week of part-time effort, and it is the highest-return week in the whole programme.
Step 1. Watch it happen, do not ask about it
Sit with the person doing the work and observe three complete instances. Do not ask them to describe it. Descriptions produce the documented version; observation produces the real one.
Step 2. Record every step, including the undignified ones
The spreadsheet somebody keeps on the side. The message they send to check something. The folder they look in. These are the steps that break automations, and they never appear in a process document.
Step 3. Mark every decision point
Anywhere the person chooses rather than follows. For each one, write the rule they are actually using. If they cannot articulate it, that is your finding.
Step 4. Count the exceptions
Over one month, how many instances went off the main path, and why? If it is above roughly one in five, split the process before continuing.
Step 5. Ask who owns it
Multi-department processes force an ownership decision most organisations have avoided. Settle it now, in writing, because an automation with no owner degrades quietly.
Step 6. Redesign, then automate
Remove steps that exist only because someone once asked. Turn "it depends" into written rules. Then, and only then, choose a tool.
Do not skip step 1. Everything expensive in this article follows from mapping the process people describe rather than the one they perform.
What does business process automation cost?
Three layers, and the software is the smallest.
| Typical cost | Notes | |
|---|---|---|
| Platform | €20 to €50 a month at small scale, more with volume | Covered in our n8n vs Zapier comparison, where the billing units differ enough to change the answer. If you are considering running it yourself, self-hosting n8n prices the hours as well as the server |
| Build | A few hours to a few weeks per workflow | Depends on integrations, not on step count |
| Mapping and redesign | About a week per process, internal time | The step most often skipped and the one the failure data points at |
| Maintenance | Ongoing | Automations break when the systems they connect change |
| Do it in-house | Hire a partner | |
|---|---|---|
| Cost shape | Internal hours | Fee plus internal hours |
| Speed | Slower at first, faster later | Faster at first |
| Who knows how it works | You | Depends entirely on handover terms |
| Suits | Teams with a technical owner and time | Teams without either |
| Evidence | 63% of organisations rely on an external partner for RPA implementation | |
| Where hiring a partner is the weaker choice | Here, if your first candidate process is small and well understood. A single well-defined workflow is a genuinely good in-house first project, it builds the internal skill you will need anyway, and paying an agency to automate one form submission is not a good use of a budget |
That last cell applies to work Euracle sells. It is still the right answer for a small first workflow.
How do you measure whether it worked?
Against the numbers you gathered in section four, which is why you gathered them before building.
Three metrics, reported monthly to the same person:
- Cost per instance. Volume times time times loaded rate, recalculated. This is the headline.
- Cycle time. How long one instance now takes end to end. Frequently worth more than the cost saving.
- Error rate. Tracked in both directions. An automation that halves cost and doubles errors has not succeeded.
And one that most teams miss: exception volume. How many instances still need a human? If that number is not falling, the automation is handling the easy cases and leaving the hard ones, which may still be worthwhile but is not what was promised.
Without the baseline from section four, none of this is measurable. That is the same failure that produces the disappointing-results statistics: not that nothing improved, but that nobody can prove it did.
What do most teams get wrong?
Automating the annoying process instead of the expensive one. The scoring method in section four takes a morning and routinely changes the answer.
Automating the documented process. It is the happy path. The real one has workarounds nobody mentioned because they stopped noticing.
Treating change management as optional. It is the single largest reported cause of failure at 35%, and it is a scheduling and communication problem rather than a technical one.
Skipping training. Second largest at 31%. People route around systems they do not understand, and the workaround becomes the new undocumented process.
Automating in silos. Finance uses one tool, HR another, IT a third. When a process crosses departments, people become the integration layer, which defeats the purpose and hides the true cost.
No named owner. Automations break when connected systems change. Without an owner, the first signal is a customer or a missed month-end.
Who pays for this: almost always the operations lead who sponsored it, because the failure surfaces as an unexplained problem rather than an outage. Agree the baseline, the owner and the training plan before anything is built.
How does Euracle run automation programmes?
The first deliverable is a map and a score, not a workflow.
The Eureka Method, Euracle's discovery sprint, runs four phases.
Discover observes the process being performed rather than asking about it, then scores every candidate on volume, time, error rate and loaded cost so the selection is arithmetic rather than instinct.
Design applies the readiness test, redesigns where the process fails it, and names the owner before any tool is chosen.
Deploy builds the smallest useful version on whichever platform the arithmetic supports, then runs it alongside the existing process before switching over.
Scale reports cost per instance, cycle time, error rate and exception volume monthly against the original baseline.
The stack is deliberately conventional: n8n, Zapier or Make for the deterministic sequences, connected to whatever already exists such as HubSpot or Salesforce, with the Claude API only on steps that genuinely need judgement. Keeping those layers separate is a cost decision as much as an architectural one.
Two structural commitments come from how Euracle is set up. Senior practitioners only: the people in the pitch do the work, which matters most in the observation week where inexperience produces a description instead of a map. And one contract across six disciplines, so a finding that the real answer is a process change and a hiring decision rather than an automation does not require a second vendor to act on.
If you want the processes scored before anyone builds anything, that is Euracle's workflow automation service. The silo problem is sharpest in ecommerce operations, where order, inventory and fulfilment processes cross three systems and nobody owns the whole path.
FAQ
Conclusion
You can now do the two things that separate automation programmes that work from the 30% to 50% that disappoint. Score your candidate processes on volume, time, error rate and loaded cost, because the expensive process and the annoying process are usually different ones. Then apply the ten-step test, and if the process fails it, fix the process before writing a single workflow. Watch the work being done rather than asking about it, name an owner, and keep the baseline so you can prove what changed. The tool matters far less than either of those. If you want the processes scored and mapped before anyone builds anything, talk to Euracle about workflow automation.
Sources
- 2am.tech, Business Process Automation Statistics, Facts & Trends, compilation published December 2025. Failure causes at 35%, 31%, 28% and 24%; the 63% external-partner figure; market sizing.
- McKinsey, reporting that 30% to 50% of automation initiatives do not deliver expected results.
- Business analysis writing on automation post-mortems, June 2026, on the gap between the documented process and the operating one.
- The ten-step readiness heuristic and the redesign-first timing comparison, from 2026 practitioner writing.
