Buying Business Process Automation: A Guide

Short answer: the technology is rarely why these programmes fail. Ernst & Young put initial RPA project failure at 30–50%, more than half of programmes never grow beyond ten bots, and over 70% plateau below fifty. The common cause is automating a process nobody mapped properly, then discovering the exceptions in production.

Business process automation services span everything from a two-week integration to a multi-year transformation programme, and the label tells you almost nothing about which you are buying. Here is how to tell them apart.

What is actually in scope

A credible engagement covers five things. If a proposal is missing two of them, that is the conversation to have.

Process discovery. Mapping what actually happens, not what the process document says. These diverge, always, and the gap is where the exceptions live. Skipping this is the single most reliable predictor of failure.

Integration. Connecting systems of record. This is where the schedule goes, and where estimates are most often wrong, because the constraints are discovered rather than specified.

The interpretation layer. The steps that need judgement — reading the attachment, deciding whether two records match, noticing something unusual. This is what AI process automation adds over classical rules.

The exception path. Who sees what fails, with what context, and how their resolution feeds back. Treated as an afterthought in most proposals and it is the thing that decides adoption.

Operations. Monitoring, audit trails, ownership after go-live. An unowned automation degrades quietly.

Why programmes plateau

The failure statistics are worth sitting with. Over 50% of RPA programmes never exceed ten bots. That is not a technology ceiling — it is what happens when each automation is a bespoke artefact with no shared exception handling, no shared monitoring and no shared integration layer. The eleventh costs as much as the first, so the business stops funding them.

Programmes that scale build the platform first: one place exceptions surface, one audit trail, one integration layer, one deployment path. Then individual automations get cheap. Programmes that plateau build automations first and never get to the platform.

The second cause is scope selection. Teams pick the process with the most visible pain, which is usually the most complex and least documented one. The right first project is a high-volume, well-understood, exception-tolerant loop — boring, and it proves the platform.

RPA, BPA and where AI fits

The vocabulary is used loosely and the distinctions are real.

	What it does	Breaks when
RPA	Scripts the clicks a human would make	The screen changes
Classical BPA	Integrates at the API or data layer	Judgement is required
AI-enabled	Adds interpretation to the loop	Nobody handles uncertainty

RPA takes unfair criticism. It is frequently the only way into a legacy system with no API, and dismissing it leaves you with no route in. The mistake is putting judgement inside it — let the model decide and let RPA execute, so a changed screen costs you a selector rather than a decision engine.

The genuine shift AI brought is not speed. It is that loops which were never candidates — because they required reading something or making a call — become candidates. That changes which processes are worth automating rather than making existing ones faster.

It also changes the failure mode, and this is the part to internalise before signing anything: rules fail loudly, models fail plausibly. A rules engine that breaks throws an error. A model that is wrong produces a confident, well-formatted, incorrect result that flows downstream unnoticed. Confidence scoring and explicit escalation are the mechanism that makes model-based automation safe — not optional extras, and their absence from a proposal is a red flag.

How to evaluate a provider

Five questions that separate serious providers from resellers:

“Walk me through your exception handling.” A vague answer means they have not built many of these. Ask to see an exception interface.
“What is your straight-through rate on a comparable project, and how do you define it?” Field accuracy is the wrong metric. Documents or cases completing the whole loop untouched is the right one.
“What happens when the model is unsure?” If the answer does not involve calibrated confidence thresholds, they are shipping a rules engine with an LLM attached.
“Who owns this in a year?” Handover, documentation, and whether your team can modify it.
“What did you learn on the last one that went badly?” Anyone with real delivery history has one. No answer means no history, or no candour.

Scoping one that survives

Map before you build. Time a sample of real cases end to end. Not the documented process — the actual one.
Pick a boring first loop. High volume, well understood, tolerant of escalation.
Automate the whole loop. Automating one step moves the bottleneck rather than removing it. Count remaining human touchpoints; more than one means a partial win at full price.
Build the platform on the first project. Shared exceptions, shared audit, shared integration. Absorb that cost once.
Instrument from the first commit. Straight-through rate, exception volume by cause, escalation latency. Retrofitting is harder because the data was never captured.
Measure for a month before the second project. Under schedule pressure this gets cut, and the second automation then inherits mistakes nobody has noticed.

The takeaway

Buy discovery and exception design, not bot counts. The programmes that scale invest in a shared platform on the first project and pick a dull, well-understood process to prove it. The ones that plateau automate the most painful thing first and rebuild the plumbing every time.

Sources

EpochC builds AI workflow and business process automation, AI agents that act on your systems of record, and document processing. See the KYC automation case study — EUR 40,000 a year of manual review removed — or start a project.

Buying business process automation: what to look for and what to avoid