Time Automation Agency
3/24/26
Deciding What to Automate First (and What Not To): the Core of APM
Most automation projects fail because they automate in the wrong order. APM defines the prioritization criterion before any tool is chosen. This article explains how to decide what to automate first, what to defer, and what never to automate, using real financial criteria instead of pressure or guesswork.
Most companies that automate poorly don't do so because they lack tools. They do it because they automate in the wrong order.
The question they most avoid isn't "how do I automate this?" It's "does this deserve to be automated now?"
That difference isn't semantic. It's the difference between a project with real return and one that generates technical debt, internal friction, and the conviction that "automation doesn't work for us."
APM, as a discipline, starts exactly there: before the tool, before the vendor, before the pilot. It starts at the decision.
Impact vs. Effort
Two variables define whether a process is worth automating first: how much return it generates and how much it costs to do it right.
Most teams only evaluate one of the two.
If you only look at impact, you end up choosing the most visible process or the one that hurts most, not necessarily the one with the best return. If you only look at effort, you end up choosing the easiest to implement, which is almost never the most strategic.
The right criterion crosses both variables at the same time. A high-impact, low-implementation-effort process is the ideal candidate to start with. Not the most urgent one. Not the manager's favorite. The one with the best return-to-real-implementation-cost ratio.
🔍 This seems obvious until you try to apply it with real numbers. Then most "priority processes" stop being priorities.
That cross requires basic data: how many hours the process consumes today, how often it occurs, who executes it and at what cost, what errors it generates and what those errors cost. With that, the priority map changes completely.
Without that data, prioritization is an opinion. And opinions, in automation, are expensive.
ROI FIRST as a prioritization criterion
What NOT to Automate
APM doesn't only define what to automate. It defines what not to automate. And that second list matters as much as the first.
Some processes shouldn't be automated now because they're poorly designed. Automating a broken process makes it broken faster and at greater scale. Before automating, that process needs redesign. Adding technology on top doesn't improve it: it freezes it in its defective version.
Some processes shouldn't be automated because they depend on human judgment that isn't yet systematic. If the team can't describe the process with clear, repeatable, predictable rules, no system can execute it well. Automation executes rules. If the rules don't exist, the system improvises, and that's worse than not automating.
💡 Some processes shouldn't be automated because the implementation cost exceeds the return over any reasonable horizon. Negative ROI isn't always obvious before running the numbers. APM requires running them.
And some processes simply aren't the right moment. Not because they don't have value, but because there are others with better return and lower risk that should go first. Deferring isn't the same as discarding.
Knowing what doesn't make the roadmap is as strategic as knowing what does.
Processes That Actually Pay
Not all processes have the same return profile. Some pay fast and large. Others pay slowly and little. APM helps distinguish them before committing resources.
The processes that tend to have the best return profile share characteristics: they're repetitive (they occur with high frequency), they're predictable (they always follow the same rules), they consume time from high-cost people, they generate frequent errors with measurable consequences, and they have a clear entry point and exit point.
When a process meets those conditions, the financial case almost always holds on its own. The calculation is direct: how many hours are eliminated, at what cost, with what frequency, minus the cost of implementation and maintenance.
When a process doesn't meet those conditions, the financial case requires assumptions. And assumptions in automation have a poor track record.
🎯 The difference between a project that generates return and one that generates hidden costs often isn't the tool. It's whether the chosen process had the right profile from the start.
That profile is evaluated before starting. Not during. Not after.
Getting Out of Guessing Mode
When there's no explicit prioritization criterion, companies make decisions through one of these routes: the process that's most uncomfortable right now, the one someone saw in a success story from another sector, the one the current vendor offers to implement fastest, or the one "everyone knows needs to be automated."
All of those routes are forms of guessing.
Guessing mode has a structural cost. Not just in the project that goes wrong. In all the correct projects that don't happen because resources are locked in the wrong one. In the distrust that builds when automation "didn't work." In the time it takes the company to try again.
APM replaces guessing mode with a decision system. It doesn't eliminate uncertainty, but it contains it. It defines what information is needed before deciding, what questions must have answers before committing budget, and what criterion is used when there are two options and one must be chosen.
A company can have no automation implemented and still be making good automation decisions. The difference is whether those decisions are made by criterion or by pressure.
📌 Write to me and let's talk about a process.
Share this article with someone who might be interested in learning about this.
Frequently asked questions
How do I know if a process is ready to be automated?
A process is ready to be automated when it can be described with clear, repeatable, predictable rules, has sufficient frequency to justify the implementation cost, and generates a measurable return that exceeds that cost over a reasonable horizon. If any of those three conditions isn't met, the process needs work before it's automated.
What is prioritization in APM and why does it matter before choosing a tool?
Prioritization in APM is the process of deciding what to automate, in what order, and with what criterion, before committing any resource. It matters before the tool because the tool only executes what it's given. If what it's given is the wrong process, the right tool produces the wrong result.
What is impact vs. effort analysis in automation?
It's the intersection of the expected return from automating a process (reduction in hours, errors, costs) and the real cost of doing it right (team time, technical complexity, maintenance). The process with the best ratio between the two, not the most urgent or the easiest, is the right candidate to start with.
What role does the team play when APM defines what not to automate?
The team shifts from executing a decision already made to participating in the prior diagnosis. In APM, the team contributes the information that makes prioritization possible: how much time the process consumes, what exceptions exist, what rules are actually followed in practice. That information doesn't exist in any system. It lives in the people who operate the process. Without it, the decision of what to automate first is a well-presented guess.