How do you know if a process is worth automating?

Automate a process when it is repetitive, stable, and expensive in a way you can name. All three matter. If the process is still changing shape every month, automating it locks in a design you are about to regret, and you will spend more maintaining the automation than you ever spent running the process by hand.

The question is not whether something can be automated. Nearly anything can. The question is whether the version you build will still be right in a year.

What makes a process a good candidate?

Run it against four tests.

It repeats on a predictable rhythm. Weekly, daily, per order, per patient, per ticket. Something that happens twice a year is almost never worth automating, no matter how annoying it is when it happens.

The rules are stable and knowable. Not simple. Stable. A process with forty rules that have not changed in two years is a much better candidate than a process with four rules that get renegotiated every quarter.

The cost is nameable. You can say what it costs in hours, errors, delay, or dependency on one person. "It's a pain" is not a cost. "It takes our operations lead six hours a week and we find two mistakes a month" is a cost.

The failure mode is tolerable. If the automation gets something wrong, does someone notice before it matters? Processes where a silent error compounds for weeks need more design work up front, and sometimes need to stay manual longer than you would like.

How do you actually size the cost?

Most teams undercount this badly, and they undercount it in the same two ways.

They price the visible time and skip the switching cost. The person doing the work is not just losing the ninety minutes the task takes. They are losing the focus around it, and the work they would otherwise have done in that block.

And they price the wrong person's time. When a founder or a CEO is the one running a manual process, the real cost is not their hourly rate. It is everything that did not happen because they spent Thursday morning in a spreadsheet. That is the number that actually justifies the work, and it is the one nobody writes down.

The third cost is the one nobody counts at all: the risk that the process only exists in one person's head. That has a price. You usually discover it at the worst possible moment.

When should you not automate?

More often than the current conversation about AI would suggest.

When the process should be eliminated, not automated. A meaningful share of what I get asked to automate should not exist. A report nobody reads. A reconciliation step that exists because two systems disagree, when the real fix is making them agree. Automating a step that should be deleted makes it permanent, because now it is cheap enough that nobody questions it.

When the process is still being figured out. If your operations lead is actively changing how this works, wait. Let it settle. Automating a moving target is how you end up with a system that fights the business.

When the volume is genuinely low. Sometimes the honest answer is that this takes twenty minutes a week and it is fine.

When buying solves it. If a product already does this well, buy the product. I say this to clients regularly, and it is a shorter engagement for me, which is exactly why it is worth trusting.

What about AI specifically?

AI changes what is automatable. It does not change this decision.

The tests above still apply. AI mostly expands the second one, because it can handle processes where the rules are real but hard to write down: reading unstructured documents, classifying messy inputs, drafting something a human then approves. Those were genuinely not automatable five years ago and now are.

What has not changed is that a process which should be eliminated is still not worth automating, and an unstable process is still a bad target. The failure I see most often right now is a company reaching for AI on a workflow whose actual problem is that two systems do not talk to each other. That is an integration problem. A model does not fix it, and adding one makes the real problem harder to see.

When I embedded AI across our software delivery work, it went in where the work was repetitive and the output got reviewed by a person: requirements, prototyping, development, testing, and code review, under written governance. That combination is the point. Repetitive enough to be worth it, reviewed enough to be safe.

How do you pick the first one?

Take the process where a specific person is the bottleneck and the cost is easiest to state. Not the biggest problem, and not the most interesting one. The one where you will be able to tell in three weeks whether it worked.

There is a practical reason for that. The first automation in a company is not really about the hours it saves. It is about establishing whether this kind of work pays off here, on a scale small enough that being wrong is cheap. Once you have one result you trust, the second and third decisions get much easier, and you make them with real evidence instead of a vendor's estimate.

That is how nearly every engagement I run starts. One problem, named clearly, with a measure agreed before the work begins.

If you can name the process that is costing you the most right now, that is enough to start a conversation.