Your job titles were never going to match O*NET's list exactly
Three weeks before a board meeting, a People Analytics Lead at a 900-employee logistics company opens a spreadsheet of 340 internal job titles and stares at the first one: "Ops Excellence Partner II." The company's private-equity owner has asked for a department-by-department view of AI exposure. Before any scoring happens, before any heatmap gets built, someone has to answer a much less glamorous question first: which of the roughly 900 O*NET occupations does "Ops Excellence Partner II" actually correspond to?
That question is not rhetorical. Get the mapping wrong and everything built on top of it — the exposure score, the department rollup, the redeployment list a CHRO eventually presents to the board — is built on a mismatch. Occupational mapping is the unglamorous, load-bearing step that most conversations about AI workforce exposure skip past. This article walks through how to do it methodically: what O*NET actually gives you to match against, a repeatable matching method, how to read a confidence score once you have one, and when a human being needs to step in and override the machine.
What O*NET actually gives you to match against
ONET — the Occupational Information Network, maintained by the U.S. Department of Labor's Employment and Training Administration — is the standardized taxonomy underneath this entire exercise. As of the ONET Resource Center's 2019 overview, the database covers 1,016 occupational titles and 923 data-level occupations, representing more than 55,000 individual jobs in the U.S. economy. Each occupation carries roughly 277 descriptors spanning tasks, work activities, skills, knowledge, abilities, and work context, and the database is updated on a rolling basis with a primary annual update cycle in the third quarter, according to the U.S. Department of Labor's 2025 O*NET documentation.
Underneath ONET sits the 2018 Standard Occupational Classification system maintained by the U.S. Bureau of Labor Statistics: 867 detailed occupations, rolling up into 459 broad occupations, 98 minor groups, and 23 major groups. ONET's occupations map onto SOC detailed-occupation codes, which is what makes the system usable as a crosswalk — you are not matching a job title to a data point, you are matching it to a standardized classification with a defined position in a hierarchy. The version of the O*NET database referenced throughout this piece is the current production release (v30.3); confirm the exact version your matching tool has loaded before you trust any output downstream, since descriptor content shifts with each update cycle.
This site incorporates information from ONET. Used under the CC BY 4.0 license. ONET is a trademark of USDOL/ETA.
If you have not yet read a plain-language walkthrough of how the taxonomy itself is structured, our overview of what O*NET is and how it works is the right starting point before you attempt any mapping. And if your immediate need is simpler — you have one job title and want the fastest path to a candidate SOC code — see our guide to O*NET SOC code lookup by job title.
A step-by-step method for mapping job titles to O*NET occupations
The core problem is that almost no internal job title was written with ONET in mind. Titles carry department shorthand, seniority ladders, internal jargon, and — increasingly — invented function names that no classification system anticipated. A repeatable method for mapping job titles to ONET occupations needs to correct for that before it ever compares strings. In practice, that method has six steps.
1. Normalize the title. Strip level suffixes ("II," "Senior," "Lead," "III"), department codes, and internal abbreviations, leaving the functional core of the title intact.
2. Extract the signal words. Most titles reduce to a function (marketing, operations, finance), a domain modifier (growth, supply chain, regulatory), and sometimes a seniority marker. Isolating the function word is usually the single highest-value step in the entire process.
3. Search against O*NET's title list — including reported alternate titles. O*NET occupations carry not just one official title but a set of alternate titles collected from real job postings and incumbent surveys. A title search that only checks the primary title will miss matches that a search against alternate titles would catch.
4. Score the candidates. This is where fuzzy matching job titles to standardized occupations earns its keep: rather than requiring an exact string match, the method scores similarity between the normalized internal title and each O*NET candidate title, producing a ranked shortlist rather than a single guess. Our companion piece on fuzzy matching job titles to occupations goes deeper into how that similarity scoring actually works.
5. Cross-check against the occupation's task and work-activity list, not just its title. A title match can be superficially convincing and functionally wrong — two occupations can share a title fragment while describing almost entirely different work. Pulling up the top few tasks and work activities associated with each candidate occupation and checking them against what the role actually does in your organization catches this class of error before it becomes a scoring error.
6. Confirm or override. The output of steps one through five is a ranked, scored shortlist — not a final answer. A human confirms the top candidate, or overrides it in favor of a lower-ranked one, or flags the role for a manual mapping outside the shortlist entirely.
For a broader view of how this crosswalk logic generalizes across an entire role list — not just one title at a time — see our guide to SOC code crosswalk tools.
Worked example: mapping "Growth Marketing Lead" to an O*NET SOC code
Here is the method applied to a single, realistic title. This example uses illustrative, round inputs to demonstrate the mechanics — treat the confidence figures as a worked example, not a measured statistic.
The internal title is "Growth Marketing Lead." Normalization strips the seniority marker "Lead," leaving "Growth Marketing." The signal-word extraction identifies "marketing" as the core function and "growth" as a domain modifier with no direct O*NET analog — growth marketing is an internal-industry term, not a classification term, which is common and expected.
A title-and-alternate-title search returns three candidates:
- Marketing Managers (O*NET-SOC 11-2021.00) — example confidence score: 82
- Advertising and Promotions Managers — example confidence score: 61
- Sales Managers — example confidence score: 44
The top candidate clears a reasonable confidence threshold on title similarity alone. The confirmation step then pulls Marketing Managers' associated tasks and work activities — planning and directing marketing policies, developing pricing strategy, coordinating with sales and product teams — and checks them against what a "Growth Marketing Lead" at this specific company actually does day to day. If the role's actual work (running paid-acquisition experiments, owning a growth P&L, coordinating with product on activation funnels) lines up with the task list, the mapping is confirmed. If the role instead spends most of its time on hands-on campaign execution with no managerial scope, a reviewer might instead route it toward a more individual-contributor-level marketing occupation, even though "Marketing Managers" scored highest on title similarity alone.
This is the core discipline behind occupational mapping: title similarity gets you a shortlist, and task-list similarity is what actually confirms the match.
Confidence scores and when to trust the match
A confidence score answers one narrow question: how similar is this internal title, after normalization, to this O*NET candidate title (and its alternates)? It does not, by itself, tell you whether the underlying work matches — that is what the task cross-check in step five is for. Treating a confidence score as a final verdict is the single most common way mapping errors slip downstream into an exposure analysis.
In practice, three bands are useful to distinguish:
- High-confidence matches are close enough on title and alternate-title similarity that a reviewer can typically accept them after a brief task-list sanity check.
- Medium-confidence matches warrant a closer look — the title is plausible but ambiguous, often because the role sits at the boundary between two adjacent occupations (a title like "Client Success Lead" plausibly maps to several distinct O*NET occupations depending on whether the role is closer to account management, customer service supervision, or sales).
- Low-confidence matches should not be auto-accepted under any circumstance. These typically indicate an internal-only title, a hybrid role that genuinely spans two or more ONET occupations, or a title in a fast-moving function that ONET's title list has not yet caught up to.
The goal of a confidence score is not to eliminate human review — it is to tell a reviewer where their attention is most needed, so that the 340-title spreadsheet from the opening scenario does not require the same level of scrutiny on every single row.
When to override the automated match manually
Certain categories of role reliably require a manual override rather than acceptance of even a high-scoring automated match:
Hybrid and multi-function roles. Mid-market and smaller organizations frequently combine functions in a single role that a larger company would split across two or three positions — an "Office Manager" who also owns bookkeeping and light HR administration, for instance. No single O*NET occupation will cleanly describe that role's full task list, and forcing a single-occupation match understates or overstates exposure depending on which function dominates the mapping.
Newly created, AI-adjacent titles. Titles like "AI Enablement Manager" or "Prompt Operations Lead" have emerged faster than any occupational classification system updates. These require a reviewer to map the role to its closest functional analog based on actual task content, since no direct title match exists yet.
Internal-only or brand-specific titles. Titles that only make sense inside one company's internal career ladder ("Ops Excellence Partner II," from the opening example) carry no external signal for a title-matching algorithm to use. These go straight to manual task-based mapping.
Roles where task importance skews the picture. Not every task an occupation performs carries equal weight, and O*NET assigns each task within an occupation a relative importance rating collected through structured surveys of job incumbents and occupational analysts. A role that nominally maps to an occupation but performs only that occupation's lower-importance tasks — while spending most of its time on tasks outside that occupation's typical scope — is a candidate for override even at a high title-confidence score. Our companion article on O*NET task importance ratings explained walks through how those importance weightings work and why they matter more than the occupation title itself once you move into scoring.
The throughline across all four categories is the same: a confidence score describes title similarity, and title similarity is a proxy for the thing you actually care about, which is task similarity. Proxies fail at the edges. Manual review exists to catch the edges.
Turning the mapped occupation into an exposure score
Once an occupation is confirmed — whether by high-confidence auto-acceptance or manual override — the mapping's job is done, and a separate methodology takes over. That methodology pulls the confirmed occupation's ONET task list and each task's importance rating, then scores the occupation's overall exposure across four dimensions: cognitive routine, physical routine, social and judgment, and creative — each scored on a 0–100 scale and weighted by how important each task is to the occupation as a whole, per ONET's own importance data.
The mapping step and the scoring step are deliberately separate. A wrong occupational mapping produces a confidently wrong exposure score — which is exactly why the confirmation and override steps described above exist before scoring ever begins.
It is worth restating plainly what this process is for and is not for. An exposure score, once calculated, sorts a role into one of three categories — Monitor, Review, or Redeployment Candidate — as an input to a human planning conversation. It is not a prediction that a role "will be automated" or a determination that a role is "safe." The score describes how much of an occupation's O*NET task profile resembles the kind of work current AI systems are suited to, based on a transparent, four-dimension rubric — nothing more, and nothing about any individual's job security. What a leadership team does with that input, including whether and how it discusses the result with the people in those roles, remains entirely a human judgment call, informed by context the rubric cannot see: tenure, performance, institutional knowledge, and the company's own strategy.
This is also precisely why getting the mapping right matters so much before the scoring stage. Downstream analyses — a department-level heatmap, a shortlist of redeployment candidates matched against adjacent occupations, a briefing document ahead of a board meeting — are only as trustworthy as the occupational mapping underneath them. Our full guide to running a company-specific AI workforce exposure assessment walks through the entire pipeline end to end, from the first job title in the spreadsheet to the final department rollup.
If you are mapping a full role list rather than a single title, doing this by hand in a spreadsheet is possible but slow, and the manual-override categories above tend to multiply faster than expected once you are past the first fifty titles. Our O*NET Task-Mapping Methodology Handbook documents the full crosswalk method, confidence-scoring logic, and override checklist described in this article as a working template you can apply directly to your own role list — available at workforceanalysis.com/store/onet-task-mapping-methodology-handbook.