How to pick which workflow to automate first

The wrong first workflow burns the budget and the trust at the same time. The right first workflow buys you a second one. Picking it is not as hard as it looks, but most teams pick on instinct and get it wrong.

We’ve sat through enough kickoff calls to recognize the pattern. Someone in the room has a workflow they want to automate. Usually it’s the workflow that frustrates them personally. Sometimes it’s the workflow that would look impressive in a board update. Almost never is it the workflow that’s most likely to ship.

Below is the rubric we use to rank candidates. It’s four dimensions, scored quickly, with a cutoff. After the rubric, the four common picking mistakes we see — each of which produces a confident answer that turns out to be the wrong workflow.

The four-dimension rubric

Dimension 1 — Frequency × duration

How often does the workflow run, and how long does each run take? Multiply them. The result is aggregate human-hours per month. This is the upper bound on the value you can capture.

A workflow that runs 200 times a month and takes 8 minutes per run is 26 hours of human time. A workflow that runs 4 times a month and takes 6 hours per run is 24 hours of human time. Roughly the same value. Very different builds. The first is amenable to automation because the pattern is repeated; the second is bespoke each time and harder to automate well.

Score: high if > 40 human-hours per month, medium if 10–40, low if < 10. Workflows below the low threshold rarely justify the build cost regardless of other factors.

Dimension 2 — Variance

How much does the workflow change from one run to the next? Stable patterns automate well. High-variance patterns produce models that work for the average case and fail noticeably on the edges.

The diagnostic question: “What percentage of runs follow the same template?” If the answer is above 70 percent, the workflow is in the green zone. Between 50 and 70, it’s amber — the build is possible but the human-in-the-loop step will be heavier and stay heavier longer. Below 50, you’re building a system that needs human judgment on every run, which means you’re not really automating it.

Dimension 3 — Failure cost

What happens when the AI is wrong? This is the most-often-skipped dimension. Teams pick high-stakes workflows because they’re important, then discover that the cost of a single wrong-but-confident output exceeds the savings from a hundred right-and-fast outputs.

Low failure cost: the wrong output goes to a human who catches it before any external impact. High failure cost: the wrong output reaches a customer, a regulator, or a financial transaction.

First workflows should have low failure cost. The team needs to learn what failure looks like before they trust the system in a high-stakes context. This is not a permanent restriction — it’s a sequencing decision. The high-stakes workflow is the third or fourth build, not the first.

Dimension 4 — Owner readiness

Is there a human owner ready to receive the output, with time on their calendar to review it during the first three months? This question echoes the readiness audit, but it’s worth scoring per workflow because the answer often varies. The workflow with the highest hours saved might be owned by the person who has the least bandwidth to onboard a new system.

Score: high if the owner has explicitly said they want this and will review outputs daily for the first month; medium if they agree in principle but their calendar is full; low if no one has been named or they’re reluctant.

Reading the rubric

A workflow that scores high on all four dimensions is the right first build. A workflow that scores high on three and medium on one is also a strong candidate.

Workflows with any low score should be deprioritized — even if the other three dimensions are stellar. A high-frequency, low-variance, low-failure-cost workflow with no owner is not actually buildable. The owner question is the constraint.

Two workflows that tie on the rubric? Pick the one with the clearer pattern of failure. Workflows where humans can articulate “here’s how this typically goes wrong” ship faster than workflows where the failure modes are diffuse, because the eval harness can be designed against known categories.

The four picking mistakes

Mistake 1 — The “most expensive person” trap

The CFO complains about a task they spend two hours on every Friday afternoon. The team takes the complaint as a signal and prioritizes that workflow because the CFO is senior and visible.

The math doesn’t support it. Two hours a week is eight hours a month — well below the threshold for a custom build. The complaint is real, but the right response is to find the CFO an off-the-shelf tool, not to build them a bespoke system.

The mistake is mistaking executive frustration for workflow importance. The two are correlated but not the same.

Mistake 2 — The “demo-able” trap

Picked because it shows well in a board update. A natural language interface to internal data, a chatbot for the help center, anything with a screenshot. The workflow is selected for visual impact rather than operational value, and the accuracy bar gets set by demo expectations rather than production reality.

These workflows usually launch, get applauded in the board meeting, then quietly degrade because no one is operating them day-to-day. Six months later they’re removed for “maintenance.”

Mistake 3 — The “AI-shaped” trap

Picked because it sounds AI-y. Anything with the word “agent,” anything that involves “reasoning,” anything that maps to a recently-announced model capability. The selection criterion is novelty rather than fit.

Some of these workflows do ship. Many don’t, because the novelty was the entire reason for picking them. When the engineering reality kicks in — eval harness, production data, owner readiness — the magic of “agentic” deflates and the team loses interest.

If you’d still pick the workflow when described in boring, mechanical terms, it’s a real candidate. If the only reason it’s on the list is the AI buzzword, take it off.

Mistake 4 — The “too critical” trap

Picked because it’s mission-important. Customer onboarding. Compliance review. Anything that touches revenue. The importance of the workflow is treated as an argument for automating it first.

It’s the opposite. High-importance workflows have high failure cost (dimension 3), which makes them the wrong first build. The team needs to learn the failure modes on a forgiving workflow before deploying AI against the workflow that pays the rent.

Sequence importance: build on the medium-stakes workflow first, learn what your eval harness misses, and only then deploy on the high-stakes one. We’ve watched teams reverse this order and lose six months recovering trust after one bad output reached a customer.

A worked example

On a recent audit, a team brought us five workflow candidates. We scored them on the four dimensions during the call:

• Sales prospecting outreach. High frequency, high variance (every prospect is different), medium failure cost (a bad email reaches a customer), high owner readiness. Net: deprioritize — variance kills it.
• Customer support ticket triage. High frequency, low variance (most tickets are one of about ten categories), low failure cost (mis-routed ticket gets caught by the receiving agent), medium owner readiness. Net: green light — the right first build.
• Contract redline assistance. Medium frequency, high variance, high failure cost, low owner readiness (legal team was skeptical). Net: not yet — the audit chapter on convergence applies.
• Internal knowledge assistant. Medium frequency, medium variance, low failure cost, no clear owner. Net: deprioritize — owner constraint.
• Quarterly board deck draft. Low frequency, high variance, high failure cost. Net: never — a bespoke high-stakes workflow is the worst possible first build.

The team had been about to start on the board deck workflow because the CEO had asked for it. The rubric named that as the worst candidate on the list. We built support ticket triage instead. It shipped in seven weeks and was operating the team on day 70. The team used what they learned to scope contract redline as build two — after running the convergence work the original audit had recommended.

What to do with this

Take three to five candidate workflows. Score each one on the four dimensions. The right first build will usually be obvious. If it isn’t, the rubric is telling you that none of the candidates are quite ready — go back to the readiness audit and check the foundation.

The next chapter on why most AI POCs don’t ship to production covers what happens once you’ve picked the workflow and committed to building.