What is business process automation, and where does it actually fail?

Business process automation means automating a whole process rather than a task within it. Filing an expense claim is a task. Submission, policy check, approval routing, reimbursement, and the accounting entry is a process, and automating that chain end to end is what BPA describes.

The definition is not the interesting part. What is interesting is that BPA projects fail for an unusual reason: not because the technology was inadequate, but because nobody could say precisely what the process was, and the automation encoded a version of it that only existed in a diagram.

What we'll cover

• Task automation and process automation
• You cannot automate what you cannot describe
• The process as documented and as performed
• Exceptions, which are the real work
• Handoffs, where time is actually lost
• Measuring before and after
• Where to start, and where not to
• What happens to the people doing it now
• Automating a process with CodeWords
• What to get right first
• Frequently asked questions

Task automation and process automation

The distinction is worth being precise about, since it determines the scope of what you take on.

A task is one step by one person or system. Copying data between two systems, sending a confirmation, generating a document.

A process spans steps, systems, and people, with decisions and handoffs between them, and usually crosses at least two departments.

Automating tasks gives local improvements. Each one saves somebody some time and the process's overall duration barely moves, because the time is in the gaps.

Automating a process attacks the gaps, which is where most of the elapsed time lives — work waiting in an inbox for somebody to notice it.

Task automation is much easier to start and is frequently the right place to begin, provided nobody mistakes it for process automation and wonders why the end-to-end time is unchanged.

You cannot automate what you cannot describe

The first real obstacle, and it is not technical.

Most processes are undocumented, existing as habit distributed across the people who perform them.

Where documentation exists it is usually aspirational — written when the process was designed, describing how it was meant to work.

Different people perform it differently, particularly where the documented version is impractical and everybody has developed the same workaround independently.

Nobody owns it end to end. Each department owns their segment, and the handoffs between them belong to nobody, which is exactly where things go wrong.

So the first deliverable is a description, produced by watching what happens rather than by asking what should happen. That work is unglamorous, it is where the value is, and it frequently reveals that the process can be simplified rather than automated.

The process as documented and as performed

These differ in every organisation and the differences are informative.

Steps that are skipped. A check everybody bypasses is either unnecessary or a genuine risk, and finding out which is more valuable than automating it.

Steps that were added. Somebody introduced a spreadsheet, a chat message, a second approval — usually to compensate for a real problem that the documented process does not acknowledge.

Decisions made on information the process does not mention. The person routing requests uses knowledge that appears nowhere, and automating without capturing it produces worse routing than the manual version.

Rework loops. Work that goes backwards — returned for more information, corrected, resubmitted — is invisible in most descriptions and is often the largest single consumer of time.

Automate the process as performed, corrected, not as documented. The documented version has usually never been executed.

Exceptions, which are the real work

The happy path is a small share of the effort and almost all of the initial design.

Exceptions are the majority of the cost, both in building the automation and in running it.

Enumerate them before building. The people doing the work know them exhaustively and are rarely asked.

Decide for each: automate, route to a person, or reject. All three are valid, and "handle it somehow" is not a decision.

Design the route to a person properly. An exception queue with no owner, no ageing, and no visibility is where automated processes go to fail silently — and the failure looks like success in every dashboard.

Measure the exception rate. If a fifth of cases fall out, either the design is wrong or the process has more variation than anybody admitted, and both are worth knowing early.

Handoffs, where time is actually lost

The reason process automation beats task automation, stated concretely.

Work sits between steps, not during them. A task that takes four minutes often takes three days end to end, and the difference is entirely waiting.

Each handoff is a queue with no visibility, usually somebody's inbox.

Nobody is accountable for the gaps, because each department is accountable for their own step.

Automating the handoff is frequently the whole win, even if every step remains manual — the work arrives, the person is told, and the clock stops.

Measure the gaps specifically. Time in each step and time between steps are different numbers, and the second is usually larger and never measured.

Measuring before and after

The discipline that determines whether anybody believes the result.

Measure the current process first. End-to-end elapsed time, exception rate, rework rate, and cost per instance, before anything changes.

Distribution, not average. The median case and the worst decile behave differently, and the worst decile is what people complain about.

Count the instances, since a process running forty times a month and one running four thousand justify very different investments.

Use the same measure afterwards, which sounds obvious and is frequently not done, leaving the improvement as an assertion.

Expect elapsed time to improve more than effort. Removing waiting is usually the larger effect, and it is the one people notice.

Where to start, and where not to

High volume, low variation, clear rules. Invoice processing, onboarding, standard approvals — these are where automation works and where the return is predictable.

A process with an owner. Someone who can decide what should happen when the rules are ambiguous, because they always are.

Not the most broken process. The instinct is to attack the worst one, which is usually broken because it is genuinely complex or politically contested. Automating it encodes the mess.

Not a process about to change. A reorganisation or a system migration will invalidate the work.

Not a process nobody can describe. Describe it first — and having described it, check whether simplifying it removes the need to automate it at all.

What happens to the people doing it now

Worth addressing directly, because it determines whether anybody cooperates with the description work above.

The people who know the process are the ones being asked to explain it. If they believe the outcome is their redundancy, the description you get will be incomplete, and the exceptions will be the part they leave out.

Say what the intent is, honestly, at the start. Ambiguity produces worse information than either answer.

Most processes absorb the freed capacity rather than shedding it. The queue was usually longer than the team could clear, and automation moves it to the exceptions and the judgement rather than eliminating the role.

The exception queue needs the same people. The cases that fall out are the difficult ones, and they require the expertise the automation replaced on the easy ones.

Involve them in designing the exception handling, since they know which cases are genuinely hard and which merely look unusual.

Do not measure the team on volume afterwards. Their work is now the hard residue, and a volume metric that made sense before is actively misleading after.

Automating a process with CodeWords

CodeWords connects to more than 3,000 integrations, and a process is described in plain language rather than assembled from components.

1. Open CodeWords and start a new automation.
2. Describe the process to Cody, the automation builder: the steps in order, what each needs, where a person decides, and what the handoffs are.
3. Describe the exceptions explicitly, including what should happen to each one.
4. Connect the systems each step touches, once, and reuse the connections.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

What to get right first

A written description of the process as it is actually performed, including the exceptions, produced by watching rather than asking. It is the artefact everything else depends on, it transfers regardless of which tool you eventually use, and producing it frequently reveals that the process should be simplified rather than automated.

Two habits make the difference. Ask the people who do the work what goes wrong, since they can list the exceptions exhaustively and are almost never asked. And measure the current end-to-end time before changing anything, because without that number the improvement is an assertion nobody can check.

Frequently asked questions

How is BPA different from task automation?

A task is one step; a process spans steps, systems, and people. Automating tasks gives local savings while end-to-end time barely moves, because most of the elapsed time is in the gaps between steps rather than in the steps.

Why do BPA projects fail?

Usually because nobody could describe the process precisely, so the automation encoded a documented version that was never actually performed. The failure is organisational rather than technical.

What should be automated first?

Something high volume, low variation, with clear rules and a named owner. Not the most broken process — that one is usually broken because it is genuinely complex or contested, and automating it encodes the mess.

How many exceptions should I expect?

More than the initial design accounts for. The happy path is most of the design effort and a small share of the real work. Enumerate exceptions with the people doing the job before building, and decide explicitly what happens to each.

What is the most overlooked improvement?

Automating the handoff while leaving the steps manual. Work sits between steps rather than during them, so telling the next person immediately often removes most of the elapsed time without automating any actual work.

Do I need to document the process first?

Yes, as performed rather than as designed — and the act of doing it frequently shows the process can be simplified instead. Automating a process nobody can describe produces an automation nobody can maintain.

How do I prove it worked?

Measure end-to-end elapsed time, exception rate, and rework rate before you change anything, then measure the same things afterwards. Report distributions rather than averages, since the worst cases are what people actually complain about.

How do I get an accurate description of the process?

Be honest about the intent first. The people who know the process best are the ones explaining it, and if they think the outcome is their redundancy, the exceptions are what gets left out — which is the part you most need.

What happens to the team afterwards?

Usually they move to the exceptions and the judgement, which is where their expertise was always needed. Do not keep measuring them on volume, though: their remaining work is the difficult residue and a throughput metric will read as a decline.

Related reading

• Robotic process automation
• Process mining
• Intelligent automation