People usually ask me the wrong first question. They ask what to automate. The better question is whether the thing they have in mind is worth automating at all, and that you can answer yourself, before you talk to anyone, if you know what to check.
I've built enough of these now, WhatsApp systems, voice agents, document pipelines, internal tools, to have a rough set of filters I run in my head before I even open a laptop. None of them are clever. They're just things I learned by getting them wrong once.
Start with what interrupts people, not what looks impressive
In a distribution business I run, there used to be one question that could only be answered by a person: what did this retailer order last time, and what's still outstanding? The information wasn't missing. It was scattered across records, and getting it meant finding whoever happened to know that account and interrupting them.
I built an internal AI tool on our own data that answers those questions in seconds. It doesn't replace anyone's judgement about the retailer, and it was never meant to. What it removed was the lookup, the part of the day that kept getting interrupted by a question someone else could have answered from a screen if the screen existed.
That's the pattern I look for first. Not
is this important work
but
is this a small question, asked often, that currently needs a specific person to be in the room.
If the answer is yes, automation tends to pay off, because you're not replacing judgement, you're removing an interruption. If the process is rare, or genuinely needs someone's judgement each time, automating it usually buys you very little.
Check whether your data actually agrees with itself
I built a dashboard once that joined a CRM, the ad platforms and website data, so a business could see leads, campaigns and traffic in one place. Pulling the data in was the easy part. The hard part, the part that took most of the actual work, was matching each lead back to the ad that brought it in. The CRM knows who the lead is. The ad platform knows who clicked. The website sits between the two of them. None of them agree on an identifier by default.
Until that link exists, you get three accurate reports that can't answer the one question the owner actually cares about, which is which spend is producing customers. The dashboards looked finished long before the problem was actually solved.
So before I quote anyone on a project like this, I ask where the systems involved disagree with each other, not where they hold data. Every business has three or four systems that each think they're the source of truth. If the process you want automated depends on those systems agreeing, that disagreement is the real project. Everything else is plumbing.
Decide, in advance, what happens when the system isn't sure
I once digitised 33 books of handwritten records for a client. Different hands, faded ink, corrections written over the original entry. Reading most of the pages was the easy part for the model. The hard part was deciding what to do on the pages it wasn't sure about, and those were exactly the pages where a wrong answer would matter most, because someone would eventually rely on that number without knowing it had been guessed.
The tempting choice is to make the system always produce something, because a fully filled page looks complete and a half-blank one looks broken. I did the opposite. Anything the system wasn't confident about got flagged and left visibly blank, with a link back to the original image so a person could check it. A blank you can see is cheap to fix. A confident wrong answer nobody notices is the expensive kind, because it doesn't surface until much later, when someone's already relying on it.
That's the second filter I use now. Not
how accurate can this get
but
what does it do when it's wrong, and will anyone notice before it costs something.
If a process has no visible failure mode built in, automating it just moves the risk somewhere quieter.
Ask what it costs to change your mind later
The last filter is less about risk and more about how much flexibility you're buying. I've built promotional videos with HyperFrames, a tool that describes a video in code rather than assembling it by hand in an editor. It doesn't replace a good editor's eye. What it changes is the cost of the next version. Once a video exists as code, a new product, a different headline or another size for another platform is a small edit and a re-render, not an afternoon rebuilding a timeline.
That's worth checking for any process you're weighing up, not just video. If the process will stay exactly the same for years, a rigid, cheaper build is fine. If it's the kind of thing that'll need a new variation every month, a new product line, a new region, a new rule, the value of automating it isn't just the time saved today. It's how cheap the next change becomes.
A process that's automated but brittle can end up worse than doing it by hand, because every small change becomes its own small project.
The checklist I actually use
- How often does this interrupt someone, and does it need that specific person, or just an answer that exists somewhere already
- Which systems does this touch, and where do they disagree with each other about the same fact
- What should happen when the system is unsure, and will that failure be visible or silent
- How often will this process need to change, and what will that change cost once it's automated
- If I removed this interruption entirely, what would that person actually do with the time
That last one is the question people skip, and it matters most. Removing a lookup or a repetitive question only pays off if the freed-up time goes somewhere. In the distribution business, it went into actually talking to retailers instead of finding out what they'd ordered. If nothing replaces the freed time, you've automated a task and kept the cost.
Say a clinic is deciding whether to automate appointment confirmations. Worth checking: how often staff are interrupted for this exact task, whether the booking system and the calendar actually agree on the same patient record, what happens when a reply doesn't match anything expected, and how often the clinic changes its opening hours or services in a way the system would need to know about. Run any process through those four checks honestly, and most of the time the answer is obvious before you've spent anything on finding out.
