Business Process Automation: What's Actually Worth Automating?

Most of the automation conversations I have start the same way. A business owner describes a process that's clearly costing them time, asks whether it can be automated, and then asks how much that would cost. The honest answer usually isn't a number. It's: probably yes, but the more useful question is whether you should.

Business process automation is one of those topics where the marketing has run so far ahead of the reality that founders arrive expecting either a miracle or a scam. It's neither. It's an engineering discipline with fairly predictable rules about when it pays off, and those rules rarely match the breathless case studies on software vendors' websites.

What Counts as a "Process" Worth Automating

Before anything else, it's worth defining what we're actually talking about. A process, in this context, is a repeatable sequence of steps that produces a specific outcome. Sending invoices. Onboarding a new customer. Generating a weekly report. Responding to a standard type of enquiry.

The important word is repeatable. If every instance of the process looks different, if the steps change depending on who's doing it or who the customer is, or if there's judgement involved at every turn, you don't have a process. You have a series of decisions that happen to share a label. Those can sometimes be supported by software, but they're rarely good candidates for end-to-end automation.

The processes that automate well have three qualities. They run often enough that the time saved adds up. The steps are consistent enough that you can describe them without saying "it depends" every second sentence. And the cost of getting a single instance wrong is low enough that you don't need a human sign-off on every one.

The Signs You Have Something Worth Automating

A few patterns come up consistently when a business has a genuine automation opportunity on its hands.

The same data is being entered into more than one system. If information from an order form needs to land in your CRM, your accounting software, and a spreadsheet your operations team uses, and someone is doing that by hand, that's a textbook case. The time cost is obvious, and the error rate on manual data entry is higher than people like to admit.

A process is gated on someone remembering to do something. Weekly reports, monthly reconciliations, quarterly reviews that require pulling data from the same three places every time. If the trigger is "it's Monday morning and Sarah has to remember", the trigger can almost always be moved into software.

Routine communications are going out one at a time. Appointment reminders, follow-up emails after a form submission, status updates when a project moves from one stage to the next. None of these need a human composing them each time, and yet in a lot of small businesses that's exactly what's happening.

You have a bottleneck at a specific point in an otherwise fine workflow. Sometimes a process runs smoothly except for one step where everything piles up waiting for a person. That's often the step that's cheapest to automate and highest-impact to fix.

When Automation Is the Wrong Answer

Equally important: the situations where automating is a mistake. I've talked clients out of automation projects more than once, and I'd rather do it early than after they've paid someone to build the wrong thing.

If a process is still changing every few weeks, don't automate it yet. You'll just be paying to encode a workflow that's about to be obsolete. Stabilise it first, run it manually a few more times, and then automate the version you've actually settled on.

If the volume is genuinely low, the maths often doesn't work. A process that happens twice a month and takes ten minutes costs you four hours a year. Unless the task is error-prone in a way that has serious downstream consequences, the engineering effort to automate it rarely pays back.

And if the process fundamentally requires human judgement at every step, automation becomes a way to remove the judgement without replacing it with anything equivalent. That's how businesses end up sending the wrong emails to the wrong customers, or generating invoices that are technically correct but commercially nonsensical.

Off-the-Shelf Versus Custom: Start With the Easy Answer

When automation does make sense, the first question isn't "what should we build." It's "what already exists." For a large category of small-business automation, tools like Zapier, Make (formerly Integromat), and n8n cover the use case competently and at a fraction of custom-build cost.

These tools work by connecting services you already use via their APIs, letting you string together triggers and actions without writing code. Form submission triggers an email, new row in a Google Sheet creates a task in a project management tool, payment received updates a CRM record. None of that needs custom development.

Where those tools start to struggle is when the logic gets genuinely specific. Conditional branching with a dozen rules, data transformations that involve business-specific calculations, or workflows that need to query a custom database all tend to push the limits of what visual automation builders handle cleanly. At that point, a custom web application usually wins. (I've written separately about when to build a custom dashboard versus use a generic tool, which is a closely related decision.)

A Real Scenario: Orders, Inventory, and a Spreadsheet

A client of mine ran a small e-commerce business with a recurring headache. Orders came in through their Shopify store, inventory was tracked in a Google Sheet, and a separate fulfilment team needed a daily summary of what to pack and ship. The sheet was updated by hand from Shopify's admin panel every evening, and the fulfilment team got a summary email the next morning that was sometimes accurate and sometimes not. (The underlying "why is this still in Excel" problem is explored more fully in when Excel is enough.)

We did not build them a custom web app. We built the first version in Make, with a scenario that pulled new orders from Shopify every hour, updated the inventory sheet automatically, and generated the fulfilment summary as a scheduled email. Total build time: two days. Total monthly cost: under fifty euros.

Six months later, when their product range had tripled and the logic around kit products and pre-orders had gotten more complex than Make could comfortably handle, we migrated the whole thing to a small Rails application with a proper admin interface. That was the right time for custom. Not before.

How to Scope an Automation Project Honestly

If you're considering automating something, the most useful thing you can do before talking to anyone is map the process as it actually runs, not as it's supposed to. Sit with whoever does the work and watch them do it. Note every step, every decision, every exception. You'll almost always find that the documented version of the process is cleaner than the real one, and the messy bits are where automation either pays off dramatically or falls over completely.

Then ask three questions. Which steps genuinely have no decision-making in them? Which ones currently take the most time? And which exceptions happen often enough to need handling versus rarely enough to stay manual? The answers give you a target: the boring middle of the process, where you're clearly just moving data around, is almost always the right place to start. (A related question, for workflows that need a shared interface rather than pure automation, is covered in the admin dashboards guide.)

If you're looking at a process and can't quite tell whether automation is the right next step, or which tool to reach for, get in touch. A short conversation usually clarifies whether you need a Zapier scenario, a custom build, or just to run the process manually for another month and see what settles.