Four tests for a real automation candidate

Ask a room what they'd automate and you'll hear about whatever made someone angry most recently. That's good information about morale and nearly useless information about cost. The task everyone complains about usually runs a dozen times a year. The task nobody mentions runs forty times a week, and nobody mentions it because it stopped feeling like work sometime in 2021.

So the first move isn't a brainstorm. It's a definition you can hold a process up against:

A quality automation candidate is work that fires on a trigger you can predict, follows a rule you can write down, moves data you can already reach, and costs enough per year to be worth maintaining.

Four tests. Most candidates fail one of them, and — this is the useful part — the test they fail tells you what to do instead.

Test one: the trigger is predictable

Automation has to start on something. If you can't finish the sentence "this work begins when…" in one clause, there's nothing to hang a trigger on.

Good triggers sound like: every Monday at 8. When a request lands in the shared inbox. When a record crosses 60 days from renewal. Bad triggers sound like when it comes up or when someone notices. "When someone notices" isn't a trigger; it's a person doing unpaid monitoring, and that's worth fixing on its own.

The way to find these is not to ask people what they'd automate. It's to look for symptoms.

What you see	What it usually means
The same field typed into two systems	No integration, and no named system of record
Someone alternating between two apps to complete one task	A person is being used as an API
Export, clean up, re-import	A recurring reconciliation — integration debt, paid in labor
A steady trickle of "where is that at?" emails	Status lives in someone's head instead of a shared record
Someone reads incoming requests and forwards them onward	Classification work, which is usually very automatable
Someone scans a report looking for the ones that are off	A threshold check wearing the costume of judgment
A spreadsheet that isn't part of any system	The real system didn't fit, so someone patched around it privately
A personal template, macro, or saved checklist	Somebody already found the pattern and half-specified it for you
Work sent back because information was missing	Bad intake, not bad execution — fix the front door
Only one person can do it at all	A documentation problem first, whether or not it's ever automated

The last two rows are there to redirect you. Rework loops and single-person processes present themselves as automation candidates and usually aren't.

When you do talk to people, ask for instances instead of opinions. What did you type twice this week? What do you do every Monday before anything else? What did you have to chase someone for? What breaks when you're on vacation? What's the last thing you had to redo? Those questions return specifics. "What would you automate?" returns a wish.

Test two: you can write the rule down

Here's the check: hand your written rule to someone who doesn't do the job, and see whether they reach the same decision as the person who does. If they can't, you haven't written a rule — you've written a summary of one.

The usual sticking point is "it depends." That's fine, as long as you can enumerate what it depends on. Six branches covering ninety-five percent of cases, plus a named path for everything else, is a perfectly good automation. The requirement was never zero exceptions. The requirement is that the exceptions have somewhere to go, and that a human is expected to be there when they arrive.

If the depends genuinely can't be enumerated — if the answer changes based on who the client is and what happened on last year's renewal — that's judgment, and it should stay with a person. Some processes should stay manual. Saying so out loud is cheaper than discovering it in production.

Test three: the data is reachable

A trigger and a rule still need inputs, and the format of those inputs sets the price more than anything else in the project.

A structured field in a system with an export or an API is the easy case. The same value sitting in the body of an email is a harder one — now you're doing extraction, which adds cost and a whole category of failure that quietly gets things wrong. Inside a scanned PDF that someone reads with their eyes, harder still. And a vendor with no export and no API is either a hard stop or a line item large enough to change the decision. Find that out in week one, not month three.

There's a second question underneath: is the data any good right now? Automating on top of bad data produces bad data faster. Worse, it removes the person who had been silently correcting it on the way through. That correction is real work, it never appears on a process map, and its absence shows up downstream as a mystery.

Test four: it clears the maintenance floor

An automation is not free after launch. It costs the build, then it costs attention — the day a vendor changes a form, the day a rule changes, the day someone adds a field. So the annual value has to clear that floor with room to spare.

The value side is arithmetic: how often the work happens, how long one instance takes, and what the loaded hour costs. The real cost of "we just handle it in email" walks that formula through with modeled numbers, so I won't repeat it here. Two rules matter when you run it:

Frequency is the multiplier. A ten-minute task that runs daily beats a two-hour task that runs quarterly, even though the quarterly one is the one people complain about.

Never claim all of it. Some review, exception handling, and babysitting survives every automation. If a projection assumes a process goes to zero, the projection is decoration.

What double entry actually costs

Double entry deserves separate treatment, because it's almost always priced wrong. People count the keystrokes. The keystrokes are the small half.

The large half is divergence. Two systems holding the same field will eventually disagree — not because anyone was careless, but because one got updated on a Tuesday and the other didn't. The disagreement doesn't announce itself. It surfaces later as a stale address on a document that went out, a renewal date that was wrong on the report everyone trusted, a bill sent to an account that closed in March. That cost is lumpy, it lands unpredictably, and it is usually larger than the typing.

Which is why every double-entry fix starts in the same place: name which system wins. You cannot sync two records without deciding which one is the truth, and if that decision hasn't been made, the sync will just spread whichever value moved most recently. That's a filing decision before it's a technical one.

Disqualify these on sight

• Annoying but rare. Frequency is what pays for the build. Without it, nothing clears the floor.
• Nobody can describe it. Automating an undocumented process encodes the current mess and runs it faster.
• It's about to change anyway. A system migration or a renegotiated vendor relationship in the next two quarters kills the payback. Wait.
• Judgment dressed as a rule. If the exception handling is really relationship management, leave it with the person who has the relationship.
• The report nobody reads. Delete it. This is frequently the highest-return move available, and it costs nothing.

That last one points at an ordering the rest of this depends on, borrowed openly from industrial engineering and older than software: eliminate, then simplify, then standardize, then automate. Steps skipped early get expensive later. An automation built on an unsimplified process inherits every bit of that complexity permanently, and it becomes much harder to remove once something depends on it.

Most of what the assessment does in its first week is exactly this — walk the work, catch the symptoms, and run each candidate against the four tests before anyone talks about tools. The shortlist that comes out is usually shorter than the client expected and worth considerably more.