Business process automation has a reliability problem in how it gets sold. The pitch is usually a percentage - cut costs by 40 percent, save thousands of hours - without much attention to which processes actually qualify, or what happens when the automation encounters something its designers did not anticipate.

Done well, automation is genuinely transformative: it removes tedious work, eliminates a class of human error, and compresses cycle times from days to minutes. Done badly, it produces an expensive, fragile system that formalises a bad process and needs constant attention.

The difference comes down to selection and sequencing.

Fix the process before you automate it

This is the single most important principle, and the most frequently ignored. Automation amplifies whatever process you point it at. If a workflow includes three redundant approvals and a step that exists because of a system limitation resolved five years ago, automating it produces a fast, efficient, permanently enshrined bad process.

Map the process as it actually happens - not as the documentation describes it. Then ask of every step: why does this exist, what would break if we removed it, and who actually uses the output? A meaningful share of steps in most mature processes fail that test.

It is common for process simplification alone to deliver more benefit than the automation that follows, and at a fraction of the cost.

Choosing what to automate

Good candidates share a recognisable profile:

  • High volume. Automation has fixed build cost and near-zero marginal cost. A process running 500 times a month justifies effort that one running twice a month never will.
  • Rule-based. The decisions can be expressed as explicit logic. If the answer is "it depends on the situation," that dependency needs to be articulated before anything can be automated.
  • Stable. The process is not going to be redesigned next quarter. Automating a moving target means rebuilding continuously.
  • Structured inputs. Data arrives in a consistent, machine-readable form. Free-text email requests are much harder than a submitted form.
  • Currently error-prone or slow. There is a real, measurable problem to solve.

Conversely, be sceptical about processes requiring negotiation, empathy, or judgement about ambiguous situations, and about processes where the cost of a wrong decision is high and hard to reverse. Partial automation - where software handles the routine 80 percent and escalates the rest to a person with full context - is usually better than forcing complete automation.

Common high-value targets

Invoice and accounts payable processing. Extracting invoice data, matching against purchase orders, routing exceptions and scheduling payment. High volume, highly structured, and manual handling is both slow and expensive.

Employee onboarding. A single trigger can create accounts across systems, assign equipment, enrol in training, notify payroll and schedule check-ins. Manual onboarding is a checklist that gets partially completed, and the gaps surface weeks later.

Order processing. Order capture through to inventory allocation, fulfilment instruction, customer notification and invoicing. Direct revenue impact and directly visible to customers.

Report generation. Recurring reports assembled by hand from multiple systems are pure automation candidates - the logic is fixed and the effort is entirely mechanical.

Data transfer between systems. Anywhere a person exports from one system and imports into another is both a waste of time and a reliable source of errors.

Compliance evidence collection. Automated audit trails and control evidence are more complete and dramatically cheaper than assembling them retrospectively under audit pressure.

Technology options and their trade-offs

Workflow platforms handle routing, approvals and state management with configuration rather than code. Fast to deploy, accessible to non-developers, and often sufficient for approval-shaped processes. Limits appear when logic gets genuinely complex.

Integration platforms and iPaaS connect systems through pre-built connectors. Excellent when your systems are mainstream SaaS products. Less useful for bespoke or on-premise legacy systems.

Robotic process automation drives existing user interfaces the way a person would - clicking, typing, reading screens. Its real value is that it requires no API, so it can automate against systems you cannot modify. Its weakness is brittleness: a UI change, a slow-loading page or an unexpected dialog breaks the robot. Treat RPA as a bridge for systems that will be replaced, not a permanent architecture.

Custom development integrates systems directly through APIs, message queues or databases. Higher upfront cost, substantially more reliable, and the right answer for core processes you will depend on for years.

AI-assisted automation extends reach to unstructured inputs - classifying emails, extracting data from varied document formats, summarising free text. Genuinely capable now, but probabilistic rather than deterministic. It needs confidence thresholds, human review for low-confidence cases, and monitoring for drift. Do not put an unreviewed model in a path where errors are costly and invisible.

Calculating ROI honestly

Establish the baseline before you build anything. You need actual measurements, not estimates from memory:

  • Hours spent on the process per month, by role and loaded cost
  • Error rate and the cost of correcting each error
  • End-to-end cycle time
  • Downstream costs - late payment penalties, lost sales, compliance findings

Then account for total cost of the automation: build or configuration, platform licences, integration work, testing, change management and training, and ongoing maintenance. That last item is where projections most often go wrong - automation is not a one-off purchase. Systems change, APIs version, edge cases surface. Budget realistically for continuing engineering attention.

Be disciplined about which benefits you count. "We freed up 200 hours a month" is only a saving if those hours are redeployed to something valuable or headcount actually changes. Otherwise it is slack, which may be worth having but is not a financial return. Errors avoided, cycle time reduced and compliance risk removed are usually more defensible than notional labour savings.

How automation projects fail

  • Starting too big. An enterprise-wide programme before anyone has delivered a working automation. Start with one process, prove the value, build the internal capability.
  • No exception handling. Real processes have edge cases. Automation without a defined path for what happens when something does not fit will quietly fail or silently do the wrong thing.
  • No monitoring. If nobody is alerted when an automation stops working, you will find out from the downstream consequence, days later.
  • Ignoring the people affected. Staff who fear replacement will not help you map the process accurately. Be explicit about what changes and what their role becomes.
  • Treating it as finished at launch. Automations need ownership, monitoring and periodic review, indefinitely.

A sensible starting sequence

Pick one process that is high volume, painful, well understood and not business-critical. Measure it properly. Simplify it. Automate the simplified version. Instrument it so you can see it working and see it fail. Measure again against the baseline.

You will end up with a real number, a working example, and a team that has learned where the difficulties actually are. That is a much stronger position from which to expand than a strategy document.

If you want help identifying and quantifying candidates in your own operation, see our business process automation service or talk to our team.