Skills Taxonomy

What a skills taxonomy looks like

A taxonomy is a hierarchy. At the top are broad domains, below them clusters, and at the bottom individual skills, each with a definition and often proficiency levels. For a customer operations function it might look like this (domain / cluster: skills):

• Customer interaction / De-escalation: handling complaints, calming distressed callers, setting boundaries with abusive customers.
• Customer interaction / Written communication: chat etiquette, email case writing, concise case notes.
• Systems and tools / CRM: case creation, account search, knowledge base search.
• Compliance / Data protection: identity verification, payment card handling, recording disclosures.

Each skill then has levels, for example 1 = learning, 2 = independent, 3 = can coach others, 4 = expert. A job profile lists the skills and levels it needs; an employee profile lists the skills and levels the person has.

Taxonomy vs ontology vs competency framework

• Skills taxonomy: a hierarchy of skills with standard names. Answers "what skills exist and how are they grouped?"
• Skills ontology: adds relationships between skills, such as "SQL is related to data analysis" or "knowing Spanish makes learning Portuguese easier", plus links to jobs, courses and synonyms. Ontologies power matching in talent marketplaces and learning platforms, usually generated or maintained with the help of AI.
• [Competency framework](/glossary/competency-framework/): describes broader behaviors and capabilities, often leadership behaviors such as "builds trust" or "drives results", with behavioral indicators at each level. Competencies tend to be fewer and broader; skills are more specific and easier to verify.

Many organizations keep both: a small competency framework for leadership and performance reviews, and a larger skills taxonomy for hiring, learning and mobility.

Public sources to start from

You rarely need to start from a blank page. Two widely used public sources:

• **O*NET**, maintained for the US Department of Labor, describes hundreds of occupations with their skills, knowledge, abilities, tasks, and tools and technologies.
• ESCO, the European Commission's classification of skills, competences, qualifications and occupations, available in many EU languages.

Both are broad and generic. Use them as a base and add the company-specific skills that actually differentiate your roles, such as your products, systems and processes.

How to build one

1. Start with a use case. Hiring for a job family, building learning paths or launching a talent marketplace. The use case decides how detailed the taxonomy needs to be.
2. Start narrow. Pick two or three job families that matter most, such as frontline customer service and team leads, rather than the whole company.
3. Collect skills. From job descriptions, O*NET or ESCO, interviews with top performers and their managers, training content and quality scorecards.
4. Clean and standardize. Merge synonyms, remove vague items ("hard-working" is not a skill), and write a one-line definition for each.
5. Set proficiency levels with observable descriptions.
6. Map to jobs and people. Attach required skills and levels to job profiles; collect current levels through manager assessment, self-assessment or assessment results.
7. Assign ownership. Name an owner for each domain and review twice a year. A taxonomy that is not maintained decays quickly as tools and products change.

A common practical size is a few hundred well-defined skills for a mid-size company. Taxonomies with tens of thousands of entries usually come from vendors and need heavy filtering before anyone can use them.

Why it matters for high-volume hiring

For roles hired by the hundreds, a taxonomy makes skills-based hiring practical. Instead of screening on degrees or job titles, recruiters screen for a short list of defined skills, such as typing accuracy, bilingual fluency at a set level and de-escalation, each tested the same way. It also connects hiring to training: if the taxonomy says new agents need knowledge base search at level 2 by day 30, the training plan and nesting checklist can target it directly. This is a big part of becoming a skills-based organization.

Common mistakes

• Trying to cover the entire company in the first version.
• Mixing personality traits and values in with skills.
• No proficiency levels, so "Excel" means anything from opening a file to building financial models.
• Self-reported skills accepted without any validation.
• Buying a huge vendor library and expecting managers to use it unfiltered.