Every automation program begins with the same meeting. Department heads are asked what should be automated, everyone names the process that annoys them most, and the resulting list is a collection of unrelated irritations ranked by whoever spoke with the most conviction.
The problem with that list is not that the items are wrong. It is that the loudest pain is rarely the largest opportunity, and the largest opportunity is rarely the right thing to build first. Selection has to balance two different questions — which process delivers the most value, and which process best positions the program to keep going — and those questions have different answers.
What follows is a scoring approach that ranks candidates on evidence rather than volume of complaint, a set of disqualifiers that should remove processes from consideration regardless of score, and a sequencing method that turns a ranked list into a roadmap.
Build the Candidate List Properly
Before scoring anything, the list needs to be real. Two techniques produce better candidates than asking people what they want automated.
Follow the spreadsheets. Every spreadsheet that exists to move data between two systems marks a process gap. Every spreadsheet that multiple people maintain versions of marks a coordination gap. Inventory them and you have a map of where the organization's manual glue lives.
Follow the shared mailboxes. Any address like ap@, hr@, or support@ is an unstructured work queue with no state tracking, no SLA, and no visibility. Volume in those mailboxes is a direct proxy for automation opportunity.
Between them, these two sources typically surface twice as many genuine candidates as a round of stakeholder interviews, and they surface them with evidence attached.
Score on Three Axes
Rate each candidate 1 to 5 on volume, variability, and value. Multiply rather than add — a process that scores badly on any single axis should not be rescued by strength elsewhere.
Volume — how many times the process runs per month.
| Score | Frequency |
|---|---|
| 1 | Under 50 |
| 2 | 50-200 |
| 3 | 200-1,000 |
| 4 | 1,000-5,000 |
| 5 | Over 5,000 |
Volume is the most reliable predictor of return, because automation cost is largely fixed while benefit scales with repetition. It is also the axis most often overridden by executive preference, usually in favor of a low-volume, high-visibility process that will not pay back.
Variability — how consistently the process runs the same way. Score this inversely: 5 means low variability.
| Score | Characteristics |
|---|---|
| 5 | One path, structured inputs, deterministic rules |
| 4 | Two or three known variants, occasional exceptions |
| 3 | Several variants, meaningful judgment on 15-30% of cases |
| 2 | Highly case-dependent, unstructured inputs |
| 1 | Essentially bespoke each time |
Variability is where estimates go wrong. Teams score a process a 4 based on the documented procedure and then discover in build that the documented procedure covers 60% of actual cases. The honest way to score this axis is to pull a sample of thirty real instances and count how many followed the standard path.
Value — what a unit of improvement is worth, combining direct cost per transaction, error cost, and value trapped by delay.
| Score | Indicators |
|---|---|
| 5 | High cost per transaction, expensive errors, delay carries direct financial cost |
| 3 | Moderate cost, errors recoverable, delay is inconvenient |
| 1 | Low cost per transaction, errors trivial, timing largely irrelevant |
The delay component is the one most frequently underweighted. A process where every day of latency forfeits a discount, risks a penalty, or loses a candidate carries far more value than its labor cost suggests.
A candidate scoring 4 x 4 x 4 produces 64. One scoring 5 x 2 x 5 produces 50 despite two perfect axes — correctly, because high variability is what turns automation projects into open-ended builds.
Apply the Disqualifiers
Score is necessary but not sufficient. Four conditions should remove a process from the current wave regardless of how well it ranks.
The process is about to change. If the underlying system is being replaced within twelve months, or a regulatory change is coming, or a reorganization will redraw the ownership, wait. Automating something that is about to be redesigned wastes the build twice.
There is no owner who wants it. A process with no accountable owner, or an owner who is indifferent, will not get the subject matter access, the exception decisions, or the adoption push that implementation requires. Enthusiasm is not a nice-to-have; it is a dependency.
The data is not trustworthy. Automation on a bad vendor master or an inconsistent employee record produces wrong answers faster. If the master data needs cleaning, that cleanup is the project, and it should be scoped as such.
The process is broken rather than slow. If the current process produces poor outcomes because it was designed badly, automating it makes the bad outcome permanent and harder to change. Redesign first.
Sequence in Waves
A ranked list is not a roadmap. Sequencing has to account for what each project leaves behind for the next one.
Wave one — prove the model. Pick one high-scoring process with a motivated owner and low political weight. The goal is not maximum value; it is a measured, credible result inside a quarter that establishes the platform, the governance model, and the measurement discipline. Time-off approval, expense submission, and onboarding task orchestration all work well here, and the HR automation guide ranks the HR candidates by implementation effort specifically for this purpose.
Wave two — take the largest single prize. With the platform proven, go after the highest-scoring candidate on the list, which in most organizations is invoice processing, payroll, or reconciliation. This is where the program earns its budget for everything after. Expect it to take two to three times as long as wave one, and plan the exception-handling design properly rather than treating it as an afterthought.
Wave three — build the adjacencies. Automate what connects to what you have already built. If AP is live, expense and vendor onboarding cost a fraction of what they would have standalone because approval routing, audit logging, and ERP integration already exist. Marginal cost per process falls sharply here, and this is where programs that planned a sequence pull decisively ahead of programs that funded projects one at a time.
Wave four — the hard, high-variability work. Contract review, complex case management, anything with genuinely unstructured input. These need the AI capability, the governance, and the organizational trust that the first three waves built. Attempting them in wave one is the single most common reason automation programs stall permanently.
The Candidates That Consistently Score Well
Across organizations, the same processes rise to the top, because they share the structural traits the scoring model rewards.
Invoice processing — very high volume, moderate variability once extraction is handled, high value from discount capture and error prevention.
Payroll processing — high volume, low variability, extremely high error cost, and hard deadlines that create real value from cycle time reduction. The full benefit picture is laid out in the analysis of payroll automation.
Employee onboarding — moderate volume, low variability, high value from compliance risk and first-impression impact, and unusually easy to implement because it is mostly coordination.
Bank reconciliation — very high volume, low variability, and a value profile driven by both labor and the close timeline it constrains.
Expense reports — high volume, low variability, and value concentrated in policy leakage that manual review does not catch.
Document collection and retention — high volume, low variability, and a value profile dominated by audit exposure rather than labor, which is why document management for compliance tends to score higher than teams expect.
The processes that consistently score poorly are strategic planning cycles, complex negotiations, exception-heavy customer escalations, and anything running fewer than fifty times a month. These are not permanently off the table, but they belong in wave four, not wave one.
Run the Exercise Annually
Scores move. Volumes grow, systems change, master data gets cleaned, and a process that was disqualified last year becomes the obvious candidate this year. The list should be rebuilt annually with fresh data, and the previous year's completed automations should be re-measured against their original business case at the same time.
Organizations that treat prioritization as a one-time exercise automate three or four processes and stop. Those that treat it as a standing capability keep finding candidates, because each wave lowers the cost of the next. If you are building a first candidate list and want it pressure-tested against volume and variability data rather than opinion, a structured business process automation assessment is the fastest way to turn a list of irritations into a defensible roadmap.
