Automate the process with high volume, low variability, and low blast radius — where blast radius means what breaks if the system gets it wrong and nobody notices for a week.
Most automation programmes stall because the first three projects were chosen for visibility rather than for blast radius. The executive-facing process gets automated first because it is the one someone complained about, it turns out to be the one with the highest consequence of error, it fails quietly, trust collapses, and the programme never gets a fourth project.
This is the sequencing method we use, the screen that drives it, and the categories that should stay manual longer than anyone expects.
Why sequencing beats tooling
The tooling question gets the attention and it is close to irrelevant. Most platforms can execute most workflows, and swapping them is weeks of work. The sequencing decision determines whether the programme earns a second round of funding, and it is nearly irreversible in its effects — a first project that fails badly poisons the well for two years.
The economics compound in both directions. A first automation that works frees capacity, which funds the second, which is chosen with better information because the first taught you how your processes actually behave. A first automation that fails silently consumes the capacity it was meant to free, plus the trust required to try again.
Pick for compounding, not for the loudest complaint.
The three-axis screen
Score every candidate process on three axes, 1 to 5.
Volume
How often does it run? Weekly is not worth automating. Fifty times a day is.
Be precise rather than impressionistic — count it. Processes people describe as constant are often weekly, and processes nobody mentions turn out to run hundreds of times. The instrumentation step is not overhead; it routinely changes the ranking.
Variability
How much do the inputs differ? This determines whether you need automation or AI automation, and AWS draws the line clearly: traditional automation "is best suited for repetitive tasks… that are the same every single time" and "falls short… with any task that doesn't have a certain outcome," while AI automation handles inputs that vary.
Low variability is cheaper, faster and more reliable. High variability is where the value is and where the failures live. Score it honestly — teams systematically underestimate it, because the exceptions are handled by a person who stopped mentioning them years ago.
Blast radius
The axis nobody scores, and the one that decides whether the programme survives.
If this process produces a wrong output, what happens, and how long before anyone knows? A miscategorised internal ticket is an annoyance discovered in minutes. A wrong number in a client invoice is a relationship problem discovered in weeks. A misrouted lead is revenue that never appears and is never counted, because nothing shows up to be counted.
Score blast radius inversely — 5 means low consequence and fast detection, 1 means high consequence or slow detection.
The screen
Priority = Volume + Variability-fit + Blast-radius score.
Where variability-fit means: does the technology match the variability? Low-variability process with rules-based automation scores 5. High-variability process with AI scores 5. Mismatch scores low in either direction — using AI on a fixed process is overpaying, and using rules on a variable one is building something that breaks constantly.
Rank candidates. Start at the top. The first project should score high on all three, not brilliantly on one.
A worked example of the screen
Four candidate processes from a mid-sized operation, scored honestly.
| Process | Volume | Variability-fit | Blast radius | Total |
|---|---|---|---|---|
| Invoice data entry into the ledger | 5 | 5 (fixed format, rules-based) | 4 (errors visible at reconciliation) | 14 |
| Inbound enquiry triage and routing | 5 | 4 (free text, AI-suited) | 3 (misroute is slow to detect) | 12 |
| Monthly client reporting pack | 2 | 4 | 4 | 10 |
| Refund approval under a threshold | 4 | 3 | 1 (money moves, detection slow) | 8 |
The refund process is the one that gets proposed first in real life, because it is the one finance complains about. It scores last, and it should — money moving on a wrong judgment with slow detection is precisely the profile that ends automation programmes.
The invoice entry process is dull, nobody asked for it, and it is the right first build. High volume, fixed format, and errors surface at reconciliation within days. It frees real capacity and it fails safely.
Note what the scoring did: it inverted the intuitive order. That is the point of scoring rather than discussing.
The first three workflows
A worked pattern, because the abstraction hides the judgment.
First — high volume, low variability, low blast radius. Data movement between systems, routine categorisation, scheduled reporting. Boring, fast to build, and it produces the credibility and freed capacity that fund everything after. Do not skip this to do something impressive.
Second — high volume, higher variability, still low blast radius. Now introduce the judgment layer where a mistake is cheap: drafting, triage, first-pass classification with review. This is where you learn how your review architecture performs before it matters.
Third — chosen from what the first two taught you. Not from the original roadmap. The first two projects will have revealed that a process you thought was uniform has nine exceptions, or that the volume was concentrated in a segment you had not noticed. Re-rank before committing.
Programmes that plan all twelve projects up front and execute them in order are the ones that discover in month eight that the plan was written without information.
The instrumentation step nobody budgets for
Everything above depends on having real numbers, and most organisations do not. Budget two to three weeks for instrumentation before any build decision, and treat it as part of the project rather than a delay to it.
What to measure per candidate process. How many times it ran in the last 90 days. How long each instance took, including waiting time rather than just handling time. How often the output was wrong or had to be redone. What proportion were exceptions, and what the exceptions actually were.
Where the numbers come from. System logs where they exist, a two-week manual tally where they do not. A tally is imperfect and still better than estimates, because estimates are systematically wrong in a specific direction: people overestimate the frequency of processes they dislike and underestimate the frequency of ones that are routine.
What this step reliably surfaces. That the highest-volume process is not the one anyone named. That a process believed to be uniform has nine variants. That the real cost is waiting time between steps rather than handling time within them — which sometimes means the answer is not automation at all but a routing change.
That last finding is common enough to be worth stating plainly: instrumentation occasionally reveals that the process does not need automating, it needs redesigning. Finding that out in week two costs a fortnight. Finding it out after the build costs the build.
What shouldn't be automated first
This is the section missing from every guide in this category, and it is the more useful half.
Anything where failure is silent. If a wrong output produces no signal — nobody complains, nothing errors, no number moves visibly — it will run wrong for weeks. Either build detection first or leave it manual. Silent failure is the defining risk in automation work and it is consistently underweighted.
Anything you cannot yet measure. If you do not know the current volume, error rate and cycle time, you cannot prove the automation improved anything, and you will not be able to defend the programme's next round of funding. Instrument first.
Anything a person is still redesigning. Automating a process that is actively changing means rebuilding it repeatedly. Wait until it has been stable for a quarter.
Anything where the exception is the point. Some processes look repetitive but exist because a person exercises judgment on the edge cases, and the routine cases are incidental. Automating the routine 80% removes the context that person used to handle the 20%, and the exceptions get worse.
Anything client-facing without a review layer. Not never — first. Earn the reliability data on internal processes before pointing a system at your customers.
Where the data disagrees
There is a genuine prioritisation dispute here, and it produces materially different roadmaps: should sequencing be driven by value or by risk?
Position A — sequence by value. Rank candidates by hours saved or revenue touched, and start with the biggest. The argument is straightforward: automation is an investment, investments are ranked by return, and starting with a low-value process to be safe wastes the programme's most valuable asset, which is executive patience. Vendors generally favour this, and the ROI case is easier to write.
Position B — sequence by risk. Rank by blast radius and start with the safest, regardless of value. The argument is that automation programmes fail organisationally rather than technically, and a high-profile early failure ends the programme entirely — so the first project's job is not return, it is credibility.
CONTESTED. Both are defensible, and which is right depends on something neither camp usually states: whether you have organisational trust to spend.
Our read. Sequence by risk first, value second, and treat that as a phase rather than a philosophy. For the first two projects, blast radius dominates — you are buying the right to do more. Once the programme has a track record and a monitoring layer that has caught a real failure, switch to value ranking and go after the big processes, because by then you can detect problems before they compound.
Organisations that skip the credibility phase mostly do not get to the value phase. Organisations that never leave the credibility phase automate trivia for two years and the programme quietly defunds itself. The switch usually comes somewhere around the third or fourth successful workflow, and the signal is that monitoring has caught something before a human did.
What would change our position: reliability and detection tooling good enough that blast radius stops being a meaningful differentiator. It is improving, and it is not there.
What "done" looks like
Agree this before building, because "it works" is not a specification.
- Accuracy threshold. What error rate is acceptable, measured how, over what sample.
- Detection. How a failure surfaces, to whom, within what window.
- Fallback. What happens when it fails — queue for human handling, or stop.
- Parallel period. How long it runs alongside the manual process before the manual path is switched off. Skipping this is the most common cause of a bad first month.
- Ownership. Who maintains it, and whether you hold the credentials, code, prompts and documentation. The full version of that check is in what an AI automation agency builds and what you own.
What to do in the next ninety days
First thirty days. List candidate processes and instrument the top ten. Volume, cycle time, error rate, exception frequency. You will re-rank once the real numbers arrive — that is the point.
Days thirty to ninety. Build one, properly, including review and monitoring. Run it in parallel with the manual process. Measure both.
Beyond ninety days. Switch off the manual path only when the parallel data supports it, then re-rank the list with what you learned before choosing the second.
The date a workflow ships is not the date you know whether it works.
Where this goes next
Two shifts worth planning for.
Blast radius is going to matter more, not less. As systems take on more judgment, the failure mode shifts further from loud errors toward plausible wrong answers. A rules engine that breaks stops; a judgment layer that drifts keeps producing confident output. Detection architecture is the discipline that will separate programmes that scale from programmes that quietly accumulate bad decisions.
The scarce skill is becoming process design, not build. Assembly keeps getting cheaper. Deciding what a system is permitted to decide, and what happens at the boundary, does not — and it is a judgment built from having watched automations fail in real operations. Teams should be hiring and buying for that, and increasingly they are.
Run the three-axis screen against your own process list.
If you want the instrumentation done properly before you rank — real volume, cycle time, error rate and exception frequency rather than what people believe them to be — that is the first phase of an AI automation engagement, and it is the phase that changes the ranking most often. WKND has been building growth and operations systems since 2018 across more than 400 brands, with 20+ years of collective DTC and B2B experience behind the work.
