Workforce Automation Analysis: How to Score Which Processes AI Can Actually Replace

Most automation shortlists are built the same way. Someone names the processes that feel automatable, ranks them by gut or by whatever a vendor demoed last week, and the list goes into a deck. Then it meets a budget meeting, where an opinion loses to a number every time.

A workforce automation analysis replaces the opinion with a score. Instead of arguing about which process should come first, you rate each one against the same factors, add up the points, and read the result off a scale. The processes sort themselves. And when someone asks why claims intake is ahead of loan servicing, you have a defensible answer instead of a hunch.

This article hands you the instrument. Seven factors, a weighted scoring model that lands every process on a 0 to 100 automatability score, and four action bands that tell you what to do with each result. At the end, I score one back-office process end to end so you can copy the method exactly.

Key Takeaways

• A workforce automation analysis scores each process on seven weighted factors instead of ranking by gut.
• The model sums to a 0 to 100 automatability score, then maps to four bands: automate now, augment, keep human, or measure first.
• The seven factors are volume, rules vs. judgment, standardization, data availability, error cost, SLA and compliance risk, and knowledge concentration.
• The worked example scores accounts payable invoice processing at 75, a strong candidate that still needs a human on the payment approval.
• The score is only as honest as the data behind it. Guess on the factors and you get a confident wrong answer.

Why “What Should We Automate” Is the Wrong First Question

The instinct is to open with “what should we automate,” and that question has a well-known answer: high-volume, repetitive, rules-based, low-judgment work. That is the right filter, and I have written before about how to find what to automate in operations once you can see your work clearly. But the criteria are not the hard part. The hard part is that “what” produces a list, and a list is not a decision.

Two processes can both qualify as automatable and still deserve very different treatment. One is high-volume but sits behind a compliance wall. The other is lower-volume but perfectly standardized and low-risk. “What should we automate” treats them as equals. “How automatable is each one, and how confident am I in that answer” does not.

That is a scoring question, not a brainstorming question. And the moment you make it one, the argument in the room changes from whose intuition wins to whose process scored higher. McKinsey estimates 30% of work hours are automatable by 2030. That number is useless to you until you can say which of your processes hold your share of it, and in what order they move.

The Seven Factors That Decide Automatability

Every process gets rated on the same seven factors. Each is scored 0 to 5, and to keep the model simple, a 5 always means “most favorable for automation.” That takes a little care on the last three, because they are risk factors: a good candidate scores low on the underlying risk, so we flip the scale. On those, you rate 5 when the risk is low.

1. Volume and frequency. How often does the task run? A step that fires thousands of times a month frees real capacity when automated. One that fires twice is not worth the build, no matter how mechanical it is.

2. Rules vs. judgment. How much of the task follows clear, stateable rules, and how much requires human discretion? Pure rules-following is ideal. Anything that needs interpretation, negotiation, or a coverage call is not.

3. Standardization. Are the inputs and steps the same every time, or does each instance arrive in a different shape? High exception rates are the most common reason an “automatable” task turns out to be a judgment task in disguise.

4. Data availability. Do you actually have activity-level data on how the task is performed today, or are you describing it from memory? This factor rates your evidence, not the task. It is the honesty check on the other six.

5. Error cost (inverse). If the automation gets it wrong, how expensive is the mistake? A miscode you catch in reconciliation is cheap. A wrong payment or a mispriced policy is not. Rate 5 when errors are cheap, visible, and reversible.

6. SLA and compliance risk (inverse). Does the task touch a regulated decision, an auditable record, or a service level agreement (SLA) you are on the hook for? Rate 5 when none of that is on the line. Rate low when it is.

7. Knowledge concentration (inverse). Is the task documented and performed the same way by many people, or does it live in one expert’s head? Concentrated, undocumented knowledge is both hard to automate and dangerous to remove. Rate 5 when the work is well documented and widely held.

The Scoring Model

Here is the rubric. Weights sum to 100, so a process that scored a perfect 5 on all seven factors would score 100.

How to calculate the score. Rate the process 0 to 5 on each factor. Multiply each rating by its weight divided by 5. Add the seven results. That total is your automatability score, from 0 to 100.

The weighting is deliberate. Volume and rules vs. judgment carry the most weight, 20 each, because they most determine whether automation returns anything at all. Standardization and data availability sit at 15. The three risk factors sit at 10, because they rarely disqualify a process outright. They usually do not kill the automation, they just tell you where a human control has to stay. If your operation weights risk more heavily, adjust the numbers. The value is in scoring every process the same way, not in the exact split.

Reading the Score: The Four Bands

Once you have a number, map it to an action. There are three score bands and one gate that overrides all of them.

Measure first (the gate). If you rated Data availability a 0 or 1, stop reading the total. You are scoring a process you cannot actually see, and the number is a guess dressed up as a metric. The action is to go get the data before you decide anything. An AI readiness assessment for operations exists precisely for this: it establishes what the work actually is before you rate how replaceable it is.

Automate now (75 to 100). High volume, clear rules, standardized, low risk, and you can prove it with data. Build it, keep a light human check where the risk factors flagged, and move on.

Augment (50 to 74). Real automation potential, but judgment, exceptions, or risk keep a person in the loop. AI drafts, routes, or pre-fills, and a human approves. This is where most knowledge-work processes land, and it is a feature, not a failure.

Keep human (below 50). Too much judgment, too many exceptions, too much risk, or too little volume to justify the build. Leave it with your people and revisit it after the higher-scoring work is done.

A Worked Example: Accounts Payable Invoice Processing

Let me run one process through the model end to end. Accounts payable invoice processing: receive the invoice, match it to a purchase order, code it to the general ledger, route it for approval, and schedule payment. Every operations leader knows this one, which makes it a good teaching case.

The score is 75, which puts invoice processing right at the floor of automate now, and that single number already tells you more than a shortlist would.

Look at where the points were lost. The two low ratings are SLA and compliance risk (2) and error cost (3). That is the model pointing at exactly where the human stays. You automate the high-volume, rules-based part, matching, coding, and routing, and keep a person on the payment release, where a mistake is expensive and the audit trail matters. The verdict is not “automate accounts payable.” It is “automate the matching and coding, keep a human on approval.” The score wrote that sentence for you.

Now watch how fragile it is. If you had rated Data availability a 1, because you were honestly guessing at how the work is done rather than measuring it, the gate fires and the process drops to measure first regardless of the 75. Same process, same team, completely different action, decided entirely by whether your inputs were real. That is the whole point of scoring the data separately from the task.

With scores in hand for every process, the next move is sequencing them against value and dependency, which is a discipline of its own. I cover that in how to prioritize AI projects in operations. If you want to see what a scored, prioritized output actually looks like, that is what the report produces.

Why the Score Is Only as Good as the Data Behind It

Here is the uncomfortable part. The rubric looks objective, seven factors, clean weights, a number at the end. But four of those factors, volume, rules vs. judgment, standardization, and data availability itself, cannot be rated honestly from an org chart or an output dashboard.

A claims examiner’s job title says “judgment.” The activity data might say a meaningful share of the day is rote data entry and rekeying between systems. Only one of those is true at the level automation operates on. Rate volume and standardization from memory, and you are not scoring the work, you are scoring your impression of it.

This is why the whole model rests on ground truth data: individual-level, activity-level data about what people actually do, moment to moment, rather than what the org chart implies. Capturing it used to take a year of consultants shadowing staff, and even then it was a sample. Our approach captures it automatically, so the ratings you feed the rubric come from evidence instead of impressions.

The stakes are not academic. 29% of leaders already say poor data quality undermines their AI performance, and 55% of companies that made AI-driven workforce changes say they regret it, with a consistent explanation: they acted too quickly, on data they should not have trusted. A scoring model built on guessed inputs is worse than no model, because it launders a guess into a number that looks defensible and is not. Measure twice, cut once. The rubric only earns its authority when the ratings are real.

Book a Strategy Call

You can run this rubric on your own operation this week. Where it will stall is factor four, whether you actually have the activity-level data to rate the others honestly. That is the gap we close.

In 30 minutes, we will look at where you are in your AI transition, which processes you are weighing, and what data you would need to score them with confidence. This is not a sales call. It is a working session, and you will leave with something you can take to your AI and operations teams. Book a 30-minute strategy call.

FAQ: Workforce Automation Analysis

How do you decide which processes to automate with AI? Score each process the same way instead of ranking by gut. Rate it on seven weighted factors, volume, rules vs. judgment, standardization, data availability, error cost, SLA and compliance risk, and knowledge concentration, sum to a 0 to 100 automatability score, then map that score to an action band. A defensible number beats an opinion in a budget meeting.

What makes a process a good candidate for automation? High volume, clear rules with little discretion, standardized inputs, and low risk if the automation gets something wrong. Strong candidates also have real activity-level data behind them, so you can prove the other factors rather than assume them. A process that is high-volume but exception-heavy or compliance-bound usually belongs in the augment band, with a human in the loop, not full automation.

What is an automation prioritization framework? It is a repeatable method for deciding what to automate first, rather than a one-time opinion. The framework here scores each process on seven factors, produces a 0 to 100 score, and sorts processes into four bands: automate now, augment, keep human, or measure first. Because every process is scored the same way, the output is comparable and defensible, which is what a framework is for.

Can every high-volume process be automated? No. Volume is only one of seven factors, and it carries 20 of the 100 points. A high-volume process that is exception-heavy, judgment-intensive, or wrapped in compliance risk will still score low, and the score will tell you to keep humans in the loop. Volume tells you a process is worth examining. It does not tell you the work is actually replaceable.

What data do you need to score automatability accurately? Activity-level data on how the work is actually performed, not what the org chart or an output dashboard implies. You need to see the specific steps inside a role, how often each runs, how standardized it is, and how much is rules vs. judgment. Without that ground truth, four of the seven factors are guesses, and the gate in the model sends the process to measure first for exactly that reason.