How to automate business processes, and which ones to start with

Business process automation means getting software to do the repeatable parts of a job that people now do by hand: typing an order into a second system, sending the same reminder every week, rebuilding the Monday report. This guide covers which process to start with, four ways to automate it, what to build in so it never fails quietly, how to measure it, and when not to.

We design, build and run business automation and integrations, including inside our own products, so this comes from the maintenance end as well as the build. If you don't yet know how the process really runs, map the process first: it is quicker than automating the wrong thing.

What the terms mean

Task automation does one step, such as sending a reminder. Workflow automation moves work through several steps and people, with approvals and handoffs. Process automation runs a whole process, such as order to invoice, often across several systems. What matters is the scope: where the process starts and ends, and which parts a person still does.

Which processes to automate first

List your candidates, then test each one against four questions.

• How often does it run? Multiply runs a month by minutes per run. A job done 400 times a month at four minutes each is about 27 hours a month.
• Is anyone rekeying? Copying data from one screen, email or PDF into another system is the clearest case for automation, because the data already exists somewhere.
• What do mistakes cost? Count how often the work is redone, and what an error leads to: a credit note, a wrong delivery, a customer chased for money they have already paid.
• Is there a deadline? Work tied to a date fails badly when the one person who remembers it is off. Payroll is the obvious UK case: HMRC says to send the Full Payment Submission on or before your employees' payday.

The best first project scores well on all four, follows rules a person could write down, and has few exceptions, or exceptions that are easy to spot. Pick one process, not a programme.

Four ways to automate a process

They are listed roughly in order of cost and effort. Try them in that order.

1. Features already in your systems

Before buying anything, check what the software you already pay for can do. Xero, for example, can send reminders before or after an invoice's due date, create and send repeating invoices, and let customers pay by Direct Debit through GoCardless, and it checks your bank feeds so it only chases invoices that are still unpaid. If a built-in feature covers the job, use it: the vendor maintains it.

2. No-code and low-code tools: Zapier, Make and n8n

These connect apps through their APIs: when something happens in one, do something in another, such as a website enquiry creating a contact in your CRM. They suit simple, low-risk jobs between popular apps, are quick to set up, and can often be changed by someone who isn't a developer.

Check how each one charges before you build on it. As of October 2026, Zapier charges by task, counted each time a Zap successfully completes an action, so a busy workflow with several steps uses tasks quickly. n8n prices its cloud plans on workflow executions, regardless of complexity, and offers a self-hosted Community Edition on GitHub. We compare the two in n8n vs Zapier.

The risk is ownership. Automations built in one person's account become invisible until one stops. Keep them in a company account and write down what each does.

3. RPA: software that works the screen

Robotic process automation drives an application through its screens, clicking and typing as a person would. Microsoft's Power Automate desktop flows, for example, can automate legacy applications such as terminal emulators as well as modern web and desktop applications, using UI elements, images or coordinates. That makes RPA the route for an old system with no API and no export. The cost is fragility: a moved button or a new pop-up can stop it. Treat it as a bridge until the system is replaced or gains an API.

4. Custom integration code

A developer writes software that talks to each system's API directly and does exactly what your process needs. It costs more to build and needs looking after. It is the right choice when the process is central to the business, handles money or personal data, runs at volume, or needs proper error handling and a full record of what happened.

Billing is a good example. In StoreBay, the self-storage software we built and run, each plan is invoiced on its renewal date, payments are collected by card or Direct Debit, and reminders, a late-fee notice and a final notice follow on a schedule the business sets. We wrote our own billing engine rather than use a card provider's subscription product, because UK self-storage has realities those products model badly, such as VAT that depends on the kind of space and Direct Debits that settle days later and can still be reversed. A Direct Debit counts as paid when the provider confirms it; if it comes back later, the payment is reversed and the arrears reopen. Our engine decides what is owed and when; the providers only move the money. Rules like that are where custom code earns its cost.

Where the input is messy, such as orders in free-text emails or supplier PDFs, AI automation can read it and draft the data for a person to check. If you need something closer to a whole system than a connection, our bespoke software examples cover when to build and when to buy.

What to build in from the start

An automation that fails silently is worse than the manual process, because nobody is watching any more. Build in five things, whichever route you take.

• Error handling. Decide what happens to every item the automation can't process, such as a missing field or a rejected payment. Usually: send it to a named person with the details, never skip it.
• Retries without duplicates. A failed step should be tried again (Zapier can automatically replay errored Zap runs on its paid plans), but retries create duplicates unless you guard against them. Stripe, for example, retries webhook deliveries for up to three days with an exponential back off in live mode, doesn't guarantee the order events arrive in, and warns that an endpoint may receive the same event more than once. Its API accepts idempotency keys, so a request can be retried without performing the same operation twice.
• A log. Record what ran, when, on which record and with what result, so that when someone asks why a customer got two emails, you can answer.
• Alerts. Failures should reach a person without anyone having to look. n8n, for example, lets you set an error workflow that runs when an execution fails, to send an email or Slack alert.
• An owner. One named person who knows what the automation does, receives the alerts and decides what changes.

In StoreBay, any change that owes the outside world something, such as a payment, writes that instruction in the same database transaction. Separate workers carry it out with retries and duplicate protection, and an instruction that keeps failing raises an alert. Every 15 minutes a check reads the queues for stuck payments, failed messages and instructions that gave up, then alerts by email and by push, so an email outage cannot mute its own alarm.

How to measure it

Measure the process before you change it, or you will have nothing to compare with:

• runs a month, and minutes of work per run;
• the share of runs that need rework or a correction;
• the time from trigger to outcome, such as order received to invoice sent;
• deadlines missed.

After launch, track the same numbers plus two more: runs finished with no person involved, and runs that failed or went to a person. A rising exception rate usually means something upstream changed, such as a supplier's file format. Count the costs honestly: subscriptions, the build and the upkeep. The saving is the time freed and errors avoided, minus all of that.

When not to automate

Sometimes the honest answer is to leave a process alone.

• It rarely runs. A five-minute weekly job comes to 260 minutes a year, or under 22 hours over five years. If building and looking after the automation would take longer than that, keep doing it by hand and write a checklist.
• The process is still changing. Automate it now and you will spend your time changing the automation. Let it settle first.
• The step shouldn't exist. Remove the approval nobody refuses and the report nobody reads before you automate anything around them.
• It needs judgement. Handling a complaint or deciding whether to allow more time to pay depends on people. Let software gather the facts and a person decide. In StoreBay, declaring a default and selling stored goods are always a person's decision, never a timer's.
• It makes significant decisions about people. Article 22C of the UK GDPR requires safeguards for significant decisions based solely on automated processing, including letting people make representations, obtain human intervention and contest the decision. The ICO's draft guidance on automated decision-making, updated for the Data (Use and Access) Act 2025, explains them.
• A product already does it. If a well-run product covers your process, buying it is usually cheaper than building and maintaining your own.

If you want a hand

Much of this you can do yourself. When the process handles money, runs at volume or needs looking after properly, that is the work we do. Start a project and tell us which process you have in mind.