Which of your business workflows can AI actually automate
There’s a predictable rhythm when someone first sits down to automate their work with an AI agent. First the excitement: everything tedious can finally be handed off. Then the doubt: “But my flow is different – too many exceptions.” And then they go back to filling spreadsheets manually. The question they skip is the one that matters: is this workflow structurally ready to be automated?
Not every repetitive task is automatable, and not every messy task is off-limits. Over the last few months, I’ve helped several people figure out which side of that line their work sits on. The answer almost always comes down to a handful of properties you can check before opening Claude Code or start looking for automation platforms.
I think of it as a two-tier framework: necessary conditions that must all be met, and nice-to-haves that help you prioritise.
The four necessary conditions
Repeatable. The workflow has to recur often enough for the setup cost to pay off. Weekly or monthly is usually the minimum. One-off tasks don’t belong here, no matter how painful they are. Repetition also gives you a feedback loop – you only learn where an agent fails by running it against many instances.
Documentable. You can put the process on paper end-to-end, including edge cases. If it only exists in someone’s head, you have a knowledge-capture problem before you have an automation problem. The test: could a new hire execute it from your written instructions without questions?
Rule-based, not judgment-based Decisions follow defined logic rather than case-by-case judgment depending on unwritten context. This is the most commonly misjudged criterion. Many tasks feel like judgment but are pattern-matching on things the operator has internalised. If you can write the rules, even the exceptions, it’s rule based.
Verifiable. You can tell whether the output is correct, either against ground truth or via spot-checks. Without verification, you can’t trust the agent or catch drift.
The nice-to-haves
The strongest candidates are ones where the information already lives somewhere accessible – a doc, sheet, or email thread. Tools matter too: Gmail, Sheets, Notion, and most modern SaaS are easy; legacy systems are not. Two final checks: how bad is an error (a misfiled row vs. a wrong client email), and how much time does this actually cost you? A ten-minute task rarely justifies the setup unless it’s weekly.
Case 1 – VC deal flow problem
A venture capital professional complained over coffee that he was spending hours every week consolidating deal flow – emails, contact forms, inbound intros – into a Google Sheet. His instinct: too many input sources to automate.
The framework told a different story. Repeatable: deals come in daily, consolidation happens weekly. Documentable: when I asked him to narrate what he did with a specific email, he listed the steps without hesitation – pull company name, stage, check size, sector, source, paste into the sheet in that order. Rule-based: each input follows the same extraction pattern regardless of channel. The source varies, the output schema doesn’t. Verifiable: any row can be checked against the original email in seconds. Over that cup of coffee, he had written the rules out loud without realising it. “Too many input sources” was a documentation problem in disguise – the variety was in the channel, not the task.
Case 2 – FMCG invoice categorisation problem
A friend in finance was convinced his month-end invoice review couldn’t be automated. Invoices arrived in different formats, and the same supplier might appear as ‘Irene Adler Ltd’, ‘IR’, or ‘IRA’. But in one conversation, he listed every edge case he’d encountered: the naming variants, the format quirks, which fields to trust when sources conflict, which to flag rather than categorise.
Those edge cases weren’t blockers – they were the documentation. The same list you’d give a new hire is your instruction set. With the rules written down, categorisation becomes deterministic and verification takes minutes against source invoices. Messy inputs aren’t unautomatable inputs.
What the framework is really doing
Both cases looked hard to the person closest to them, and both passed cleanly. People doing a workflow undercount how much they’ve already systematised, because the systematisation lives in their heads.
None of this requires an engineer. The harder part is recognising which workflows are worth the investment – and that only comes from spending time with the tools, building a sense of what they can and can’t do.
In my own team, this started with me bored on a Saturday in January, watching a two-hour YouTube tutorial about Claude Code. By Monday I’d built my first automated workflow. By the end of the week I’d walked my team through what I’d built; within weeks, they were running their own setups. When we connected Claude Code to our existing tools through MCP integrations, it stopped being a personal experiment and became a team workflow. Now, in spring, my colleagues are finding use cases I hadn’t even considered.
One person on your team figuring it out and showing the others is usually how it starts.
