The automation audit we run for every new client

Everyone who calls us already knows what they want automated. The invoicing. The reports. "That spreadsheet." They're almost always half right — and the other half is where the real time is hiding.

A bad automation project starts with a tool. A good one starts with an honest hour looking at how work actually flows today. So before we scope, build, or quote anything, we sit down with the people doing the work and run the same short audit. It's deliberately low-tech: a call, a shared doc, and five questions.

The point isn't to find the flashiest thing to automate. It's to find the boring, repetitive, high-frequency work that quietly eats a team alive — and to make sure that whatever we build is worth more than it costs to keep alive.

01 / Frequency"What did you do more than five times last week?"

Automation pays off on repetition, not difficulty. A gnarly task you do twice a year is rarely worth a robot. A trivial one you do forty times a day almost always is. We ask people to walk through a normal week and flag anything they touched repeatedly — even the small stuff they've stopped noticing.

The things people forget to mention are the best candidates, because they've already been mentally filed under "just part of the job."

The most expensive tasks are the ones so routine that nobody complains about them anymore.

02 / Cost"How long does it take, and who has to do it?"

Now we put a number on each candidate. Two cheap numbers, actually:

• Time per run — a rough minutes-per-occurrence, honest rather than precise.
• Who does it — because the same task costs very differently depending on whether it's the founder, an ops hire, or a contractor.

Multiply frequency by time and you get a weekly hour count. Multiply that across the year and the "small annoying task" often turns out to be a week of someone's life. That number is what justifies the build — and it's the number we measure against when we're done.

# the only math the audit really needs
hours_per_year = (minutes_per_run * runs_per_week * 52) / 60

# > ~40 hrs/yr on a repeatable task = almost always worth automating
# < ~10 hrs/yr = probably leave it alone, for now

03 / Stability"How often do the rules change?"

This is the question that saves projects. A task can be frequent and expensive and still be a terrible thing to automate — if the rules behind it change every month. Automating a moving target means you're not building a tool, you're signing up for permanent maintenance.

So we ask how stable the process is. Stable, well-understood work gets fully automated. Fast-changing work gets assisted instead — we build something that does the tedious 80% and hands a human the judgment call, rather than pretending the judgment doesn't exist.

04 / Failure"What happens when it goes wrong?"

Every automation will fail eventually — a login expires, a format changes, an upstream goes down. The question is whether failure is loud or silent. A report that doesn't send is annoying. A bot that silently sends the wrong numbers for three weeks is a disaster.

For each candidate we ask what a wrong answer costs and how quickly someone would notice. That tells us how much to invest in checks, logging and alerts — and occasionally it tells us not to fully automate at all, because the blast radius is bigger than the time saved.

05 / Ownership"Who looks after it once we're gone?"

An automation with no owner becomes a haunted house — it works until it doesn't, and then nobody knows how it was built. So the last question is about life after launch: who gets the alert, who has the keys, and where the docs live. We'd rather build something slightly simpler that the client can actually own than something clever that only we understand.

Run those five questions across a team's work and a clear shortlist falls out: high-frequency, expensive, stable, safe-to-fail, and owned. That's the list we build from. Here's roughly how a first audit tends to shake out.

06 / The takeawayAudit before you automate

The temptation with automation is to start coding the first thing someone points at. But the cheapest, fastest win is almost never the most obvious one — it's the quiet, repetitive task hiding in plain sight. An hour of honest questions before you write any code is the highest-leverage hour in the whole project.

You can run this yourself. Open a doc, list what your team did more than five times last week, and put a time and an owner next to each one. The shortlist will be obvious — and a little uncomfortable.