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

Business process automation (BPA) means automating a whole process, not one task inside it. Filing an expense claim is a task. Submission, policy check, approval routing, reimbursement and the accounting entry together are a process, and automating that chain end to end is BPA. Projects fail most often because nobody can describe the process precisely.

The technology is rarely the cause. The automation encodes a version of the process that only existed in a diagram, while the real process, with its workarounds and exceptions, kept running beside it.

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

Key takeaways

• A task is one step, and a process spans steps, systems and people, so process automation attacks the waiting between steps.
• Describe the process as it is performed, by watching the work, before automating anything.
• Exceptions are most of the cost, so list them with the people who do the work and decide for each one whether to automate, route or reject.
• Measure end-to-end time, exception rate and rework rate before and after, using the same measures.
• Start with a high-volume, low-variation process that has a named owner.

Task automation and process automation

Task automation handles one step by one person or system, and process automation handles the chain of steps, systems and people, including decisions and handoffs. The distinction sets the scope of what you take on.

• A task is one step, such as copying data between two systems, sending a confirmation or 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 saves someone some time, but the process duration barely moves because the time is in the gaps.
• Automating a process attacks the gaps, where most elapsed time sits: work waiting in an inbox for someone to notice it.

Task automation is easier to start and often the right first step. The mistake is treating it as process automation and then wondering why end-to-end time is unchanged.

You cannot automate what you cannot describe

The first real obstacle to BPA is organisational: most processes exist as habit spread across the people who perform them, and nobody can describe the whole.

• Most processes are undocumented.
• Documentation, where it exists, is aspirational. It was written when the process was designed and describes how it was meant to work.
• Different people perform the process differently, especially where the documented version is impractical and everyone developed the same workaround independently.
• Nobody owns the process end to end. Each department owns its segment, and the handoffs between segments belong to nobody.

The first deliverable is therefore a description, produced by watching what happens and not by asking what should happen. The work is unglamorous, it is where the value is, and it often shows that the process can be simplified instead of automated.

The process as documented and as performed

The documented process and the performed process differ in every organisation, and the differences are informative. Four kinds of difference recur:

• Skipped steps. A check everyone bypasses is either unnecessary or a real risk, and finding out which is worth more than automating it.
• Added steps. Someone introduced a spreadsheet, a chat message or a second approval, usually to compensate for a real problem the documented process ignores.
• Decisions on unlisted information. 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 information, corrected, resubmitted) is invisible in most descriptions and is often the largest 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

Exceptions are the real work of BPA: the normal case takes most of the initial design, but exceptions take most of the cost of building and running the automation.

1. Enumerate exceptions before building. The people doing the work know them well and are rarely asked.
2. Decide for each exception: automate it, route it to a person, or reject it. "Handle it somehow" is not a decision.
3. Design the route to a person properly. An exception queue with no owner, no ageing and no visibility is where automated processes fail silently, and the failure looks like success on every dashboard.
4. Measure the exception rate. If a large share of cases fall out, the design is wrong or the process has more variation than anyone admitted. Both are worth knowing early.

Handoffs, where time is actually lost

Handoffs are where time is lost because work sits between steps, not during them. A task that takes four minutes can take days end to end, and the difference is waiting.

• Each handoff is a queue with no visibility, usually someone's inbox.
• Nobody is accountable for the gaps, because each department is accountable only for its own step.
• Automating the handoff is often the whole win, even if every step stays 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. The second is usually larger and rarely measured.

Measuring before and after

Measuring before and after decides whether anyone believes the result. Measure the current process first, using the same measures afterwards.

• Measure four things before anything changes: end-to-end elapsed time, exception rate, rework rate and cost per instance.
• Use distributions, not averages. The median case and the worst tenth behave differently, and the worst tenth is what people complain about.
• Count the instances. A process that runs forty times a month and one that runs four thousand times justify very different investments.
• Expect elapsed time to improve more than effort. Removing waiting is usually the larger effect, and the one people notice.

Where to start, and where not to

Start with a high-volume, low-variation process that has clear rules and a named owner. Invoice processing, onboarding and standard approvals fit, and their return is predictable.

• Start with an owned process. The owner can decide what should happen when the rules are ambiguous, which they always are.
• Do not start with the most broken process. It is usually broken because it is complex or politically contested, and automating it encodes the mess.
• Do not start with a process about to change. A reorganisation or system migration invalidates the work.
• Do not start with a process nobody can describe. Describe it first, then check whether simplifying it removes the need to automate it.

What happens to the people doing it now

The people who know the process are the ones asked to explain it, so their expectations decide how complete the description is. If they believe the outcome is their redundancy, the exceptions are the part they leave out.

• State the intent honestly at the start. Ambiguity produces worse information than either answer.
• Keep the exception queue staffed. The cases that fall out are the difficult ones, and they need the expertise the automation replaced on the easy ones.
• Involve the team in designing exception handling. They know which cases are hard and which only look unusual.
• Change the team's measures. Their work becomes the hard residue, and a volume metric that made sense before is misleading afterwards.

Automating a process with CodeWords

To automate a process in CodeWords, describe it in plain language to Cody, the automation builder, instead of assembling it from components. CodeWords connects to 3,000+ integrations (CodeWords integrations page, 2026).

1. Open CodeWords and start a new automation.
2. Describe the process to Cody: 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, and Cody builds it, connects it and deploys it. The Free plan covers light use. Pro costs $39 per month and Business costs $100 per month (CodeWords pricing page, 2026). Details are on the pricing page.

What to get right first

Get a written description of the process as it is performed, including the exceptions, produced by watching and not by asking. Everything else depends on it, it transfers to whichever tool you use later, and producing it often shows that the process should be simplified instead of automated.

Two habits make the difference. Ask the people who do the work what goes wrong, since they can list the exceptions and are rarely 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, and a process spans steps, systems and people. Automating tasks gives local savings while end-to-end time barely moves, because most elapsed time sits in the gaps between steps and not in the steps themselves.

Why do BPA projects fail?

They usually fail because nobody could describe the process precisely, so the automation encoded a documented version that was never performed. The failure is organisational more than technical, and a written description of the real process prevents most of it.

What should be automated first?

Start with a high-volume, low-variation process that has clear rules and a named owner. Avoid the most broken process, because it is usually broken by real complexity or disagreement, and automating it only encodes the mess.

How many exceptions should I expect?

Expect more than the first design covers. The normal case takes most of the design effort but a small share of the real work. List exceptions with the people doing the job before building, and decide what happens to each.

What is the most overlooked improvement?

Automating the handoff while leaving the steps manual. Work sits between steps, 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 and not as designed. Documenting it often shows the process can be simplified instead. Automating a process nobody can describe produces an automation nobody can maintain.

How do I prove BPA worked?

Measure end-to-end elapsed time, exception rate and rework rate before you change anything, then measure the same things afterwards. Report distributions and not averages, since the worst cases are what people 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, they will leave out the exceptions, which are the part you need most.

What happens to the team afterwards?

Usually the team moves to the exceptions and the judgement, where their expertise was always needed. Stop measuring them on volume, because 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