Step 2: Prioritized Review

What we look for

Expected return is usually some function of frequency × per-instance cost. We multiply frequency (per week or per month) by realistic per-instance time, plus an estimate of indirect cost — context-switching, mistakes that have to be undone later, customer-experience hits. A workflow that runs 200 times a month and takes 10 minutes each is a different conversation than one that runs three times a month and takes two hours.

Implementation difficulty is the harder axis to estimate honestly. We deliberately write the difficulty estimate as if a developer you haven't hired yet will be doing the implementation — not as if we're doing it. This keeps the estimate calibrated to a market rate rather than to our optimism. Difficulty includes both the build cost (how long does it take to get the first working version) and the maintenance cost (how often does this thing break, how complex is the recovery).

Then we look for the obvious wins: workflows that are high-return, low-difficulty, low-risk. These usually go to the top of the recommendations list. And we look for the obvious skips: workflows that are low-return regardless of difficulty, or high-difficulty with marginal payback.

Common mistakes at this stage

Optimizing the painful step instead of the bottleneck. Sometimes the workflow step that feels worst — the one your team complains about most — is actually downstream of the real constraint. Automating the painful step doesn't make the workflow faster; it just moves the wait. We flag this explicitly when we see it.

Treating "more automation" as automatically better. A workflow that gets done by a human in 4 minutes with 99% reliability is sometimes the right answer. Automating it might cost three months of engineering time and introduce a new failure mode. The right output of this step is sometimes "don't automate this one."

Underestimating maintenance. Automations rot. APIs change, vendors discontinue features, business rules drift. A workflow that takes one engineer-week to build and one engineer-day per quarter to maintain has a very different lifetime cost than one that builds in the same week and never breaks. We include maintenance cost in the difficulty estimate.

What this step looks like in practice

You receive a one-page ranking. Each workflow from the inventory gets a row showing: estimated annual time recovered (in hours and rough dollar terms), implementation difficulty on a low/medium/high scale, a one-sentence justification for the ranking, and a status: 'recommended,' 'maybe,' or 'not yet.' The page is short on purpose. You should be able to look at it and immediately know which two or three workflows we think are worth talking about further.

Often the most surprising row on this page is the "not yet" entry — a workflow you came in expecting to automate, ranked low. We always explain why. The "why" is the actually-useful output, more than the ranking itself.