The 4-question filter that tells you which workflow to automate first

You have a list of ten processes that could be automated. Some are quick wins. Others are rabbit holes that will consume weeks of work for a payout that barely justifies the effort. How do you decide where to start?

Solo operators and small teams rarely have the luxury of a dedicated dev team to prioritize automatically. You need a filter that is fast to apply, accurate enough to avoid wasting time, and scalable as your infrastructure grows. The four-question filter below has worked well for teams running production systems without a full-time engineering crew.

Question 1: How often does it run?

Frequency is the first signal. A process that runs once a year is rarely the best automation target. If a manual step happens dozens of times a week, automating it provides daily value. Even a weekly process can be worth the effort if it involves multiple systems and multiple people.

For example, reconciling vendor invoices against purchase orders is often done monthly. If that process touches five different tools, requires three people to sign off, and takes half a day, the payback period of automating it is measured in days, not weeks.

When evaluating frequency, consider both the hard schedule and the ad-hoc occurrences. Does someone always remember to run the backup check on Friday? Or do they miss it occasionally, creating blind spots?

Question 2: How many systems does it touch?

The complexity of a workflow multiplies with every external tool. If a process only touches a single system, you can likely script or schedule it with a single command. If it involves authentication across multiple services, moving data between tools, and human coordination, the automation surface grows rapidly.

A good rule of thumb: each additional system adds a layer of integration complexity. Automated authentication, format conversion, and cross-service notifications each introduce potential failure points. When you count systems, count the number of data transformations as well.

For instance, deploying to production might involve a code repository, a CI pipeline, a staging environment, and a production server. That is four systems plus the data transformation of pushing code to each. A process that touches two systems is much safer to automate in your first round than one that touches eight.

Question 3: How reliable is the manual process?

Error rates are often hidden behind an assumption that humans never make mistakes. In reality, manual workflows accumulate errors over time, especially when they are performed at scale or under time pressure. Look for signs of drift, rework, and informal workarounds.

If someone has created a spreadsheet to supplement an automated system, that spreadsheet is a symptom of a process that is not fully automated. If your team talks about "remembering" to do something during the release, the process lacks guardrails. If multiple people are required to sign off on the same deliverable, someone is likely skipping or bypassing steps when the process becomes cumbersome.

Reliability is not just about frequency of errors. It is also about predictability. A process that runs three times a week but takes exactly 45 minutes each time is more predictable than one that takes anywhere from 10 to 90 minutes depending on who is doing it.

Question 4: What is the cost of doing it wrong?

Not all errors are equal. Some are annoyances. Others can lead to data loss, downtime, or reputational damage. The cost of doing it wrong should inform how you scope the automation effort.

Processes that touch critical data or customer-facing systems warrant more thorough automation and testing. For example, a process that pushes a configuration file to ten servers has a very different risk profile than one that generates a weekly report. If an error propagates to production customers, the automation must include rollback mechanisms and validation steps.

When the cost of doing it wrong is high, invest in clear documentation, dry-run steps, and staging environments. When the cost is low, you can iterate faster and roll out automation in smaller increments.

Applying the filter

To apply the filter, run through each of the four questions for your candidate processes. Score each question as low, medium, or high. Then look for processes with a high frequency, moderate system count, moderate reliability issues, and a manageable cost of doing it wrong.

The sweet spot for your first automation efforts is usually the intersection of frequent execution, moderate complexity, and clear downstream value. A process that runs weekly, touches three systems, has occasional manual workarounds, and feeds into a customer-facing deliverable is a strong candidate for automation.

Once you have identified a target process, sketch out the steps, identify the systems involved, and draft a high-level automation design before writing any code. The filter gets you to the right target. Good design gets you there reliably.

Want the full version?

Ops Starter Kit Vol. 2 — A$27 | Agent Ops 24/7 — A$19 | The Automation Starter Pack — A$19 | Hive80 Ops Mega Bundle — A$29 | free: The First 30 Minutes