Which Processes to Automate First | 2V Automation
A weighted scoring framework to pick the right automation candidates - ROI, frequency, error rate, stakeholder count, and complexity. Plus a worked example.
Jump to a section
- The five criteria that actually matter
- Score each candidate, criterion by criterion
- The formula
- A worked example: ten candidate processes
- Why the weights look the way they do
- Adjusting the framework for your situation
- What the framework deliberately leaves out
- How to run the workshop
- Common failures of the framework
- What to do with the result
- Related reading
You have twenty candidate processes. You can fund two or three this quarter. Which ones? This guide is the scoring framework we use with clients to make that call defensibly - not a vibes-based pick, not the loudest stakeholder’s preference, an actual model.
You can run it in a spreadsheet. By the end of this post you’ll have one.
The five criteria that actually matter
Most automation prioritization frameworks have ten to fifteen criteria. That makes them hard to use because the criteria correlate (frequency and ROI, complexity and risk) and the scoring becomes arbitrary. After running this with dozens of teams, five criteria explain the vast majority of “should we do this first” decisions:
- Frequency - how often the process runs
- Touch time - how much human time it consumes per run
- Error rate and cost of errors - how often it goes wrong and what that costs
- Implementation complexity - how hard it is to build
- Stakeholder buy-in - whether the team that does it wants this
Each one is scored 1-5. Weights matter (frequency × touch time is most of the value; complexity and buy-in mostly affect the probability of success). The formula is straightforward.
Score each candidate, criterion by criterion
1. Frequency (weight: 3)
How often does this process run?
| Score | Frequency |
|---|---|
| 1 | A few times a year |
| 2 | Monthly |
| 3 | Weekly |
| 4 | Daily |
| 5 | Multiple times per day |
This drives the volume side of the ROI math. A process that runs three times a year almost never justifies automation, regardless of how painful each run is. A process that runs 50 times a day produces compounding savings even if each run is small.
2. Touch time (weight: 3)
How much human time does each run consume? Include all hands, not just the primary one.
| Score | Per-run touch time |
|---|---|
| 1 | Under 5 minutes |
| 2 | 5-15 minutes |
| 3 | 15-60 minutes |
| 4 | 1-4 hours |
| 5 | 4+ hours |
Multiply this by frequency to get annual touch-time savings potential. (We don’t multiply them in the framework - we weight them equally and sum - but they’re the two drivers of the time-saved component.)
3. Error rate × cost of errors (weight: 2)
How often does the manual version go wrong, and what does each error cost?
| Score | Error impact |
|---|---|
| 1 | Errors are rare and easy to fix |
| 2 | Occasional errors, recoverable downstream |
| 3 | Errors happen monthly, cost a few hours of rework each |
| 4 | Errors happen weekly, customer-visible or financially material |
| 5 | Errors are common AND costly (customer churn, financial loss, compliance exposure) |
A 4 or 5 here often justifies automation even when frequency and touch time are modest. We’ve seen finance processes scored 2 on frequency and touch time but 5 on error cost (single-digit-percentage chance of a $50K invoice going out wrong) that absolutely justified automation.
4. Implementation complexity (weight: -2)
This is a negative weight - complexity reduces score. Estimate the build effort.
| Score | Complexity |
|---|---|
| 1 | One system, well-documented API, clear rules |
| 2 | Two systems, both modern APIs |
| 3 | Three systems, mostly modern, one edge case |
| 4 | Multiple systems, one with poor API or RPA needed |
| 5 | Many systems, legacy components, undocumented logic, AI judgment required |
Complexity isn’t always a deal-breaker. But for first-wave projects, lower is better. You build operational muscle on the 1s and 2s; you tackle the 4s and 5s in wave two when your team has confidence and the platform’s installed.
5. Stakeholder buy-in (weight: 2)
Does the team that owns the work want this to happen?
| Score | Buy-in level |
|---|---|
| 1 | Team is hostile or skeptical |
| 2 | Team is indifferent |
| 3 | Team is open but not advocating |
| 4 | Team is asking for it |
| 5 | Team is desperate for it; this is on their wish list |
Adoption is everything. Automations the team doesn’t want are usually quietly bypassed within a quarter. The team that requested the automation will use it, defend it, and report the bugs that need fixing.
The formula
Total score = (Frequency × 3) + (Touch time × 3) + (Error impact × 2) − (Complexity × 2) + (Buy-in × 2)
Range: −10 (max negative complexity, zero everything else) to +50 (max positive on everything, lowest complexity). In practice, scores cluster between 5 and 35.
A useful rule of thumb:
- 30+ : strong candidate, build this quarter
- 20-29: good candidate, build this year
- 10-19: keep on the list, revisit when wave-one items ship
- Under 10: don’t automate this; either eliminate it or accept manual
A worked example: ten candidate processes
Below is a real-shape (anonymized) example from a $20M SaaS company. Their team came up with these candidates during a workshop.
| # | Process | Freq | Touch | Errors | Complex | Buy-in | Score |
|---|---|---|---|---|---|---|---|
| 1 | New customer onboarding sequence | 4 | 4 | 4 | 3 | 5 | 32 |
| 2 | Lead routing from web forms | 5 | 2 | 2 | 1 | 5 | 31 |
| 3 | Monthly invoice generation | 2 | 4 | 5 | 2 | 4 | 24 |
| 4 | Support ticket triage | 5 | 3 | 3 | 3 | 3 | 24 |
| 5 | Sales handoff to CS | 3 | 3 | 4 | 3 | 4 | 22 |
| 6 | Renewal forecast spreadsheet | 1 | 5 | 3 | 4 | 2 | 14 |
| 7 | Marketing campaign reporting | 3 | 4 | 2 | 3 | 2 | 19 |
| 8 | Vendor invoice processing | 3 | 3 | 4 | 4 | 3 | 18 |
| 9 | Compliance documentation pulls | 1 | 4 | 3 | 5 | 3 | 9 |
| 10 | Custom contract redlines | 2 | 4 | 3 | 5 | 2 | 12 |
The framework says: do #1 and #2 first. #3, #4, #5 are good wave-two candidates. #6 and #9 should probably be eliminated or simplified before automation. #10 is too complex for early wave; revisit when the team has more experience.
In practice, this company built #2 first (it was easiest and the team was begging for it), shipped it in two weeks, then tackled #1. Six months later they had completed wave one and were starting wave two. The scoring matched the actual experience well.
Why the weights look the way they do
A few notes on calibration.
Frequency and touch time get equal weight (3 each). They’re the two multipliers in the time-saved math. A 5 on one and 1 on the other still produces meaningful savings; both at 4-5 is where the real wins live.
Error impact has lower weight (2). It compensates for cases where frequency is low but the error stakes are high. Without it, finance and compliance processes get under-prioritized. With too much weight, you get pulled into low-volume work.
Complexity is negative-2. Strong enough to filter out the 5s in early waves, not strong enough to disqualify a great-fit process that happens to be moderately complex. Adjust if your team is very new to automation (push complexity weight to -3) or very experienced (drop to -1).
Buy-in is +2. Adoption is the real determinant of success after the build. Without buy-in, a perfect automation gets bypassed. With strong buy-in, even rough automations get used and improved.
Adjusting the framework for your situation
A few common modifications:
- Heavy regulatory exposure? Add a “compliance value” criterion at weight 2. Score it 5 for processes where automation reduces audit risk.
- Highly seasonal business? Discount frequency by what fraction of the year the process runs at peak. A monthly cadence that becomes daily during a 2-month peak should reflect that.
- AI components in some workflows? Add an “AI suitability” criterion. Score it 5 for processes with clear judgment steps (classification, extraction, drafting) and 1 for purely deterministic flows.
- Very large team? Add a “blast radius” criterion. Score it 5 for processes that affect many people; pick those first for stakeholder impact.
The base framework above works for most mid-market companies. Calibrate as your context demands.
What the framework deliberately leaves out
Several criteria appear in other prioritization models that we’ve intentionally excluded:
- ROI calculation. It’s tempting to score expected ROI directly. The reason we don’t is that ROI estimates before you’ve built anything are usually wrong. Frequency × touch time × error impact is a better proxy.
- Strategic fit. Strategic fit means “the CEO likes it.” That’s a separate decision; if there’s an executive mandate, you don’t need a framework.
- Vendor or tool preference. Pick the tool after you pick the process, not before.
- Technical novelty. Don’t pick processes because they let you try a new technology. Pick them because they save the business work.
How to run the workshop
Practical mechanics for putting this in front of a team:
Step 1: Open candidate list. Ask each team to nominate 3-5 processes. You want 15-25 candidates total before scoring.
Step 2: Rough scoring as a group. Walk through each candidate, score it together. This goes faster than you expect - most rows take 2-3 minutes.
Step 3: Calculate totals. Spreadsheet. The formula above. Sort descending.
Step 4: Review the top and bottom. Are the top 3 surprising? Are the bottom 3 obviously low-value, or are they things the framework is undervaluing? Adjust scores or weights if the model says something is high-priority but your gut says no - usually the gut catches something the framework missed.
Step 5: Commit. Pick the top 2 or 3 for the next quarter. Get them on the roadmap with named owners.
This whole workshop runs in 2-3 hours. It’s much faster than the endless debate-without-data that usually happens.
Common failures of the framework
Three places we’ve seen this go wrong:
1. Inflating frequency. Teams sometimes score frequency as “if we got this working, it would run constantly” rather than “current frequency.” Score the current state.
2. Ignoring buy-in. Skipping the buy-in criterion to “be objective.” The result is automations that score 35 on paper and get used by nobody.
3. Overestimating complexity. Engineers tend to over-score complexity because they’re imagining the perfect solution. Score against “minimum viable automation that solves 80% of the case,” not the full enterprise version.
What to do with the result
The top 2 or 3 go to the roadmap. The next 5 stay on the list for wave two. The bottom of the list either gets eliminated (low-value work) or accepted as manual (low-frequency work where automation doesn’t pay back).
Run the workshop again every 6-12 months. The list will have changed - wave-one items will have shipped, new candidates will have emerged, business priorities will have shifted. The framework stays the same; the candidates rotate through.
Related reading
- What is business process automation?
- Complete guide to business process automation
- BPA best practices
- How to improve operational efficiency
- Automation ROI calculator
- Workflow cost calculator
- Solutions: operations automation, sales automation
If you want help running this exercise - or just an outside read on which of your processes will pay back fastest - our Efficiency Scorecard does it in 15 minutes with no commitment. Free, and the output is yours.