What to Automate First

Every week an owner asks us some version of the same question: what should we automate first? It is exactly the right question, and almost everyone approaches it backwards. They start with a tool. They saw a demo, or a competitor mentioned something, or an article promised a revolution, and now the conversation is about software. We start somewhere else entirely: with the goal the business is chasing, the team's real capacity for change, and a scoring discipline that keeps the exciting project from jumping the line. This is the same approach we run in every client engagement and teach in our trainings. Here is the thinking behind it.

Start with the goal, not the tool

The first question in any automation decision has nothing to do with technology: what is this business actually trying to do right now? In our work, the answer lands in one of three places.

• Grow revenue. "We're turning away work because we can't keep up."
• Improve margins. "We're busy but not making money."
• Get time back. "I'm working 70 hours a week and still behind."

Most owners will say all three, and that is fine, but one has to be primary, because the goal is the lens every problem gets judged through. A quoting bottleneck is transformative for a business trying to grow revenue and merely annoying for one whose real problem is margin leaking out of every job. The problem did not change. The goal did, and with it the priority.

Here is the part we tell every owner: if you genuinely cannot pick one, that is not a failure of the exercise. That is the finding. A business without a clear primary goal will struggle to prioritize anything, automation included, and goal clarity becomes the first problem to solve.

Why readiness matters more than the solution

The insight that surprises people most: before we evaluate a single problem, we evaluate the company. Not its financials. Its capacity to adopt and sustain change.

The reason is simple. An automation only creates value if it gets used, and whether it gets used has less to do with the quality of the solution than with the organization it lands in. A sophisticated build in a company that cannot absorb it will lose, on purpose, to a simpler build the team will actually run. Anyone who has watched an expensive software rollout die quietly in a drawer knows this is not theory.

So we ask a handful of blunt questions before anything gets prioritized:

• How does the owner run the operation? Is everything documented and delegated, or does the whole business live in one person's head?
• How does the owner really respond to change? Not in the kickoff meeting. Under pressure, in week three, when the old habit is right there.
• How does the team work with technology today? Paper and phone calls, a couple of tools they tolerate, or platforms they actually lean on?
• What happened the last time this company tried something new? A team that has watched three initiatives die is not cynical, it is experienced, and it will wait you out.
• How much of the operation is written down anywhere? Could a new hire learn the job from your materials, or only by shadowing someone?

One rule we never bend: these questions get asked of the owner and the team, separately. Owners consistently rate their operation as more documented, more consistent, and more change-ready than their team experiences it. The gap between those two answers is some of the most useful information in the entire process.

The answers do not disqualify anyone. They calibrate everything. A company earlier in its journey does not get told "come back later." It gets a different first move, and the honest version of that move is usually simpler than the one the owner walked in wanting.

How do you compare problems fairly?

Once the goal is set and readiness is understood, every problem the business surfaces goes through the same three lenses. This is the discipline that keeps prioritization honest, because without a common yardstick, the loudest problem or the most recent one wins by default.

Impact

How much does solving this move your primary goal?

Scored against the one goal you picked, not in the abstract. This lens counts the most.

Recurrence

How often does this cost you time, money, or quality?

Daily friction compounds. A modest problem you hit every day often outranks a dramatic one you hit twice a year.

Effort

What would fixing it actually take?

Time, cost, and disruption. When two problems matter equally, the easier fix wins the tie.

Readiness bends every score

The same problem, in two different companies, lands in two different places.

Every score is weighted by the company's capacity for change, so the roadmap never asks a team to run something it cannot absorb. By design.

Impact asks how much solving this moves the primary goal, and it deliberately counts the most. Not "is this annoying" but "does fixing this change the number the owner said matters."

Recurrence asks how often the problem costs you. This lens exists because dramatic problems get overweighted and chronic ones get ignored. A modest inefficiency you hit every single day compounds into more damage than a painful mess that flares up twice a year, and the daily one is usually where the automation payoff lives.

Effort asks what the fix actually takes: time, cost, and how much disruption the team absorbs while it lands. When two problems matter equally, the easier fix wins the tie, because a solved problem builds momentum and a stalled project burns trust.

Then readiness does its work. Every score is weighted by the company's capacity for change, which means the same problem, scored in two different companies, lands in two different places on the roadmap. That is not a bug in the method. It is the entire point. A prioritized list that ignores who has to execute it is just a wish list with numbers on it.

Why the exciting project is usually not the first project

Two rules in our process exist specifically to protect owners from their own enthusiasm, and they are worth stealing.

A quick win has to actually be quick. The most common prioritization mistake we see is a high-impact, high-complexity project wearing a quick-win costume. It is important, everyone is excited, so it gets slotted in as the fast first move, and six weeks later it is half-built, the team is tired, and the whole initiative has a credibility problem. In our method, no problem qualifies as a quick win unless the fix is genuinely small, days to a couple of weeks, low cost, minimal disruption. The big exciting project does not get discarded. It gets sequenced honestly, as the strategic project it is, after the fast wins have built momentum and trust.

The boring prerequisite goes first. Some problems are not the highest scorers but are blocking everything above them. Nobody gets excited about standardizing how job data gets collected, but if three of your highest-priority automations all depend on clean, consistent data, that unglamorous fix moves to the front of the line. It does not become more important. It becomes first. Sequencing and importance are different questions, and conflating them is how businesses end up building impressive things on foundations that do not exist yet.

The ladder you cannot skip

The last piece is deciding what kind of fix each problem deserves, and this is where most automation advice goes wrong by assuming the answer is always "automate it." It is not. There is a maturity ladder, and it gets climbed in order.

01

Standardize

Define the process and write it down. No new tech, just clarity on how we do this here.

Where every undocumented process starts.

02

Centralize

Pull scattered data and communication into one place, usually with tools you already own.

When the process exists but lives in five channels.

03

Automate

Layer technology on a solid process to remove manual steps, enforce consistency, and scale.

When manual execution is the real bottleneck.

04

Optimize

AI, analytics, and predictive tooling on top of a foundation that already holds.

When the first three levels are stable.

You cannot skip rungs

Automate an undocumented process and you have automated the chaos.

Most owners want to start at Level 3. Most operations honestly live at Levels 1 and 2. That is not a criticism, it is the starting point, and the ladder is how you climb from there.

The order is the whole insight. When you automate an undocumented process, you do not fix the chaos. You automate it, and now it runs faster than you can catch it. When you automate before centralizing, the automation spends its life hunting for information across five channels. Every rung stands on the one below it, which is why the first move in most engagements is not software at all. It is a written process, or one shared place where the information finally lives, built with tools the company already owns.

Two honest observations from running this with real businesses. First, most owners want to start at Level 3, and most of their operations honestly live at Levels 1 and 2. That is not a criticism. The businesses we work with are usually excellent at their craft and grew faster than their systems, and Levels 1 and 2 are cheap, fast, and immediately valuable. Second, maturity is not one number for the whole company. The same business can be Level 1 on quoting and Level 3 on scheduling, so the right answer is per process, not per company, and a single fix is often a hybrid: define the process and centralize it in the same move.

If you want the hands-on version of this for a single task, the seam between what a machine should own and what stays human, we wrote that method up separately in Draw the Line. And before any problem earns a score at all, it has to clear a simpler gate: some things should not be automated in the first place.

What this looks like in practice

Put together, the sequence is short: get clear on the one goal, get honest about readiness, put every problem through the same three lenses, let the small real wins go first, and match each fix to the rung the process is actually standing on.

What makes it work is that it compounds. The first quick win does more than solve a problem. It gives the team a success, and a team with a recent success adopts the next change faster, which raises the readiness that was capping the scores, which unlocks projects that were not viable six months earlier. The businesses that get the most out of automation are not the ones that started with the most ambitious build. They are the ones that sequenced the climb so every step made the next one easier. And once something ships, the work shifts to earning trust in it, run by run.

The tools will keep changing. The discipline of goal, readiness, and honest sequencing is the part that does not.

Schedule a call and bring the list of things you have been meaning to automate. We will walk this thinking with you, and tell you honestly which one goes first and which rung it belongs on.

Prefer email? Reach me directly at john@clearoakconsulting.com and tell me the project you are most excited about. That is usually the most useful place to start the conversation.