A recruitment CRM skills taxonomy is a controlled vocabulary for the work candidates can do. Start with the skills your current vacancies actually require, give each concept one stable identifier, and map everyday recruiter terms to it. Keep the evidence behind a skill separate from its name. This makes a search for relevant experience more dependable without pretending that a matching label proves someone is ready for a placement.
For an agency serving Dutch logistics clients with Polish and English recruitment desks, the immediate problem is often vocabulary drift. One recruiter records order picking, another writes warehouse work, and another copies a Polish job title. Some descriptions overlap; others mean different work. A better vocabulary makes those differences visible before a shortlist reaches the client.
Diagnose a vocabulary problem before changing search
Take a small selection of recent vacancies and candidate records from the same desk. Ask two recruiters to identify candidates with a specific skill using the existing labels. Compare their reasoning, including people they excluded. The goal is to discover whether different words represent the same work or whether one broad word hides several capabilities.
If both recruiters understand the labels but cannot combine them with location and availability, focus on CRM search filters. If they disagree about what a label means, fix the vocabulary first. Saving another search will simply preserve the disagreement.
Write down examples of three problems: genuine synonyms, ambiguous terms, and missing distinctions. Do not merge them into a single cleanup list. Each needs a different decision, and a spelling correction should not receive the same treatment as a change in meaning.
Define a skill without turning it into a candidate verdict
Create a short dictionary entry for each concept. It should contain a stable internal identifier, preferred display label, plain-language definition, accepted aliases, and a named maintainer. Include an example of what belongs and, where confusion is likely, what does not.
For example, distinguish order picking with a handheld scanner from operating a reach truck. Both can belong to a warehouse role family, but membership of that family should not automatically assign either skill. Likewise, past experience, a certificate and permission to operate equipment at a particular site are different pieces of information.
Keep candidate evidence beside the vocabulary:
- what the candidate reported doing;
- the source and date of that information;
- any recruiter clarification or assessment;
- relevant evidence still to review;
- limitations, such as experience on a different machine type.
An intake statement can support a follow-up question. It should not silently become a verified competence because an automated tool recognized a phrase. Avoid labels such as excellent or fully qualified unless the agency has defined exactly what evidence they require.
Make multilingual terms point to shared concepts
The visible wording can differ between desks while the underlying concept remains the same. A Polish recruiter should be able to search familiar terms without inventing an entirely separate classification. Preserve the candidate's original wording so another recruiter can check a mapping when it looks doubtful.
Treat translations as proposals for review. A broad phrase such as magazynier can describe a job family rather than a specific warehouse skill. Ask what tasks the person performed before mapping it to a narrower capability. Similarly, a job title alone should not imply every skill associated with that occupation.
The European Commission's ESCO classification provides multilingual occupation and skill concepts. It can be a useful reference when designing a shared vocabulary. Review the relevant definitions against your vacancies rather than importing an entire classification into the recruiter interface. This is a design option, not a claim that AI JOB AGENCY includes an ESCO integration.
Introduce the vocabulary in one live role family
Agree the first set with the desk
Choose a role family where inconsistent labels cause repeated clarification. Work from actual job tasks, with personal details removed from workshop examples. Keep the initial list small enough for recruiters to explain to one another. Add distinctions only when they change search, screening or a client conversation.
Map old labels with reversible decisions
Create a mapping list showing the old value, proposed concept, reason and reviewer. Straightforward spelling variants can share a destination. Ambiguous labels should remain unresolved until someone checks the source context. Preserve the previous value and mapping version so you can reverse a mistaken assignment.
Test both inclusion and exclusion
Use sample records that should match and records that should remain outside the result. Include broad job titles, translated terms and candidates with incomplete evidence. Ask the desk to explain unexpected results before applying mappings across the full database.
For a hypothetical Tilburg warehouse vacancy, a scanner-picking requirement should surface candidates with that recorded experience. A generic warehouse label may deserve clarification; it should not automatically satisfy the requirement. A reach-truck label should remain distinct even when both roles sit under logistics.
Publish a route for new terms
Give recruiters a way to suggest a missing term without creating a permanent tag immediately. The maintainer can accept a new concept, add an alias to an existing one, or request clarification. Record the decision and update the short dictionary that desks actually use.
Ask suppliers to demonstrate the difficult cases
During a recruitment CRM workflow review, ask how the proposed setup handles aliases, retired labels and evidence attached to a candidate skill. Request a demonstration in the languages your desks use. A translated menu is less useful if searching an everyday local term returns nothing.
Check what happens when a concept is renamed. Existing candidates and saved searches should remain understandable. Ask whether a mapping change can be reviewed and reversed, and whether an automated extraction retains the original phrase. These are requirements to verify in the proposed system, not capabilities to assume from a product category.
Evaluate the pilot through concrete desk work: incorrect inclusions, overlooked relevant records and labels recruiters still have to explain. A larger tag count is not a business outcome. A vocabulary earns its place when recruiters can justify why a candidate appeared and what remains to be checked.
Common mistakes and a practical checklist
Avoid importing hundreds of unused labels, translating job titles as if they were precise skills, and making every synonym a new checkbox. Another mistake is overwriting source wording during cleanup, which removes the evidence needed to correct an error. Keep broad role families and specific capabilities distinct.
Before rollout, check that:
- each concept has a definition and stable identifier;
- Dutch, Polish and English aliases have been reviewed where used;
- reported and assessed skills remain distinguishable;
- ambiguous legacy values have a clarification route;
- searches have been tested with positive and negative examples;
- a maintainer owns additions and retired terms.
If inconsistent labels are blocking candidate reuse, contact AI JOB AGENCY with a few anonymized examples. A focused vocabulary review can establish what needs changing before you expand CRM automation.
FAQ
Is a skills taxonomy the same as candidate segmentation?
No. A taxonomy defines what a skill label means. Segmentation groups candidates for a particular purpose, often combining skills with availability, location or timing. Shared definitions make those groups easier to trust.
How many skills should we start with?
Use the number needed to describe one active role family accurately. There is no universal target. If recruiters cannot distinguish two proposed labels in a real placement conversation, reconsider the distinction before adding both.
Can AI assign skills from CVs or calls?
It can be evaluated as a way to suggest labels. Keep the source phrase and an explicit review state, especially for ambiguous language. A suggestion must not become proof of competence or replace necessary clarification.
Should every branch display identical wording?
The meaning and identifier should be shared. Display labels and approved aliases can reflect local language. Branch-specific terms need a documented relationship to the common vocabulary so cross-branch searches remain interpretable.
Does a skill tag prove a certificate is current?
No. Record certificate information and its verification separately where relevant. Experience, documentary evidence and a site's requirements answer different questions; collapsing them into one tag hides work that may still be necessary.