Business process automation: what to automate first, and what to leave for later

What is business process automation?

Somewhere in your business, someone copies the same details from one screen to another many times a day. An order comes in by email and gets typed into the job system. A job closes and someone builds the invoice by hand. A new client signs, and three people set up the same account in three different tools. Business process automation is software taking over those steps, so the details move on their own and people spend their time on the parts that need a person.

IBM describes business process automation as using software to automate complex, repetitive processes, and it sets out several types, among them:

• Task automation: one manual step handed to software, such as sending a confirmation when a form comes in.
• Workflow automation: a defined series of steps run in order across people and systems: the order arrives, the job is created, the customer is told and the dispatcher gets a task.
• Process automation: a whole process automated end to end, both its separate tasks and the workflows that connect them.
• Intelligent automation: task automation, process automation and RPA combined with AI, for steps that call for reading text or making predictions, such as pulling the details out of an email or a scanned form.

Robotic process automation, or RPA, is a narrower kind: software that mimics what a person does in an application, such as entering data or moving it from one application to another. IBM notes that low-code tools can reach an application through its API instead, without imitating a person at the screen.

Workflow automation software is the tooling for the middle level. Microsoft describes Power Automate, for example, as a way to build automated workflows between apps and services, to sync files, get notifications and collect data (Microsoft Learn, September 2026). Business process automation software is the wider category: it runs from connector tools like that, through platforms that model a whole process with its approvals and hand-offs, to software made for one business.

Which business processes are worth automating?

IBM’s guide names four signs of a good candidate: high volume, repetitive tasks, time pressure, and several people involved in getting it done. Its examples include email notifications, helpdesk support, data migration, payroll and invoicing, and its advice is to aim at manual work that takes a long time or tends to go wrong.

In an operating business, those signs usually point to a short list:

• Intake: orders, inquiries or job requests typed from emails and forms into the system that runs the work.
• Billing: an invoice built when a job closes, and a follow-up when it goes unpaid.
• Onboarding: a new client or employee set up in each tool, with the same details typed each time.
• Scheduling: bookings confirmed, and changes passed on to everyone they affect.
• Reporting: the weekly figures pulled from three tools into one sheet.
• Routing: a web inquiry sent to the right person with its details attached.

What these share is that the decision has already been made. What happens next is settled, and the person doing the work is carrying details from one place to another. Work that needs judgment every time, such as pricing an unusual job or calming an upset customer, is a poor first candidate even when it takes a lot of hours.

What should a business automate first?

Making the list is the easy part. The order is harder. Score each candidate on the same tests, and the first project usually stands out:

Two rules for reading the scores. First, a candidate that scores low on the rules or the input isn’t ready, however many hours it takes: fix those first, as the next section explains. Second, between two ready candidates, take the one whose result you can check soonest. An automation that runs every day shows quickly whether it works, while one that runs at month end takes a quarter to prove.

How do I know if a process is ready to be automated?

A process is ready when software could follow it without stopping to ask questions. Six checks:

• You can write the steps down: if three people describe the job three ways, software will do it a fourth way. Agree on one way, by hand, first.
• Most cases follow the main path: list last month’s exceptions. If they’re a handful, automate the main path and send the rest to a person. If every case is an exception, it isn’t ready.
• The inputs are data: the details arrive in a form, a system or an email with a set layout. An AI step can read free text and PDFs, but it adds checking.
• The systems can be reached: each tool involved has an API, an export or a connector. A system with no way in can stop a project however simple the logic is.
• Someone owns the result: a named person who can say what correct looks like and who hears about it when a run fails.
• You know today’s numbers: how many a week, how long each takes and how often it goes wrong. Without that baseline, nobody can say later whether it worked.

Don’t skip the first check. IBM lists thin process documentation among the roadblocks to automation, and writing the steps down costs far less than rebuilding an automation that encoded the wrong ones.

How do I calculate the return on automating a process?

Work it out in hours first, then in dollars. Take an example:

• The task: orders come in by email and someone retypes each one into the job system: 20 minutes each, 15 times a day, five days a week.
• The hours: 20 minutes times 15 is five hours a day, or 25 hours a week. Over 52 weeks, that’s 1,300 hours a year.
• The cost of an hour: in June 2026, US private employers paid an average of $46.89 per hour worked, wages and benefits together, and $14.07 of that was benefits (Bureau of Labor Statistics, released September 2026). Use your own payroll figure for the people who do the task instead: it’s the one that counts.
• The gross figure: 1,300 hours at $46.89 comes to $60,957 a year.

That figure is a ceiling. Three things come off it before you reach the saving:

• Running costs: subscriptions, usage fees, hosting and upkeep, every month.
• The time that stays: someone still checks results and handles exceptions. If one order in ten still needs a person, keep a tenth of the hours in the sum.
• The build: the setup or the software, paid once.

The payback period is the build cost divided by the monthly saving that’s left. What builds cost in the market is on the custom software cost page. Some of the return won’t show up in hours: fewer typing errors, faster replies, and work that doesn’t stall when someone is out. Count those only if you measure them today, or the sum turns into a guess.

Can an owner-run business automate without custom software?

Often, yes, at least for the first few processes. Work through the options from lightest to heaviest:

• Features you already pay for: accounting, CRM and scheduling tools often have triggers and rules built in. Check them first.
• A connector tool: Zapier, Make, n8n and Power Automate link the apps you already use, so an event in one starts an action in another. The Zapier vs Make vs n8n guide compares how they bill and where they run.
• An AI step inside a workflow: when the input is an email, a PDF or a scanned form, a model can read it and pull out the details, with a person reviewing anything it isn’t sure of.
• Software made for the process: when the work needs its own screens, its own records or rules too involved for a connector, it becomes custom software. Whether to build or buy is a decision of its own, set out in the build vs buy software guide, and no-code vs low-code weighs the tools in between.

Pick the lightest option that runs the process reliably. Signs you’ve stretched a connector too far: a chain of steps nobody wants to touch, the same data in three tools that disagree, usage bills that rise with every order, or a workflow only one person understands.

Marketing automation is its own branch. A marketing automation consultant sets up email sequences, lead scoring and the hand-off from marketing to sales inside a CRM or an email platform, within that platform’s own rules. Operations work, such as orders, jobs, invoices and schedules, usually crosses more systems, which is where connectors and custom builds come in.

What are the challenges of workflow automation?

Most of them sit at the edges of the process:

• Exceptions: real work brings cases the rules don’t cover. Each workflow needs a route for them, usually to a person with the details in front of them, and a count of how often it happens.
• Messy inputs: a customer puts the address in the notes field, or a supplier changes its invoice layout. The automation should stop and flag an input that doesn’t fit.
• Tools that change: the apps at either end rename fields, change limits or retire features, and a workflow that ran in March can fail in June with nobody touching it.
• Quiet failures: a run that fails without telling anyone is worse than no automation, because people have stopped checking. Every workflow needs an alert and a log.
• People and habits: IBM notes that keeping people and automated systems in step can be complex and may need training and some cultural adjustment. The team needs to know what the automation does, what it doesn’t, and what to do when it stops.
• Access: an automation signs in to your systems. Give it its own account with only the permissions it needs, so its actions can be traced and switched off.

IBM also points out that what works for one set of tasks may not carry over to the next. Plan the second automation as a project of its own, with its own checks.

What doesn’t make a process a good first pick?

A few common starting points lead the wrong way:

• The task people complain about most: a good way to find candidates and a poor way to rank them, since what makes a task frustrating is often its exceptions.
• A tool from a demo: start from the work, then choose the tool that fits it.
• The process as it runs today, workarounds and all: automating a muddle only makes the muddle run faster.
• Hours on their own: a task that takes many hours but needs judgment each time won’t run on rules.
• Everything at once: one process, measured, then the next.

How do I start automating business processes?

1. List the candidates: for a week, note every task where someone moves details from one place to another by hand.
2. Measure each one: how many times a week, how many minutes each, and how often it goes wrong.
3. Score them: use the tests in the table above, and set aside any that fail on rules or inputs for now.
4. Fix the process before automating it: one written way of doing it, agreed by the people who do it.
5. Automate the main path: the cases that follow the rules, with the exceptions routed to a person.
6. Check it, then widen it: compare against your baseline after a month, then add the next most common case or the next candidate.

Steps 1 to 3 take a few hours and no software. They’re worth doing even if you never automate anything, because they show where the team’s week goes.

If you’d like help putting numbers on it, the free Operations Audit worksheet counts the recurring work your team does by hand. When a process is worth automating, our business process automation services build the rules that move each record to its next step or system, in software made for your business and kept in its own repository, and we keep running what we build on a monthly plan. If something you already pay for can handle it, we’ll tell you. It starts with a 15-minute call.