Pick Your First Automation: Prioritizing the Toil Map
The most painful process on your list is usually the wrong first thing to automate. Pick for readiness instead: work that comes up often, has clean handoffs and needs little access. Your first automation is the one everyone remembers.
Part 3 of the Toil Audit series. New to the series? Start with Part 1: Find the Toil: The Required Work Discovery Method.
The Toil Map Isn't a Priority List
Every company has toil: the required, repetitive work the business depends on and nobody wants to do. Ask people in different roles what their job requires that they'd stop doing tomorrow if they could, and the answers that keep coming back show you where it is (Part 1 covers the method). Look at how that work moves between people, and you'll see which handoffs are ready for automation and which still depend on someone quietly filling the gaps (Part 2 covers that).
Put those two together and you have a toil map: the toil that shows up across the organization, with a note on each item saying whether it's ready to automate or needs fixing first.
It's tempting to read that map as a ranked list and automate the most painful item first. That's usually the wrong read. The map tells you where the required, repetitive work is. It doesn't tell you which item can be automated successfully right now, and readiness, not pain, should decide the first target. Mixing up the two is one of the most common ways a promising AI initiative stalls before it produces anything.
Why the Biggest Pain Point Is Usually the Wrong First Pick
The most painful item on a toil map usually got that way for reasons that also make it a poor first target. It's often the most complex process, the one touching the most systems, the one with the messiest handoffs, or the one with the highest stakes if something goes wrong: customer-facing, compliance-sensitive, or claimed by several departments that would resist seeing it automated without a lot of buy-in.
None of that means it should never be automated. It means it's rarely the right first one. A first attempt that fails publicly or expensively makes every later automation conversation harder, however sound the method was. The organization won't remember "the process was too complex for a first attempt." It will remember "we tried AI and it didn't work."
What Actually Makes a Good First Pick
A strong first target clears three bars at once:
- It comes up often. The toil shows up daily or weekly, so fixing it produces an improvement people feel, not a marginal one.
- Its handoffs are clean. Each step produces something the next step can use as it arrives, the data is usable, and nobody is quietly patching the gaps. Confirmed by looking at how the work really moves, not assumed from a process diagram.
- It needs little access. The automation can do its job without broad or sensitive permissions.
Notice what's missing from that list: how painful the task feels, how visible it is to leadership, and how impressive the demo would look. Those are fair tiebreakers once a few candidates clear the bar. They're a poor first filter, because they track visibility more than the odds of success.
A demo is especially weak evidence. In a Harvard Business School field experiment with Boston Consulting Group consultants, people using AI on tasks inside its capabilities finished more of them, faster, and with better quality. On a task the researchers picked to sit just outside those capabilities, consultants using AI were 19% less likely to reach a correct answer than those working without it. The researchers call this a jagged frontier: tasks that look similar in difficulty can land on either side of it. You find out which side your task is on by running it on real work, which is one more reason to start where a miss is cheap.
The Real Goal of the First Automation
The goal of the whole initiative is to cut a meaningful share of the toil across the business. The first automation's goal is narrower: prove the organization can do this at all. Prove the discovery method surfaces real targets. Prove the process mapping catches the right prerequisites. Prove the automation holds up under real use. And prove that the people whose work it touches trust the result.
That's a different bar from "solve the hardest problem," and a much more achievable one. A modest first win that works reliably does more for the initiative than an ambitious first attempt that impresses in a demo and breaks in production.
Design the Human Oversight Before It Goes Live
Every automation needs an explicit answer to two questions: where does a person stay in the loop, and what would have to be true to change that? Answer both before launch, not after something breaks.
Start with close human review at the point where a wrong answer would cost the most. Loosen it only when the automation has earned it, with real volume over real time, against criteria you wrote down at the start. Let the evidence move it the other way too: a confident wrong answer, or a change to the model or the process, should bring closer review back until the record rebuilds. Human-in-the-Loop Is a Stage, Not a Policy covers how to set those stages and their exit criteria.
What to avoid is oversight that changes by drift: loosened because things seem fine, or bolted on in a hurry after a failure a better initial design would have caught.
Define Success Before You Start
Before the first automation goes live, write down what "this worked" means at 30, 60 and 90 days. Not "people seem happier with this process," but things you can check:
- volume processed without a human correction
- time saved against a real baseline
- error rate compared with the manual process it replaced
- whether the people whose work it touches would choose to keep using it
Deciding this up front is the only way to have an honest conversation later about whether it worked, rather than one shaped by whoever is most invested in declaring victory. It's also the evidence you need to loosen oversight on purpose rather than by drift.
How a Good First Win Sets Up the Second
A successful first automation fixes more than one process. It gives you internal proof that the method works, it builds trust with the people whose work is next in line, and it gives leadership a concrete story to point to instead of an abstract pitch about what AI might do.
That's the case for choosing readiness over pain on the first pick. It doesn't mean picking the safest target forever. The harder, higher-value items on the toil map still need attention. They just get attempted with credibility and a proven method behind them, instead of being the initiative's first and highest-stakes bet.
A practical place to start: take the handful of toil items that come up most often across your organization and check each one against the three bars above. Start with the one that clears all three, even if it isn't the one people complain about most.
Subscribe to get the last post in this series: the engineering concept behind toil, and why it belongs in every business leader's vocabulary.
This article was drafted with AI assistance and reviewed and edited by Matt before publishing.
About the Author: Matt Shirel writes Praxis CTO, exploring what real technology leadership looks like for growing companies that have outgrown ad hoc decision-making. He brings over 20 years in enterprise IT — spanning infrastructure architecture, cloud strategy, and technology budget ownership — and works hands-on in applied AI, building multi-agent and RAG workflows with tools like n8n and AI coding agents. Picking the right first target, not the most dramatic one, is usually the highest-leverage decision in an AI initiative, and the one most often gotten wrong.
