How to spot a process worth automating before you buy anything

I've seen this play out more than once. A business spends three months and around $22,000 automating their weekly inventory report. The build goes well. The report runs on schedule, clean and formatted, every Monday at 7 a.m.

Six weeks in, the ops manager notices the numbers look off. One supplier had renamed a column in their export file. The automation had been pulling the wrong data for six weeks straight, and nobody caught it because the person who used to catch it wasn't checking anymore.

They didn't buy the wrong tool. They automated the wrong process.

The selection step is where most automation projects are won or lost, and it's the step that gets the least attention. Here's how to get it right before you spend anything.

Which of your manual processes is actually ready to automate, and which ones are a data-quality problem or a 14-times-a-year task that only feels constant? The Fastw3b automation audit is the first step that gives you a straight answer. It maps how your processes really run rather than how they are supposed to run, finds the ones where error rate and downstream cost are the hidden driver rather than time alone, and hands you a ranked plan showing what to automate first and what needs to be fixed before any build starts. The audit is step one; automating what it flags is where the hours come back. Explore business automation →

Not Every Manual Step Deserves to Be Fixed

The instinct when you start thinking about automation is to scan for anything manual and ask: could this run itself? That's the wrong question.

Manual work isn't automatically a problem. Some manual steps exist because they require judgment. Some run so rarely that automating them would cost more than a decade of doing them by hand. Some are fast, low-error, and genuinely don't hurt.

The two signals that matter most are frequency and error rate. A task you do twice a year, correctly, in 20 minutes is not a candidate. A task you do three times a day, frequently wrong, with downstream consequences is exactly what you're looking for.

Error rate is the one most people undercount. They track time, not mistakes. A process that takes two hours a week and produces a correct result is a much weaker candidate than one that takes 45 minutes and generates three callbacks, a correction email, and a customer complaint every other week. That second one has a hidden cost that doesn't show up in any time log.

High frequency plus high error rate is the signal you're looking for. Time alone won't tell you.

Three Questions That Show Whether a Process Is Ready

Before you score anything or build anything, run every candidate process through what I call the Process Readiness Check. Three questions, honest answers.

Does this process run at least weekly?

If the answer is no, the economics rarely work. A process that saves two hours per run will return around 100 hours over a year if it runs weekly. If it runs once a month, you're looking at 24 hours saved annually. That sounds meaningful until you factor in the time to document, build, test, and maintain the automation, plus the inevitable edge cases that surface six weeks in. Most once-a-month processes break even at best.

There's a useful gut check here: if you doubled the frequency of this process tomorrow, would it become urgent? If yes, it's a candidate. If doubling it still wouldn't hurt much, it probably isn't.

Does a human currently catch errors in this process?

This is the question that saves the most projects from going sideways. If a person reviews the output, approves it, or corrects it before it goes anywhere, that person is load-bearing. Their role isn't just checking; it's absorbing variation, noticing the thing that's slightly off, and making judgment calls on edge cases that weren't predicted when the process was designed.

Remove them from the loop and you need to build every one of those checks into the automation itself. That's possible, but the project you're about to build is significantly bigger than the one you were imagining. If your answer is yes, the readiness check isn't failed, but your scope just doubled, and your timeline should reflect that.

Is the input data consistent and structured?

Automation struggles with exceptions. A process that runs on a clean, structured data feed (a form submission, a standardised report, a reliable integration) is far easier to automate reliably than one that depends on PDFs from three different suppliers in four different formats, or email attachments where column headers change quarterly. If your process is downstream of variability you don't control, fix the data problem first. Automating a chaotic input just produces chaotic output faster.

How to Rank Your Candidates Before Spending a Dollar

Once you've run a handful of processes through the Readiness Check, you'll usually land on two or three candidates. Here's a simple way to rank them without needing a consultant.

Score each process from 1 to 3 on four dimensions:

• Weekly run frequency (1 = fewer than 2 runs per week, 2 = 2 to 5, 3 = more than 5)
• Error rate and consequence (1 = rarely wrong, 2 = wrong sometimes with mild cost, 3 = wrong often or with significant downstream damage)
• Human-in-loop complexity (1 = safe to remove the human, 2 = one checkpoint needed, 3 = multiple approval steps required)
• Data consistency (1 = messy and variable, 2 = mostly clean with occasional exceptions, 3 = clean and structured)

Add the scores. The highest total is your first candidate. A process with a high error rate and inconsistent data probably isn't a second-phase project. It's a data-quality project in disguise, and automating it before you fix the data will cement the problem in place.

One thing worth doing before you finalise the list: ask each process owner how often the process actually runs, not how often it's supposed to run. A "weekly report" that quietly skips every second or third week because someone is busy is a twice-a-month process. The real frequency matters.

This scoring isn't precise science. It's a forcing function that makes you compare candidates honestly before any vendor has seen your calendar.

What a Ready Process Looks Like: A Before-and-After

Here's what this framework looks like applied to a real routine.

A seven-person professional services firm was spending four and a half hours every Friday pulling together a weekly client status report. One person collected updates from each team member by email, consolidated them into a spreadsheet, formatted it, and sent a PDF to each account. She was also the person who noticed when someone had sent the wrong project status, or when numbers didn't match the previous week's baseline.

Run the Readiness Check: it runs weekly, errors happen about once a month when an update is missed or misfiled, one person reviews and corrects the output before it goes out, and the inputs come from structured internal notes rather than variable external sources. Score: 3 + 2 + 2 + 2 = 9. A solid candidate.

After automating the collection and formatting steps, the same report takes about 25 minutes. The reviewer stayed in deliberately, because the Readiness Check flagged her role as load-bearing and the automation couldn't replicate the context-dependent checks she was making. The time saving worked out to roughly 200 hours a year. The error rate dropped because the collection step stopped depending on whether people replied to an email on time.

The honest part: setup, testing, and ironing out edge cases took about six weeks. Week one felt slower than before. That's normal, and it's worth building into your expectations.

The Honest Caveat: When Automating Creates More Work Than It Saves

McKinsey research consistently puts the failure rate for automation and AI projects at around 60 to 70 percent against expected returns. That isn't because the tools don't work. It's mostly because teams automate before they understand the process well enough.

The failure modes are predictable: hidden human judgment baked into the process, data that wasn't as clean as it looked, or frequency that wasn't high enough to justify the build and maintenance cost. Wrong selection is the root cause in most of those cases.

There's a subtler failure too. Some processes feel painful because they're genuinely inefficient, and the right fix is to simplify or eliminate the step, not automate it. Automating a step you shouldn't be doing at all just makes you do the wrong thing faster and at scale.

If a process exists mainly as a workaround for something else, fix the underlying problem first. Automating a workaround locks it in permanently.

One Step to Take Before You Open a Single Sales Demo

Before you look at any tool or platform, do this: write down your three most painful manual processes and run each one through the Process Readiness Check.

For each one, answer the three questions in order and assign the scores. Write them down. Then rank the list. It takes about an hour, maybe 90 minutes if you want to be honest about the error rates.

You'll usually find that one candidate rises clearly to the top, one turns out to be a data problem in disguise, and one runs far less often than it feels like it does. The misery of doing it on a Friday afternoon makes it feel constant; the calendar usually says 14 times a year.

That list, with scores, is what you bring into any conversation about tools or platforms. It tells you exactly what you're trying to solve and why, which makes it much easier to ask the right questions rather than react to a demo.

It's also what protects you from the scenario this post started with. The business that automated the wrong inventory report had budget and a capable tool. What they were missing was 45 minutes of honest diagnosis before anyone wrote a line of configuration.

The right process, identified before anything is built, is what makes the economics work. The tool comes after.

The right process, identified before anything is built, is what makes the economics work, and a Fastw3b automation audit is the step that gets you there. Plan your business automation →