When Not to Automate a Process: The Audit That Saves You 20,000€

Six months ago a client paid us nearly 20,000€ to automate a process that ran four times a month. Three minutes each. We did the math: ROI would arrive in the year 2051.

Nearly 20,000€ to automate a process nobody actually used

The process was a discount approval workflow. The brief sounded reasonable: sales reps were waiting too long for sign-off, deals were slipping, automation would fix it. We built it. Clean Slack approvals, HubSpot updates, audit trail in Notion. It worked beautifully.

Then we measured. Four approvals a month. Three minutes each. Twelve minutes saved monthly. At that rate, the nearly 20,000€ build pays itself back somewhere around the year 2051.

Nobody lied. The sales director genuinely felt the bottleneck. The reps genuinely complained. But the actual data nobody pulled before signing the contract said the problem wasn't worth solving with code. It was worth solving with a Slack channel and a rule: "discounts over 15% need director approval, reply within 4 hours."

That project is the reason we now refuse work. Not because we don't want it. Because we've seen what happens when you don't.

The number nobody wants to look at

Automation has a failure rate the industry quietly tolerates. EY found that 30 to 50% of initial RPA projects fail. Forrester reported that only 52% of companies manage to scale past their first 10 bots, and 45% see weekly bot breakages. Deloitte has attributed much of the failure to poor change management, not to the technology itself.

The pattern repeats with every new wave of tooling. RPA yesterday, AI agents today. Different decade, different tools, same root cause underneath: the process you're automating wasn't ready. The same dynamic shows up when a sales forecast misses by 30% quarter after quarter — the tooling amplifies whatever was already loose underneath.

The vendors and integrators selling the project know this. They just don't lead with it, because "your process isn't ready" is a harder conversation than "sign here."

The Bill Gates rule the industry pretends not to know

In 1996, Bill Gates wrote: "The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency." (Bill Gates, The Road Ahead, 1996).

Thirty years later, it still defines whether a project works. Drop Make, n8n, Zapier or HubSpot Workflows on top of a clean process and you get a clean process at 10x speed. Drop them on top of a messy one and you get mess at 10x speed, with more places for it to break. The decision of whether to stay on a generalist SaaS or move to a custom automation when Zapier or Make stop being enough is downstream of this same question: the tool isn't what breaks the project, the process underneath is.

This is why generalist integrators won't tell you to stop. Their billing model rewards shipping workflows, not auditing whether the workflow should exist. The honest version of the conversation sounds like: "we can build this in three weeks, but if your reps don't follow the same path 80% of the time, we'll be back in three months fixing edge cases. Let's fix the process first."

That conversation costs your integrator a project. So it rarely happens.

The Aoware checklist: 5 questions before we touch a line of code

Before we quote, we run the candidate process through five questions. If any of them fail, automation is the wrong answer right now.

1. Volume: does it happen at least 20 times a week?

Below that threshold, the engineering hours rarely pay back. A process that runs 4 times a month isn't an automation candidate. It's a checklist.

2. Frequency: is it predictable?

A process that fires daily is different from one that fires when a particular customer renews. Automation rewards rhythm. Sporadic processes are better handled by a clear owner and a calendar reminder.

3. Variance: does it happen the same way at least 80% of the time?

This is where most projects die. If your sales team handles enterprise deals one way, mid-market another, and SMB a third, you don't have one process. You have three. Automating "the deal handover" averages them into a workflow that fits none.

4. Clear trigger: can you point at the exact event that starts it?

"When a deal moves to Closed Won in HubSpot" is a trigger. "When the rep feels the deal is ready" is not. If the start of the process lives in a human judgment call, automate the parts after it, not the trigger itself. The same logic explains why a clean CRM is an invisible asset: without observable fields and stages, you don't have triggers — you have hopes.

5. Minimum ROI: 5x over 12 months

Here's the math we run, simplified: Hours saved per month × loaded hourly cost × 12 months ≥ 5 × build cost. A workflow that saves 2 hours a week at 40€/hour saves about 4,160€ a year. That justifies a build up to ~830€. Anything above that, fix the process with a checklist and revisit in a year.

If the candidate process doesn't clear all five, automating it will produce a project that looks good in the demo and dies in month four.

The 4 cases where we tell you not to automate yet

These come up often enough that we've named them.

Case 1: the process lives in one person's head

Anna in operations has been doing the monthly client reconciliation for six years. She knows the exceptions. She knows which client invoices arrive in the wrong format. She knows which manager to ping when a number doesn't match.

You don't have a process. You have Anna. Automating it means encoding her undocumented decisions into a workflow, and the first edge case will break it. What to do instead: document the process with Anna for two weeks. Once it's written down and someone else can run it from the doc, automation becomes possible.

Case 2: variance above 40%

We see this in lead qualification constantly. Reps say they follow the same flow. Then we shadow them and find five versions, depending on lead source, deal size, and rep preference.

A workflow built on "the qualification process" will misfire in 40% of cases. What to do instead: pick the version that wins more often, standardize it, run it manually for 30 days. If the win rate holds, then automate.

Case 3: the trigger is ambiguous

"Send the renewal email when the client is ready to renew." When is that? 90 days before? 60? When they open a pricing page? When the CSM says so?

Until the trigger is a concrete event, the automation will either spam clients or miss them. What to do instead: decide the trigger with the team that owns the outcome. Write it down. Then automate. This is also the cleanest way to spot early warning signs of a sales bottleneck before they harden into structural problems.

Case 4: not enough volume

A process that runs 4 times a month, even if it takes an hour each time, gives you 48 hours saved a year. Even a much smaller build than the nearly 20,000€ example above still costs more than that. What to do instead: build a one-page SOP, assign an owner, set a calendar block. Revisit when volume crosses 20/week.

What the one-week audit actually looks like

We charge a fixed price for a five-day audit. The deliverable is yours whether you continue with us or not.

• Day 1–2: shadowing and interviews. We sit with the people who actually run the process. Not the manager describing how it should work. The person doing it.
• Day 3: measurement. Volume, time per execution, variance, error rate. Real numbers, pulled from HubSpot, the inbox, the spreadsheet, wherever the truth lives.
• Day 4: ROI per scenario. We model two or three automation scopes, from minimal to full, with the math behind each.
• Day 5: deliverable. A document with the process as it is, the gaps, the recommended scope (or the recommendation not to automate yet), and the price if you proceed.

If the answer is "fix the process first," we say so on day 5 and explain what to fix. That's the whole point of the week.

Clients who saved their first 20,000€ before spending it

Two patterns we keep seeing, anonymized into the shape they usually arrive in.

Pattern 1: client onboarding across multiple systems. A company wants to automate onboarding because the same data is being entered into a CRM, a billing tool and an internal database, and the handoffs are slow. When we measure, we find two of those systems have been holding contradictory data for months — the team has been silently patching the mismatches by hand. Our recommendation: fix the sync first, automate after. An automation built on top of contradictory sources doesn't speed up onboarding. It propagates the contradiction faster, into more places. Cost avoided: an integration project that would have amplified the mess instead of solving it.

Pattern 2: inbound lead qualification with low volume. A company wants an AI-assisted qualification flow because the sales team feels overwhelmed by inbound. When we count, the actual inbound is 15 to 25 leads a month, not a week. The "overwhelm" is concentration: leads arrive in bursts on Monday mornings and after campaigns. Our recommendation: skip the automation, write a one-page qualification SOP, assign rotation. Revisit when volume triples. Cost avoided: an AI workflow whose monthly tooling cost would have exceeded the time it saved.

Both decisions cost us a larger project this quarter. Both kinds of clients have brought us back since for work where the math actually works.

What to do now

Pick the process you're closest to automating. Run it through the five questions:

1. Does it happen at least 20 times a week?
2. Is the frequency predictable?
3. Does it follow the same path 80% of the time?
4. Is the trigger a concrete event?
5. Will it return at least 5x over 12 months?

If any answer is no, fix that first. The automation will work better, cost less, and last longer when you come back to it.

Before automating anything, we run a one-week process audit. If the process isn't ready, we tell you straight and explain what to fix first. Drop us a line and we start there.