Using O*NET Occupation Templates to Define Role Requirements Faster
The Role-Profile Problem Nobody Talks About
Picture the moment a manager says, "We need to hire a second logistics coordinator." HR's response is reasonable: draft a role profile so everyone agrees on what skills matter before the résumés arrive. What actually happens next is less reasonable — someone opens a blank document, types a job title, stares at it for a while, then starts pulling requirements from the current job posting, a colleague's memory, and a 2019 performance review that may or may not still apply.
Thirty minutes later, you have a list. It reflects whoever happened to be in the room, not a considered view of what a logistics coordinator actually needs to succeed. Two roles drafted the same way in different departments will share almost nothing in structure, making a skills gap analysis across those roles nearly impossible.
This problem compounds at scale. If defining one role profile takes an hour of collective effort, defining profiles for twenty roles — the kind of audit that comes up during a reorganization or a new performance cycle — takes the better part of a week. Most HR teams at 50–500-employee companies simply don't have that week, so the profiles never get done, the gap analysis stalls, and workforce planning stays reactive.
There is a faster starting point. The US Department of Labor's O*NET program has already mapped more than 900 occupations to the skills, knowledge domains, and work activities they typically require. Those mappings are available as structured data, and they exist precisely to give HR practitioners a research-backed head start on exactly this problem. This article explains what O*NET occupation templates contain, how to read them, and how to adapt them into role profiles your organization can actually use — in minutes rather than hours.
What an O*NET Occupation Template Actually Contains
O*NET — the Occupational Information Network, maintained by the US Department of Labor's Employment and Training Administration — is a continuously updated research database built from employer surveys, incumbent worker surveys, and occupational analyst input. Each occupation record is, in effect, a structured template describing what people in that role typically know, do, and need to be good at.
(Skills Inventory Manager incorporates O*NET-derived content under CC BY 4.0. Data source: O*NET Resource Center, onetcenter.org.)
A standard O*NET occupation record includes several layers of information relevant to role profiling:
Skills — drawn from the O*NET skills taxonomy, organized into Basic Skills (reading comprehension, writing, mathematics, active listening, and so on), Cross-Functional Skills (problem sensitivity, coordination, service orientation, and others), and Knowledge domains (customer and personal service, production and processing, administration and management, and more). Each skill in an occupation record carries an importance rating and a level rating, giving you both a priority signal and a proficiency benchmark derived from actual worker data.
Work activities — the tasks and cognitive operations the occupation typically involves, which translate directly into the performance expectations you'd articulate in a role description.
Technology skills and tools — common software platforms and equipment associated with the occupation, useful for the technical-requirements section of a role profile.
Together, these layers give a hiring manager or HR team a research-backed answer to the question "what does someone in this role actually need?" — before anyone has to generate that answer from memory.
Why Starting From a Template Is Structurally Better Than Starting From Scratch
When you build a role profile from scratch, you are doing two things at once: deciding which skill categories to consider, and then populating those categories. The first step — choosing the right categories — is where most of the error happens. You remember the skills that caused problems recently, and you underweight skills that have been running smoothly in the background. The resulting profile is shaped by recency bias and organizational memory rather than by what the occupation actually demands.
Starting from an O*NET template separates those two steps. The category selection is already done, informed by survey data from thousands of workers and employers in that occupation. Your job shifts to the more tractable task of calibrating — which of these skills matter most in our context, and at what proficiency level do we need them?
This calibration step is important to name explicitly, because O*NET templates are not a finished role profile. They are a starting point. The O*NET data describes what the occupation typically requires across many organizations; it does not know that your logistics coordinator also manages the carrier compliance portal, or that your customer service representative handles escalations that require technical product knowledge your industry peers outsource to a separate tier. Those organization-specific requirements get layered on top. Skills that aren't relevant to your context get removed. Proficiency thresholds get adjusted to reflect your actual operational standard, not a population average.
What you end up with is a role profile that is grounded in occupational research and calibrated to your organization — which is a much better foundation for a skills gap analysis than a document assembled from memory in a thirty-minute meeting.
How to Read O*NET Importance and Level Ratings
Two numbers appear next to every skill in an O*NET occupation record, and both are worth understanding before you build your profiles.
The importance rating runs from 1 to 5 and reflects how critical the skill is to performing the occupation. A rating of 4 or 5 signals that the skill is a core requirement — something a person in this role needs to have before they can function effectively. A rating of 2 or 3 suggests the skill is relevant but not make-or-break.
The level rating also runs from a scale anchored to behavioral descriptors. At the low end, the anchor might be "read a memo"; at the high end, "write technical specifications a specialist audience will rely on." These anchors vary by skill, but the principle is consistent: the level rating tells you roughly how advanced the capability needs to be, not just whether it needs to exist.
For role-profile purposes, a practical workflow is:
- Pull the occupation template for the role you are defining.
- Identify the skills with importance ratings of 4 or above — these become the non-negotiable requirements in your profile.
- Review the level ratings for those high-importance skills and translate them into the proficiency scale your organization uses (if you use a 1–5 scale, the O*NET level descriptors can serve as calibration anchors for each step).
- Scan the remaining skills and add any that are organizationally significant even if they rate lower in the population-wide data.
- Add any organization-specific skills the O*NET record doesn't include.
This process typically takes 20–40 minutes per role — compared to the hour-plus of open-ended drafting that a blank-page approach requires, and far more consistently structured across roles.
For a closer look at how the underlying skills taxonomy is organized, the O*NET skills taxonomy explained article walks through the Basic Skills, Cross-Functional Skills, and Knowledge domains in detail.
Handling the Gap Between O*NET Occupations and Your Actual Job Titles
One practical friction point: your job titles may not match O*NET's Standard Occupational Classification (SOC) codes directly. Your "People Operations Generalist" doesn't appear in the database; "Human Resources Specialists" (SOC 13-1071) does. Your "Supply Chain Coordinator" maps approximately to "Logistics Analysts" (SOC 13-1081) or "Transportation, Storage, and Distribution Managers" (SOC 11-3071) depending on what the role actually does.
This is normal, and it's less of a problem than it sounds. The mapping exercise — deciding which O*NET occupation record is the closest analogue to your job title — is itself a useful clarifying conversation. If you can't agree on whether a role maps to one O*NET occupation or another, that ambiguity usually reflects genuine disagreement about what the role is supposed to do, and surfacing that disagreement before you hire for or evaluate against the role is exactly the right time to surface it.
A few mapping strategies that help:
- Search by task, not title. O*NET's occupational search lets you search by work activity (e.g., "coordinate logistics") rather than by job title, which often produces better matches.
- Read the occupation summary first. Before importing a template, read the one-paragraph occupation description to confirm the work described matches the work your role actually does.
- Blend two templates when the role is genuinely hybrid. A role that combines customer-facing service with technical troubleshooting might pull the high-importance skills from both a customer service representative template and a help-desk technician template, then deduplicate. This is legitimate — just document that you blended two sources so the logic is auditable.
If you are building a full competency framework across multiple levels of a job family, you may find that O*NET's occupational levels (e.g., the distinction between a specialist and a manager in the same domain) provide a useful structure for differentiating proficiency expectations across career stages.
From Template to Live Role Profile: Keeping It Current
The most common failure mode for role profiles isn't the initial build — it's the six-month update cycle that never happens. A profile drafted in January based on what the role required in January becomes quietly wrong by July, because the technology stack changed, a team member left and the remaining person absorbed new responsibilities, or the department's focus shifted.
O*NET itself is updated on a rolling basis as occupational data is refreshed, so the templates you started from don't stay static either. Building a habit of reviewing role profiles against the current O*NET template annually — flagging skills whose importance has shifted in the population-level data — is a low-effort way to catch drift before it becomes a gap.
The more durable fix is keeping role profiles in a system that makes them easy to edit, compare, and connect to live employee skill data. When a role profile lives in a spreadsheet alongside the skills matrix, the update cycle depends entirely on someone remembering to open the right tab. When it lives in a role profile builder that sits next to the same system tracking what your employees actually know, the gap between "what this role requires" and "what this person has" is always visible — and always current.
That connection — between the defined role requirements and the actual employee data — is what turns a role profile from a hiring document into a workforce-planning tool. It's what makes it possible to answer, in real time, which of your current employees could step into a role, which have the foundation and need targeted development, and where you have structural gaps that require external hiring. That is the full skills inventory workflow, and the role profile is its foundation.
Getting Started Without Waiting for a Full Initiative
If a complete role-profiling project feels too large to launch right now, the O*NET approach scales down well. Start with one role — the one you're currently hiring for, or the one where the gap between what people have and what the role requires feels most acute. Pull the O*NET occupation template, run the 20–40 minute calibration workflow described above, and you have a draft role profile grounded in research rather than memory.
Use that profile to run a focused skills gap analysis for the people currently in or being considered for the role. See whether the process produces insights that are more actionable than what you were working with before. If it does, you have the working model to extend across the rest of your roles — without having to build the methodology from scratch.
Skills Inventory Manager pre-loads the O*NET skills taxonomy on Day 1 so your team starts with a populated skill library rather than a blank screen, and the role profile builder connects directly to that taxonomy — so the skills you define in a role profile are the same skills you're tracking across your workforce.
If you want to see how that works in practice, explore the features or start a 14-day free trial — no credit card required.
Skills Inventory Manager incorporates O*NET-derived content under CC BY 4.0. O*NET is developed by the National Center for O*NET Development under sponsorship of the US Department of Labor, Employment and Training Administration. Data source: O*NET Resource Center — onetcenter.org.