What is business process automation? A plain-English guide

Business process automation is getting software to carry out a repeatable business process that a person currently does by hand.

That is the whole idea. Everything else is detail about which process, which software, and how to handle the cases that do not fit the pattern.

The term sounds like it belongs to large companies with change programmes. It does not. Some of the highest-return automation work happens in businesses of ten to fifty people, because that is where one person is doing something forty times a month that a computer could do in a second.

The definition, without the jargon

A process is a sequence of steps with a trigger at the start and an outcome at the end. Something arrives, things happen to it, and it ends up somewhere.

Automation replaces the mechanical steps with software while leaving the judgement to people. Notice that framing: you are not automating a job, you are automating the typing, the filing, the copying and the chasing that sit around the decisions.

A process is a good candidate when it is:

• Repeatable. It happens the same way most of the time.
• Rule-based. You can describe what to do in each situation without saying "it depends who is dealing with it".
• Frequent. Weekly at minimum, ideally daily.
• Currently manual. A person is doing it now, so you can measure what you are removing.

A worked example

Supplier invoices, because almost every business has this one.

How it works today. An invoice arrives by email. Someone opens it, reads the supplier name, the amount and the purchase order reference. They save the PDF into a folder, with a filename that depends on who saved it. They type the figures into the finance system. They forward it to whoever approves that supplier. If no reply comes, they remember to chase, or they do not.

Call it twelve minutes of attention, spread over several interruptions. At sixty invoices a month, that is twelve hours.

How it works automated. The invoice arriving is the trigger. The document is filed in SharePoint with a consistent name. The supplier, amount, date and purchase order reference are read from it. Those figures are checked against the matching purchase order. If everything agrees and it is within the approval threshold, it goes into the finance system and the approver is notified. If something does not match, it goes to a person with the specific discrepancy attached: "supplier says 1,240, purchase order says 1,204".

The chasing happens automatically after two days, then escalates.

The person still handles the exceptions, which is the part needing a brain. What has gone is the reading, the typing, the filing and the remembering.

What automation is not

Three things people reasonably assume and should not:

It is not replacing your systems. Most automation connects things you already have. If a proposal starts with replacing your finance system, that is a systems project with automation attached, which is a much bigger commitment.

It is not the same as AI. They overlap and get marketed together. Most valuable automation is deterministic: clear rules, predictable outcome, easy to verify. AI is useful for the parts requiring interpretation, such as reading a document with an unpredictable layout or classifying an enquiry. A well-built process usually uses rules for the bulk and AI for the specific step that needs it.

It is not set and forget. Processes change. A supplier alters an invoice format, a system gets updated, a rule stops applying. Automations need an owner, and an automation that fails silently is worse than no automation.

How to spot a good first candidate

The instinct is to pick the most painful process. Usually wrong: the most painful process is often painful because it is complicated, which makes it a bad first project.

Better instinct: pick the most boring frequent one. Do this arithmetic:

Times per month × minutes each = minutes saved per month

A fifteen-minute task done forty times a month is ten hours. A two-hour task done monthly is two hours. The first is a far better candidate even though the second feels more significant.

Then sanity check:

• Could you write down the rules in a page? If not, the process needs agreeing before it needs automating.
• Does it depend on one person's judgement in a way they cannot articulate? Start elsewhere.
• How many genuine exceptions are there? A handful is normal. A third of cases being exceptions means it is not really a process yet.
• Is the data already digital? Automating something that starts as a handwritten note is a different job.

The part everyone underestimates: exceptions

This is where automation projects live or die.

Every process has cases that do not fit. The supplier who invoices differently. The order that arrives without a reference. The customer whose account is on hold. When a person runs the process they handle these without thinking, and usually without telling anyone, which is why they never appear in the documentation.

An automation that only handles the clean cases and breaks on the rest creates more work than it saves, because now someone is doing the original job plus investigating failures.

The design principle worth insisting on: the automation should be confident about what it handles and explicit about what it cannot. Anything outside the rules goes to a named person, with the reason attached and enough context to act. That way the worst case is a human doing what they did before, which is exactly where you started rather than somewhere worse.

In practice this is why watching a process being done is worth more than reading a description of it. The exceptions only show up in the doing.

Where the tools fit

For most businesses already on Microsoft 365, the tooling is already paid for. Power Automate handles the flow of triggers and actions, SharePoint holds documents, Power Apps covers the cases needing a small purpose-built screen, and Microsoft's AI services handle the interpretation steps.

This matters commercially: it means the cost of automation is mostly the design and build, not new licences. It also means what gets built stays inside your own environment rather than a third party's platform.

None of that makes the tool choice the interesting part. The interesting part is understanding the process. A well-understood process can be automated with almost anything; a poorly understood one cannot be automated with the best tools available.

How automation projects fail

Consistently, in these ways:

• Automating the wrong process. Complex, low-frequency, or one that is about to change.
• Automating a broken process. Making a bad process faster gives you the wrong answer sooner. Fix the process first, then automate it.
• Ignoring exceptions. Covered above, and the most common single cause.
• No owner. The person who commissioned it moves on and nobody notices when it stops working.
• Not telling the people affected. If someone's role is changing, they should hear it from you before they find out from a workflow. They also know the exceptions, so excluding them makes the automation worse as well as the working relationship.
• Doing everything at once. One process, working properly, builds more confidence than five half-finished ones.

Start with one dull, frequent, well-understood process. Measure what it took before. Build it, handle the exceptions properly, and give it an owner. Then pick the next one.