AI Automation Opportunity Index: 20 Roles Ranked

The 20-role index

The current score answers: how much of the role’s rated task exposure can available AI and automation tools handle under a controlled production design? The 2029 column is a capability scenario under the same task mix. It is not an employment or adoption forecast.

For a faster functional path, browse the reports in four groups:

• Revenue and service: customer service, marketing management, sales management, real estate agents, and insurance agents.
• Finance and risk: bookkeeping and finance teams, accountants and auditors, payroll, tax preparation, claims adjusting, and paralegal work.
• Operations and administration: operations management, data entry, administrative support, property management, procurement, and logistics analysis.
• People and technology: HR and recruiting, IT systems analysis, and software development.

The ranking makes the practical boundary visible. Data entry, payroll, bookkeeping, and customer-service administration contain more structured, repeated work. Sales management, insurance advice, general operations management, marketing management, and real-estate selling rely more heavily on relationships, judgment, negotiation, and accountable decisions. That difference is why one generic “AI will automate 60% of work” claim is not useful for implementation.

What is original Arsum data

O*NET supplies the occupation definitions, 432 task statements across this 20-role cluster, task type, importance, relevance, frequency distributions, work context, activities, job titles, and software examples. BLS supplies May 2025 national employment and wage estimates.

Arsum adds:

• the current automatable share for each task;
• human judgment, interaction, physical-presence, and supervision requirements;
• current tool capability, implementation complexity, and best-fit technology;
• a 2029 capability scenario;
• the exposure-weighted occupation score;
• a disclosed time-capacity range;
• gross wage-capacity scenarios;
• the first-pilot recommendation and human control boundary.

This separation matters. “ONET says payroll is 78.6% automatable” would be false. ONET describes the work; 78.6/100 is an Arsum transformation and assessment built on those task facts.

Source snapshots and coverage

All occupation pages in this release use the same frozen inputs:

All 432 task statements were assessed. Most occupations also have complete O*NET importance, relevance, and frequency inputs for every task. Accountants and Auditors have 25 of 29 fully weighted tasks, and Claims Adjusters have 27 of 29; their pages disclose that denominator next to the score. Missing rating inputs are not silently imputed into the weighted result.

The task-exposure formula

O*NET reports importance on a 1-5 scale, relevance as a percentage, and frequency as respondent shares across seven categories. It does not publish a ready-made “events per week” number. Arsum converts those frequency categories to explicit planning midpoints and then uses a logarithm so hourly tasks do not erase important weekly or monthly work.

For task (t):

importance_weight = importance / 5
relevance_weight  = relevance_pct / 100
frequency_weight  = min(1, ln(1 + estimated_occurrences_week) / ln(41))

exposure_weight   = importance_weight
                  × relevance_weight
                  × frequency_weight

The current occupation score is:

Automation Score = Σ(exposure_weight × automatable_today_pct)
                 / Σ(exposure_weight)

The result ranges from 0 to 100. It is a weighted technical-capability share. It is not a probability, a headcount recommendation, or a claim that the whole occupation can run without supervision.

How task capability is assessed

Each task receives a structured assessment with the occupation context hidden from the desired final score. The rubric distinguishes five constraints:

1. Structured processing: calculation, transfer, reconciliation, classification, validation, and record maintenance raise current capability.
2. Professional judgment: interpretation, strategy, recommendations, materiality, and ambiguous trade-offs reduce safe autonomy.
3. Human interaction: negotiation, persuasion, counseling, employee decisions, and trust-heavy conversations keep a person in control.
4. Physical presence: inspection, travel, property showing, cash custody, and physical handling limit software-only automation.
5. Consequence and regulation: legal, tax, payroll, insurance, claims, privacy, security, and compliance tasks raise supervision and implementation requirements.

The original 61 customer-service, bookkeeping, and marketing-manager assessments were retained as editorial calibration anchors. The remaining tasks use the frozen rubric, followed by top/bottom and risk-domain QA. That QA caught and corrected errors such as treating email as physical mail, overrating applicant matching, overrating legal filing, and mistaking “measure productivity” for physical measurement. The corrections changed the rubric class and reran the full batch; they were not hidden one-off edits to the published total.

What “hours per week” means here

ONET reports frequency but not task duration, so the index does not pretend to observe actual hours saved. For comparison across roles, Arsum uses a reference 40-hour week and assigns 30 hours across fully rated ONET tasks in proportion to exposure. Ten hours remain unmodeled for context switching, meetings, breaks, and work not represented by task statements.

task_minutes      = 1,800 × task_exposure / occupation_exposure
automatable_hours = Σ(task_minutes × current_capability) / 60
published range   = 75%-125% of modeled hours, capped at 30 hours

This produces a planning range, not a promise. A real pilot should replace it with actual workflow volume, median handling time, acceptance, review, exception, and rework data.

Wage capacity is not savings

The gross annual wage-capacity midpoint uses the May 2025 BLS national mean hourly wage:

gross wage capacity = modeled automatable hours × mean hourly wage × 52

Net value must subtract software and model usage, implementation, integration, review time, exception handling, maintenance, change management, and a risk reserve. Employment counts exclude self-employed workers. The real-estate figure therefore does not represent the whole agent population. Procurement and Logistics Analyst pages use disclosed broader BLS parent occupations because OEWS does not publish a separate detailed estimate matching those O*NET specializations.

How the 2029 scenario is calculated

Every task has a separate automatable_in_3y_pct. Physical and relationship-heavy tasks receive smaller capability gains; structured digital tasks can receive larger gains when reliability and integration are the limiting factor. The 2028 value is a two-thirds linear midpoint between the 2026 and 2029 task estimates, aggregated with the same task exposure weights.

The scenario deliberately holds the task mix constant. It does not model:

• whether a company buys or deploys the technology;
• regulatory changes;
• changes in customer demand or employment;
• new tasks created by AI adoption;
• changes in occupation definitions;
• economic cycles, prices, or organization design.

This makes the date useful for roadmap planning without presenting capability as destiny.

Publication and QA gates

A role page can publish a hero score only when the following are visible and reproducible:

• O*NET snapshot, scoring version, run, capability date, and scenario horizon;
• task assessment coverage and the count with complete score weights;
• current score, supervision, and human boundary;
• time-model assumptions and range rather than false precision;
• BLS year, geography, and parent-mapping disclosure where needed;
• task IDs behind the top opportunities;
• a statement that the index does not forecast layoffs;
• a first-pilot recommendation with a measurable control path.

The repository stores the SQL schema, generated assessment run, BLS import, analytics views, per-role research packs, and site data. Re-running the scripts creates a new versioned model run rather than overwriting the prior history.

How to use the index in a real company

Use the role page as a shortlist, then validate one workflow against local evidence:

1. choose one high-opportunity task that happens at meaningful volume;
2. capture current handling time, quality, rework, and escalation;
3. map every source system and permission;
4. define the normal path, exceptions, and accountable owner;
5. run in review mode before allowing actions;
6. measure accepted capacity minus review and exception cost;
7. expand only if net value and control quality both improve.

That sequence turns the index into a buying and implementation tool. It also gives the team permission to stop: if a low-scoring, high-supervision workflow cannot produce net capacity, the correct decision may be better software configuration, process cleanup, or no AI project at all.