How to pick the first process to automate

The most common automation mistake isn't technical. It's picking the wrong process — usually the most annoying one instead of the most expensive one, or the most impressive-sounding one instead of the one that's actually automatable. The result is a build that works perfectly and doesn't matter.

Here's the sequence that avoids that. It's a simplified version of what we run in the Mevera Diagnostic Method, and you can do it in an afternoon with a spreadsheet.

Step 1 — List what repeats

Write down every task anyone on the team does more than once a week. Data entry, invoice handling, answering the same customer questions, assembling reports, chasing documents, copying things between systems. Don't filter yet — the goal is a complete list, and most teams are surprised how long it gets.

Step 2 — Keep only the rule-based ones

Cross out anything that needs real judgment on most runs. "Decide whether this supplier is worth switching to" is judgment. "Copy the invoice amount into the accounting software" is rules. Automation handles rules brilliantly and judgment badly — and pretending otherwise is how automation projects turn into disappointments.

Step 3 — Score by hours and error cost

For each surviving task, estimate two numbers: hours per week across the whole team, and what one mistake costs. A task that eats ten hours a week is an obvious candidate. So is a task that only takes two — if a typo in it means a mispaid invoice or a compliance problem. High frequency and high error cost both move a task up the list.

Step 4 — Check system access

A process is only automatable if the systems it touches can be connected. Most modern tools — accounting software, CRMs, shop platforms, email — have APIs or at least structured exports. A process locked inside a desktop program from 2009 with no export function is a bad first project, even if it scores well on everything else. Save it for later.

Step 5 — Pick one, and define the number

One process. Not three, not a "digital transformation". Take the top of your list and write down the target before anything gets built: hours saved per week, or minutes per transaction. If the build doesn't hit the number, it failed — having that number on paper is what keeps everyone honest, including whoever you hire to build it.

That last habit is the whole reason our sprint guarantee can exist: we agree the number in writing before we start, and refund in full if the build misses it. But the method works whether you use us or not — and the audit that runs this properly is credited back in full if you book a build within 30 days.