Ask a room of operators which process they'd automate first and you'll get the loudest answer, not the most expensive one. The loudest process is usually the one that annoys people. The expensive one is quiet, boring, and happens four hundred times a month.
We've now run this teardown across dozens of operations, and the gap between what teams think is costing them and what actually is runs consistently wide. Here's the model we use to close it.
First: price the work, don't rank the annoyance
Take every repeated task in the workflow and capture four numbers. Not estimates from a meeting, numbers from a week of watching.
- Frequency. How many times per week does this actually happen?
- Handling time. Minutes of human attention per instance, including the context switch to get into it.
- Error rate. How often does it get redone, and what does the redo cost?
- Delay cost. What happens while it waits? A lead going cold has a price; a monthly report being late usually doesn't.
Multiply the first two and you have weekly hours. That alone reorders most people's priority list. The task everyone complains about often turns out to be twenty minutes a week. The one nobody mentions, copying figures between two systems, is eleven hours.
The tasks worth automating first are almost never the tasks people complain about. They're the ones that have been normalised.
Second: score build effort honestly
Hours saved is only half the equation. Against it, score effort on three axes:
- Data readiness. Is the input structured, or is it a PDF someone scanned crooked? Unstructured input doesn't rule it out, but it moves the estimate.
- Integration surface. Does every system in the chain have a real API, or is one of them a desktop application from 2011?
- Decision complexity. Can the rules be written down? If three experienced people would each decide differently, you have a judgement problem, not an automation problem, and that needs a human-in-the-loop design from the start.
Third: sequence for proof, not for size
With hours saved on one axis and effort on the other, the roadmap picks itself, but only if you resist a specific temptation: starting with the biggest win.
The biggest win is usually the most complex, takes three months, and spends all your organisational goodwill before anything works. Start instead with the highest ratio of saved hours to build days that also touches a team willing to change how they work. You want a visible win inside two weeks, because the second project is far easier to fund once one thing is already running.
What this looks like in practice
A services client came to us certain they needed an AI sales agent. The teardown said otherwise: their sales team was fine. Their problem was that every new client required eleven manual onboarding steps across four tools, taking nine working days, and roughly one in six got stuck waiting on a document nobody had chased.
We built the onboarding workflow instead. Nine days became under two. The chase emails send themselves. Then, six weeks later, with the team's trust earned, we built the sales agent they originally asked for, and it landed on a system that was actually ready for it.
The one-page version
- Measure a week of real work. Don't survey; observe.
- Compute weekly hours per task and sort descending.
- Score each on data readiness, integration surface and decision complexity.
- Ship the best hours-to-effort ratio first, not the biggest prize.
- Instrument it before you scale it, a baseline you didn't capture is an ROI you can't prove.
Everything after that is engineering. The part that decides whether the project succeeds happened in step one.
Put this to work
Want this built, not just read?
Tell us the workflow that's eating your week. Thirty minutes, no deck.