Ask a department which work to automate first and you get the list of things people hate. It is a useful list, but it measures irritation, and irritation and cost are only loosely related. The three hours a week that vanish in twelve minute slices barely register as a complaint. The unpleasant quarterly report that everyone mentions in the first interview might cost twenty hours a year.
So the first build is a ranking problem, and it is worth being explicit about the number you are ranking on. Otherwise the choice gets made by whoever spoke most forcefully in the workshop.
The number to rank on
Hours returned per month, divided by weeks to build. That is it. Everything else is a filter applied after the sort.
Hours returned comes from three factors you can count rather than estimate. How often the workflow runs, from the source system rather than from memory. How long one run takes, from watching somebody do it and timing it. And the share of that time an agent can actually take, which is almost never all of it, because someone still reads the output for a while.
A worked example. Suppose a workflow runs 40 times a week and takes 12 minutes. That is 8 hours a week, roughly 35 hours a month. If an agent handles 80 percent of the volume end to end and the rest goes to review, call it 25 hours back. At six weeks to build, the ranking number is about 4.
Now the quarterly report that three people complain about. Three days of work, four times a year, so 24 hours a quarter or 8 hours a month. A single run has more distinct decisions in it than the frequent workflow has in a month, so it takes longer to build, say eight weeks. The ranking number is 1. It is a fifth of the value, and it is the one everybody named.
Write the estimates down before you rank, including the ones you are unsure about, and mark the confidence. A build estimate is a guess, and a guess you wrote down is one you can learn from. A guess you kept in your head just becomes the schedule.
Frequency beats duration
Two workflows can return the same hours per month, one running 200 times and one running twice. Take the frequent one, for reasons that go beyond the arithmetic.
You get a verdict sooner. A workflow that runs 200 times a month produces enough shadow mode comparisons in two weeks to know whether the agent is right. At two runs a month, the same confidence takes a year, and in the meantime nobody can tell whether the build worked.
Corrections arrive while you can still act on them. The first version of any agent is wrong about something specific. On a frequent workflow you find it in week one, fix it, and watch the fix land. On a rare workflow the flaw surfaces once, gets patched from one example, and the next chance to check the patch is months away.
Rare workflows have less repetition to exploit. A three day process is usually thirty different steps done once each, and every step needs its own rules. A frequent one is a few steps done hundreds of times. Cost per hour returned is much lower on the second kind.
And frequency carries a cost that never shows up in a time study. A task that interrupts someone eight times a day fragments the day around it. Twelve minutes of work costs more than twelve minutes of attention.
The exception rate trap
Here is the estimate that goes wrong most often. A workflow looks uniform, the agent is built for the standard path, and the hours returned come in far below the number in the map. The cause is nearly always the exception rate, and specifically what happens on the exception path.
Two workflows can both throw 25 percent exceptions and be completely different investments. In the good case an exception is self contained. The agent files it with a reason, somebody handles that one case without needing to know anything about the other 75 percent, and the saving is close to proportional. In the bad case, handling an exception means loading the whole context anyway. The reviewer has to understand the batch, check what the agent already did, and then decide. There the 25 percent can eat most of the benefit, because the expensive part was never the typing.
Measure the rate before you commit, from data rather than opinion. Pull 200 recent cases, have the person who does the work mark each one as standard or not, and ask what each exception required. It takes an afternoon and it is the single best predictor of whether the build pays back. My rule of thumb is simple. Above roughly 20 percent exceptions where each one needs the full context, the workflow moves down the list until the standard path can be pulled out more cleanly.
Then use reversibility as the tiebreak. Two candidates with similar numbers are not equal if one drafts internal text and the other sends invoices to customers. A first build should be one where a mistake in week two costs a correction and an apology inside the team. That is not caution for its own sake. The first build sets whether anyone trusts the second, and an early public error costs more than the schedule it saved.
Why the loudest complaint is rarely first
The workflow people complain about loudest is loud for reasons that usually make it a bad first build.
It is unpleasant rather than frequent. Tedium and volume are different things, and the tasks that generate the most grumbling are often the rare, awkward ones.
Or nobody agrees what the right output is. This one is the real disqualifier. If two experienced people would handle the same case differently and both defend their answer, you cannot write a pass mark, and without a pass mark shadow mode has nothing to compare against. That disagreement is worth resolving, and it is a management job, not an agent build. Automating a contested process just makes the disagreement run faster.
Or it is loud because it is visible to someone senior, which tells you about reporting lines rather than hours.
None of this means ignore it. The loud workflow usually belongs in the queue as build two or three, and in the meantime you owe it an explicit reason, in writing, for why it is not first. People accept being second when the arithmetic is on the page. They do not accept a decision that looks like the consultant preferred something easier.
What the first build needs besides a good score
Three filters after the sort, and they can all veto the winner.
One system, or two at most. Every additional system adds credentials, rate limits, a permission model and a way to fail. A high scoring workflow that spans five tools is a second or third build.
A named owner who can decide. Somebody has to answer questions within a day and sign off the rules. Not a committee.
A number the sponsor already tracks. If the workflow's improvement shows up only in a metric you invented for the project, the build will be judged on vibe six months later. Pick the workflow whose result lands on a number that was already on someone's dashboard before you arrived, and agree what it reads today.
The ranking is not the hard part. Holding to it when the loudest complaint is not at the top is.