Where to start

Business process automation what it is, examples and where to start

Business process automation (BPA) means handing a repeatable sequence of steps, usually spread across several systems and people, to software that runs it the same way every time. It rarely falls over on technology. It falls over on order: a company starts with the process that hurts most, and two years later it has a dozen workflows nobody maintains. Below: how BPA differs from RPA, BPM and AI agents, examples by department, and the selection method we use.

12 minutes read

4 numberswhat you measure on every process before choosing: runs per month, time of one run, cost of an error, people in the chain
2 implementationshow many we take at a time, which is why the queue has to be sorted rather than merely written down
90 dayshow often we review the automation register; a workflow with no runs in that window goes to a fix or to shutdown
EUR 3,500 netone week of the process workshop, 1 to 7 weeks; it ends with a sorted queue and a named owner on every entry

Short answer

What is business process automation, and where do you start?

Business process automation is software carrying a case from start to finish without a person retyping it: an event in one system (a signed deal, a new ticket, a supplier invoice) starts a workflow that moves data between systems, applies the rules and hands only the exceptions to a human. It is built on platforms such as n8n, Make, Zapier or Power Automate, or written as code against the systems' APIs.

To choose where to start, write four numbers next to every repeated task: runs per month, minutes per run, cost of a mistake and people in the chain. Runs per month times minutes per run, divided by 60, gives hours per month. Sort descending, then strike out everything that fails the gate on data quality, cost of an error and ownership.

Start with a boring process: one department, one owner, an effect visible after 30 days, and a failure that stops a report rather than a customer order. Before you build anything, check whether the process can simply be made shorter. Automating a bad process gives you the same bad result, faster and more often.

How is BPA different from RPA, BPM and AI agents?

The four terms get used as if they meant the same thing. They do not, and the difference decides what you buy. BPA connects systems through their APIs and runs the steps in between. RPA does the same job through the screen, with a software robot clicking where a person would. BPM is the discipline of mapping and managing processes, a method rather than a tool. An AI agent is a step inside a workflow that reads unstructured input and makes a bounded decision.

Is RPA better than AI? The question compares two different parts of the job. RPA is a way of reaching a system that has no API; an AI agent is a way of handling a step that has no fixed rule. Most processes need neither: a plain workflow over APIs is cheaper to build and to maintain. More on where an agent fits is in what an AI agent is.

Approach	How it works	When it fits	Where it breaks
Business process automation (BPA)	a workflow on n8n, Make, Zapier, Power Automate or in code, talking to the systems' APIs	the systems have APIs and the rule can be written down	a key system has no API, or the rule changes every month
Robotic process automation (RPA)	a software robot repeats clicks and keystrokes in the user interface	an old desktop or web system with no API that you cannot replace yet	the screen layout changes; every update can stop the robot
Business process management (BPM)	mapping, measuring and redesigning processes, sometimes with a modelling tool	before automation, to decide what the process should look like	on its own it moves no data; a map is not a workflow
AI agent	a language model reads emails, documents or tickets and picks the next step within set limits	the input is free text and a person today reads it to decide	the decision needs accountability a model cannot carry; then it proposes and a human approves

In practice the approaches are layered: BPM decides the shape of the process, BPA carries the data, an AI agent handles the one step that needs reading, and RPA stays as a last resort for a system with no API.

Business process automation examples by department

Every example below is a workflow with a start, an end and an owner, not a department-wide project. Each one reads data from one system and writes it to another, and stops for a person only on an exception.

The descriptions of individual workflows, with the systems they connect, are in our catalogue: for example invoicing from the CRM or automatic lead routing. Which of them belongs at the top of your queue is decided by the numbers in the next section, not by the list.

Department	Process	What the automation does	Exception for a person
Finance	sales invoices	a won deal in the CRM creates the invoice in the accounting system and sends it to the customer	missing tax number or a non-standard payment term
Finance	payment reminders	an overdue invoice triggers a reminder sequence and a note on the customer record	a customer disputing the invoice
Sales	lead routing	a form or an inbound email lands in the CRM, is matched to an owner by region or size, and the owner gets a task	a lead that matches no rule
Management	weekly sales report	data from the CRM and the ad accounts is pulled into one sheet or dashboard on a schedule	a source that returned no data
Operations	CRM and ERP sync	orders, customers and stock move between the two systems without double entry	a record changed in both systems at once
HR	employee onboarding	a signed contract creates accounts, access requests and a first-week checklist	a role with access outside the standard set
Customer service	ticket categorisation	an AI agent reads the ticket, sets the category and priority, and routes it	a ticket the agent cannot classify with confidence

The last column is the one to fill in first. A process where you cannot say what counts as an exception is not ready for automation yet.

How do you measure a process before you touch it?

With no measurement, the queue is set by whoever talks loudest. That is not always the wrong pick, it is just a pick nobody can check. Four numbers are enough to turn the conversation from impressions into arithmetic.

Collecting them takes an afternoon, because three of the four come straight out of a system and the cost of an error comes from the person who last cleaned that error up. How to go deeper on one chosen process is in our guide to process automation step by step.

Number	Where you get it	What it tells you when choosing
Runs per month	system log or three months of document history	at a dozen or so runs a month, maintenance eats the gain
Time of one run	a stopwatch on three cases: easy, typical, hard	times the runs, it gives hours per month, the sorting axis
Cost of an error	a conversation with whoever last fixed the consequences	a high cost does not kill a process, it moves it behind the first pilot
People in the chain	a map of handovers, not the org chart	every handover is waiting; at 4 people the elapsed time grows faster than the work time
Hours per month	runs times minutes, divided by 60	the only number that compares across departments

Time three cases, not one. A measurement taken on the easy run understates the result, because it skips hunting for the data and fixing your own mistakes.

Which processes even get into the queue?

The queue is not a list of everything that could be automated. It is the list of what passed a gate on several criteria at once. Each criterion is judged on a specific task with a start and an end, never on the name of a department.

The catalogue of ideas, meaning what companies tend to automate, sits in a separate guide: what can be automated in your business. This page is the opposite job: filtering out of that catalogue the processes that are not ready at your company yet.

Qualification criterion	Good result	Disqualifying result
Repeatability	a few times a week, always in the same order	once a quarter, or differently every time
A rule or a stable reading pattern	you can write it as „if this, then that” or point at what to look for in the document	the call is made on instinct and two people do it differently
Quality of the input data	one set of data in one system, key fields always filled in	the same customer in two versions, a key field empty in every second record
Cost of an error	the mistake shows up the same day and can be reversed	the mistake reaches a customer or a regulator and surfaces a month later
Owner	one person who reports exceptions and approves a rule change	a process belonging to „everyone”, which means to nobody
Stability of the rules	the rule has not changed in six months	the rule changes every month along with the price list or the procedure

A disqualifying result does not mean „never”, it means „not this quarter”. Ahead of such a process the queue gets a clean-up task instead, usually a week of work: fixing the data, naming an owner or writing the rule down.

What do you sort the queue by?

Sorting by hours per month is enough for a company that does not have a single working automation yet. From the second and third implementation on, processes start to affect each other: one of them tidies up the data the next one reads.

The order of criteria we apply in a workshop looks like this. How to turn those hours into money and into a payback date is covered separately in automation ROI.

Hours per month, descending: the main axis, because it is the only figure comparable across departments
Down goes any process whose data has to be cleaned first; that is a week of work, not an implementation
Down goes a process with a high cost of error, for as long as the company has no working automation at all
Up goes a process that unblocks the next ones: one tidy format that later workflows can read
Up goes a process with a working API on both sides; the lack of one turns a week of work into three
The owner decides ties: a process with a person who has time this month beats a process without one

Why should the first process be boring?

The first implementation has one job: to deliver a number you can show the rest of the company. It is not there to prove the technology is clever. Hence the choice of something dull and measurable.

The process that hurts most is usually the most tangled one: plenty of exceptions, several departments, decisions a human has to answer for. The pilot drags on for a quarter and the company concludes that this does not work here. The conclusion is false, the cost of undoing it is real.

One department and one owner, with no cross-department negotiation in the middle of the pilot
An effect visible after 30 days on a number from a system, with no team survey
A failure stops a report, not a customer order
The manual path still works, so the team has somewhere to fall back to in a bad week

When should you simplify a process instead of automating it?

Automation freezes a process in the shape it found it in. Three approvals stay three approvals, only faster. A field filled in „just in case” stays a field, except now a machine fills it.

The sentence we repeat at every workshop: automating a bad process gives you the same bad result, faster and more often. So before we quote, we look for steps to cut. Sometimes after that cut the process drops out of the queue entirely, because a quarter of an hour a week is all that is left of it. That is a good workshop outcome, not a failure.

Three approvals in a row, two of which nobody has ever rejected: keep one
Two systems holding the same information: pick the source of truth before you build a bridge between them
A field filled in because it has always been filled in: find out who reads it before you have a robot populate it
A report sent to ten people and opened by two: ask those two what they actually need
A step that exists to fix the previous step: fix the previous step

Who owns the process after go-live, and how do you avoid an automation graveyard?

A workflow with no owner runs until the first change around it: a new field in the CRM, a different file format, an expired token. Then it stops, and the team quietly goes back to doing the work by hand alongside it.

The owner is not the vendor and not the IT department. It is a person from the department where the process happens: the same one who reports exceptions and approves a change to the rule. The vendor is responsible for making the change possible, the owner for making sure somebody knows about it.

Skip both and you get an automation graveyard: a dozen workflows built by somebody who no longer works here, wired into accounts nobody knows about. The cure is a register and half a day a quarter. This is how we run it, in our founders' own companies and with clients; more on how we work is on the AI automation agency page.

Field in the register	What you write	Why
Name and purpose	one sentence: what this workflow does and for whom	a year later nobody remembers why entry number seven was built
Owner	the first and last name of a person in the department, not a team name	an exception report needs an addressee
Systems and access	what it connects to and whose account it runs on	one person leaving can switch off several workflows at once
Manual path	how to do this step without the automation	the day of an outage is a bad moment to work that out
Last review	date and verdict: working, needs a fix, to be shut down	with no date nobody notices the workflow that has been stopped since May

The register can be a Google Sheet or a page in Notion. What matters is that there is one per company and that the entry is created on the day of go-live, not on the day of the outage. The review below runs on that register every 90 days.

Pull the run history
Take the number of runs and errors for every workflow over the last 90 days out of the platform. Execution history is standard in n8n, Make and Zapier.
Three piles
Workflows with runs and no errors stay. Workflows with a repeating error go to a fix, with a date and a name on it. Workflows with zero runs go to a conversation.
Talk to the owner
Zero runs has two causes: the process disappeared, or the team stopped trusting the automation. The first ends in shutdown, the second in a fix and a reading after 30 days.
Shutting down
Switch the workflow off, revoke the access and leave an entry in the register with the date and the reason. Deleted without a trace, it comes back in six months as a question about why nobody ever did this.

Common mistakes

Five mistakes when picking and running processes

A queue ordered by who complains loudest
The first implementation lands on the most tangled process, drags on for a quarter and ends with the conclusion that automation does not work here.
Choosing with no measurement of runs and run time
After go-live it turns out the task happens 8 times a month and takes a quarter of an hour. Maintenance costs more than the workflow takes off the team.
Automating a process that should have been shortened first
Three approvals and double data entry stay exactly where they were, only faster. The bad result now appears more often and with more confidence behind it.
Four departments, four pilots at once
None of them has supervision or a reading after 30 days. Next quarter's budget disappears, because there is not a single number to show for it.
No register and no review every 90 days
After two years nobody knows which workflows run and whose access they stand on. One person leaving switches off several at once.

Checklist

Checklist before you put a process into the queue

Treat every „I do not know” as a no and leave the process one level down.

Four numbers collected: runs per month, run time, cost of an error, people in the chain
Hours per month calculated and put side by side with the other processes on the list
The process passes every criterion in the gate table, including input data quality
Checked whether it can be shortened first: approvals, double entry, dead fields
First in the queue is boring: one department, one owner, a failure does not stop sales
The owner is named in full, and knows they are the owner
The register entry is prepared, together with the manual path for the day of an outage
The review date 90 days out is already in the owner's calendar

Sources

Let us sort the queue

You leave with a sorted list, not with an idea

On a free 30-minute consultation we take the three processes you talk about most and measure them against the four numbers live. If one of them drops out, we say so on the call. The process workshop costs EUR 3,500 net per week and ends with a queue with named owners plus a 30-day plan you can execute without us. We take at most two implementations at a time.

Book a free consultation

Frequently asked questions

Which process should you automate first?

The one with the most hours per month that is also boring: one department, one owner, and a failure that stops a report rather than a customer order. Hours are runs per month times minutes per run, divided by 60. Leave the process that hurts most for the third implementation.

How many processes should you automate at once?

One, until you have a single working automation. We take at most two implementations at a time, so that every pilot has supervision and a reading after 30 days. Four departments running their own pilots end with four unfinished projects and no numbers to show.

What is business process automation?

Software running a repeatable, rule-based sequence of steps across systems and people, so that a case moves from start to finish without anyone retyping data. A typical example: a won deal in the CRM creates the invoice in the accounting system and sends it to the customer, and a person sees only the exceptions.

What do you do when a process fails the data quality gate?

It stays in the queue, but a clean-up task lands ahead of it: removing duplicates, filling in a field, picking one source system. That is usually a week of work rather than an implementation. An automation wired into two versions of the same customer will spread the error faster than anyone spots it.

Who should own an automation inside a company?

A person from the department where the process happens, named in full, not the IT department and not the vendor. The owner reports exceptions, approves rule changes and receives the outcome of the review every 90 days. Without that person the workflow stops at the first change of file format.

How often should you review automations that are already running?

Every 90 days, against the run count pulled out of the platform. A workflow with zero runs goes to a conversation with its owner and ends either in a fix or in a shutdown recorded in the register. Execution history is standard in n8n, Make and Zapier, so the review takes half a day.

Is RPA better than AI for automating processes?

Neither is better, they solve different problems. RPA reaches a system that has no API by clicking through its screens; an AI agent handles a step with no fixed rule, such as reading a free-text email. If both systems have APIs and the rule can be written down, a plain workflow without RPA or AI is the cheaper choice to build and maintain.

How much does choosing the processes cost, before you build anything?

The free consultation runs 30 minutes and is enough to put three processes through the four numbers. The process workshop costs EUR 3,500 net per week, runs from 1 to 7 weeks and ends with a sorted queue with named owners. The implementation is quoted after the workshop.