Buying business process automation: what to look for and what to avoid
Short answer: process automation programmes often stumble before the software becomes the problem. In a 2017 interview, EY’s RPA leader described 30–50% of initial projects failing and pointed to poor process selection and implementation. That is historical practitioner evidence, not a current industry-wide failure rate. It still gives buyers a useful test: ask how the provider will map the work and handle exceptions before discussing bots or models. (Interview with EY’s RPA leader)
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 business process automation services add over classical rules. Where document-heavy intake is the bottleneck, include document classification and extraction in the scope.
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
Programme growth is not a useful goal by itself. Adding bots without shared exception handling, monitoring and integration creates a collection of bespoke automations that each cost money to maintain. The next workflow then inherits none of the groundwork from the previous one, so the business has little reason to fund a larger portfolio.
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.
Compare proposals using the same evidence
Ask every business process automation provider to respond to one shared brief. Describe the current workflow, show a few representative inputs and exceptions, list the systems involved, and state what a completed case means. Ask for assumptions and exclusions alongside the price. Without the same scope, proposal totals do not compare the same work.
Then assess each proposal against the operational design. Does it explain how the system resumes after a failure? Does it include permissions, audit history, alerting and a named owner? Does it say where AI makes a decision and what happens when confidence is low? These answers reveal more than a list of automation tools or framework logos.
Request a demonstration with your own sample cases. Include the ordinary input, incomplete data, a duplicate, a low-quality scan and a case that requires approval. Ask the provider to show the full loop and the exception queue. A polished demonstration on a clean case says little about production readiness.
Build a baseline and agree on the success measure
Before work begins, record monthly case volume, handling time, rework, queue time, error types and current system costs. Define whether a completed case needs a person to verify it. Decide how you will count re-opened cases and cases that fail downstream validation.
Choose a small number of outcome measures that match the workflow. Straight-through rate describes cases finished without intervention. Exception rate by reason shows where the design still fails. Cycle time describes how long work waits. Error and rework rates show whether speed came at the expense of quality. Compare all of them with the same baseline and period.
Do not use a single accuracy percentage as the business case. A document extractor can read a field correctly while the process still routes the application to the wrong team. Measure the complete business outcome and separately inspect the fields or decisions that carry risk.
Calculate the total cost of ownership
The proposal is one part of the financial decision. Include discovery, implementation, integration, platform subscriptions, model usage, hosting, security review, human exception handling and ongoing support. Add the cost of changing upstream systems and maintaining credentials. If a vendor prices per transaction, model the expected and peak volume rather than only the pilot.
Compare those costs with the work the organization can actually remove or redeploy. Hours released do not automatically become cash savings. The business may use the time to handle more cases, reduce a queue or shift staff to other work. Name the intended outcome so finance and operations evaluate the same benefit.
Build a conservative scenario for the first year and a separate scenario for steady state. State the assumptions behind volume, review rate and maintenance effort. A range is more useful than a precise forecast built from unmeasured inputs.
Plan for access, security and ownership
Map what data the automation reads and which systems it can change. Give service accounts only the access the workflow needs. Require approvals before irreversible or regulated actions. Store secrets through the organization’s approved mechanism, and decide how access is revoked when a worker, vendor or system changes.
Agree who owns the software after launch. The handover should cover source code, deployment steps, environment settings, dashboards, alert thresholds, recovery procedures and the list of vendor dependencies. Ask the team that will operate it to review these before acceptance. Documentation that nobody can run is not an operational handover.
Set an exit path as well. Know how to export workflow data, rotate credentials, replace a connector and pause automation safely. This matters whether you buy a platform or commission a custom process automation system.
When you should not automate yet
Wait when the process changes every month, the rules are disputed, or nobody can explain what a correct result looks like. Automating disagreement makes it faster and harder to notice. Fix the policy and ownership first, then map the new process.
Also pause if the only measurable goal is “use AI” or “reduce headcount” without a clear workflow outcome. A narrow integration, a better queue or a report may solve the underlying problem for less cost. A capable provider should be willing to recommend that smaller option.
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.
Business process automation questions
What should business process automation services include?
Discovery, integration design, exception handling, access controls, testing, monitoring and operational handover. Ask the provider to show how each is covered.
How do I choose an automation provider?
Give providers the same workflow and representative exceptions. Compare their assumptions, recovery plan, ownership model and measured outcomes alongside price.
Should we buy software or build a custom workflow?
Buy when supported connectors and standard rules fit. Consider custom development when system boundaries, permissions or decision logic require control the product does not offer.
Is RPA still useful?
Yes, especially when a legacy application exposes no API. Treat interface changes as a maintenance risk and avoid using simulated clicks for decisions.
How should we measure automation success?
Track whole-case completion, exceptions by cause, cycle time, errors, rework and operating cost against a baseline from the current process.
What is straight-through processing?
It is a case completed without manual intervention. Agree what verification counts as intervention before setting a target or comparing providers.
Does business process automation need AI?
No. Use rules for known decisions and AI only where inputs require interpretation. Keep validation and authorization outside the model.
What happens when an automated workflow fails?
It should stop safely, preserve its state, alert an owner and support a controlled retry. Idempotent steps prevent repeated side effects.
What costs are easy to miss?
Integration changes, platform fees, usage, hosting, exception review, security work and maintenance often sit outside the initial implementation quote.
When should we wait before automating?
Wait when the policy is unresolved, the process changes constantly or the team cannot define a correct outcome. Stabilize ownership and rules first.
EpochC builds AI business process automation services, AI agent development services that act on your systems of record, and intelligent document processing services. See the KYC automation case study — EUR 40,000 a year of manual review removed — or start a project.