Expertise locator: why searching for experts inside a company doesn't work
Knowledge in a company almost always exists — it just isn't found at the moment it's needed.
An engineer with a question about integration goes through three chats, two archives, and old correspondence, spends half a day on it, and at best pulls out an answer that has lost its relevance. Meanwhile the task is stalled, and the decision is made blindly — from memory, not from facts.
The root of the problem is that the employee competency map lives separately from the work itself. It is maintained as a questionnaire: someone once a year filled in the "skills" field, someone didn't.
Such a map doesn't know who was last dealing with a specific unit, who wrote a technical breakdown, and who answered a similar question a month ago.
The internal knowledge base is structured the same way — documents are arranged by departments, not by tasks, and searching through them finds wording, not the holder of the knowledge.
Hence typical losses. The same work is done twice in different teams. A new employee spends a month restoring context that could have been obtained in one conversation.
A person leaves — and knowledge that was never recorded anywhere falls apart with them, and no one knows who to go to next.
Expertise locator solves this differently: searching for experts inside a company is built not on questionnaires, but on traces of real work.
The system collects who did what, answered, wrote, and fixed, and on request in plain language returns specific people with justification — why exactly them.
The key here is not "smart search," but the connection between a person and a topic and confirmation that this experience is still relevant. Below we break down how this is covered.
What internal expert search gives: effects in numbers
Effect from implementing expert search consider not by number of queries in interface, but by four metrics that we take before and after launch.
They show whether work is going away blindly and how much is being solved repeatedly — for this class of systems, Expertise Locator, this is what results validation is based on.
-
Time to the right person. Previously the question "who has already solved this here" went through several threads and depended on personal acquaintances — the answer was found in hours, sometimes days.
After bringing profiles, projects, and work correspondence into a single index, the name, role, and confirmed experience come up in minutes — including departments the asker didn't know about.
-
Share of questions answered on the first try.
A significant portion of requests previously came back with the formula "ask a colleague from the neighboring team." After launch, most queries close at the first step: the system searches by task description, not by the exact name of the expert.
-
Competency coverage. Narrow specialists who did not declare themselves in profiles and do not sit in formal competency centers stop falling out of the results.
The share of found experts from non-obvious departments is growing — this is the main source of new connections inside the company.
-
Reduction of duplicate work. The request increasingly sounds like "who has a ready solution" rather than "how to do this." Teams pick up existing work instead of building from scratch, and the share of tasks done anew falls.
Metrics are taken on the same set of typical tasks: time to contact, share of requests closed on the first try, department coverage, number of re-created solutions. This way the effect is visible in dynamics, not in a launch report.
Expertise locator options: built-in search, assistant, relationship graph
The expert search scheme is determined not by the interface, but by where the evidence of competence lies: in document and correspondence texts, in task and project history, or in connections between people.
There is no universal option — each is limited in its own way by the quality of the source data, so they choose for their own environment: how many sources are available, how well they are labeled, and how often team composition changes.
The common requirement for all options is regular index updates and inheritance of access rights from the source. If an expert card does not pull in the current project composition and roles, after a couple of months it diverges from reality, and people stop trusting the system.
| Option | When it fits | Limitations |
|---|---|---|
| Built-in search across documents and the knowledge base | There is a large corpus of texts: regulations, reports, project descriptions | Finds a document, but not a person; works poorly on short queries |
| Internal assistant | The user formulates a question in words and expects an answer with links | Requires fact-checking; without sources and citations it quickly loses trust |
| Employee relationship graph | Competencies are visible from tasks, projects, authorship, and collaboration | Sensitive to metadata quality in trackers and HR system |
| Hybrid: graph plus semantic search | Need both candidate precision and a clear answer to the question | More expensive to maintain: two data loops and rules for merging them |
Transition to a hybrid usually takes a separate stage: first the graph collects a pool of candidates based on participation in similar tasks, then semantic search ranks them by relevance and explains the choice with a link to the source.
It is more reasonable to start with the source where the data is already structured — this gives the first working result without rebuilding accounting systems.
How we implement an expert search system: stages of work
We start with an audit of data sources, not with choosing technology: the quality of results is determined by how completely and freshly employee competencies are described.
Below is the sequence of work for implementing expertise locator, an internal expert search system, with checkpoints at each step.
- Audit of data sources. We examine where information about skills is stored: HR directory, project histories, knowledge bases, profiles in work chats. For each source we record completeness, update frequency, and access rights.
- Consolidated competency directory. We bring role and technology names to unified formulations — otherwise the same skill comes in three lines and search falls apart into synonyms.
- Search setup. We assemble a hybrid scheme: exact match against the directory plus semantic search in project descriptions. Ranking takes into account the freshness of skill confirmation.
- Relevance validation. We form a reference set of queries with pre-known correct answers and measure the share of hits in the top results. We agree on the threshold before launch.
- Pilot and fine-tuning. We launch in one department and look at which queries do not find the right person. Separately, we check rights: who sees the profile of an employee who has moved to another department.
- Solution handover. We provide documentation, the regulation for updating the directory, a report on result quality, and train the system owner.
Each stage ends with a verifiable artifact: a source map, a directory, a set of reference queries, a metrics report. We confirm readiness with numbers on the reference set, not by showing successful examples.
Delivery composition: configured search, access policies, regulations
Delivery is not a demonstration prototype, but a working search loop inside the customer's infrastructure along with documents by which it can be developed and maintained without us. Below is what exactly remains with your team after launch.
- Working search loop — a service with indexing of employee profiles, ranking by query relevance, and highlighting of matched skills; deployed in your environment.
- Data schema — sources (HR system, skills catalog, project trackers), rules for linking records into a single profile, handling duplicates and outdated attributes.
- Access policies and visibility model — what is open to a role, what is hidden, which fields only the profile owner sees; logging of requests to personal data.
- Profile update regulation — triggers for actualization, frequency of reconciliation with sources, those responsible for record quality, and the procedure for reviewing complaints about incorrect data.
- Solution documentation — architecture diagram, description of ranking logic, administrator instructions, and an employee memo: the system is not tied to one person.
- Quality assessment methodology — a test set of queries, the share of hits in the top results, the procedure for changing weights and recalibrating after data edits.
Such a kit removes the main risk: expert search remains manageable, is refined by the internal team, and does not require constantly returning to the contractor.
Case: how expert search reduced approval time
The company is distributed: product teams in three time zones, some contractors join on a project basis.
Knowledge of who is responsible for the payment gateway or exchange of directories with an external catalog lived in correspondence, task descriptions, and the heads of long-tenured employees — the request "we need someone who has already configured this" turned into a chain of four to five forwards between teams.
Measurements before launch: technical solution approval took an average of eight working days, finding the competency owner — from two days, and every third request went to the wrong team and came back with a clarification.
What was changed
Expertise Locator was assembled as a layer on top of existing sources: project catalog, task tracker, employee profiles, and approval history.
The model extracts technological entities from task descriptions and matches them to people, and calculates the competency profile with weight by freshness and number of confirmations — not only by self-assessment in a questionnaire.
Search goes by the meaning of the query, not by exact word match: the wording "supplier directory migration" finds the person who did the same solution under a different name.
Rights are inherited from the corporate catalog — an employee sees only the teams and projects to which they already have access; a separate role matrix is not needed.
Result
Solution approval dropped from eight days to three, and the share of requests closed on the first contact with the right person grew from 60 to 88%.
The profile is rebuilt daily: if a person has not touched a topic for six months, their weight in the results falls, and those who work with it now rise to the top.
How is semantic search different from keyword search?
Keyword search relies on an inverted index: the query is split into tokens, reduced to a base form, and documents are ranked by term rarity and field length.
The logic is explainable — you can see why an expert card rose in the results — but it is rigidly tied to wording: in the query "streaming," in the profile "stream data processing," there is no match, and the person remains unfound.
Semantic search compares vector representations of the query and profiles, so it finds the right specialist without shared words — by the description of tasks and projects.
The flip side: it confuses abbreviations, system names, and exact identifiers, and quality directly depends on the completeness and uniformity of cards.
The working option is hybrid retrieval, where the semantic branch is responsible for recall and keywords for precision on rare terms; mature search platforms support this scheme, including Elasticsearch.
| Approach | Retrieval quality | Data requirements | Maintenance effort |
|---|---|---|---|
| Keyword | Accurate on terms and codes, zero on paraphrases | Text fields of the employee card | Synonym and stop-word dictionaries, changes are predictable |
| Semantic | Finds by meaning, weaker on abbreviations and names | Up-to-date descriptions of competencies and projects | Reindexing when the model changes, labeling relevance scores |
| Hybrid | Recall plus precision on rare terms | Normalized cards and links to projects | Maintaining both branches and configuring result merging |
A separate part of the work is data and quality monitoring. Keyword search is fine with text fields and a synonym dictionary; semantic search needs a unified competency directory, linking experts to projects, and regular reindexing when the model is updated.
Acceptance is carried out by metrics: share of queries with no results, precision in the top ten, share of query reformulations — in the hybrid, the first two noticeably improve, and the third decreases.
Common technical questions about expert search
Searching for an expert is not searching for a document: the system must return a person who has already solved a similar task and show on what facts the conclusion is based.
Below are the doubts that most often arise before the start and how they are closed at the architecture level.
How accurate will the results be?
A hybrid scheme works: exact match by terms and skills plus semantic search when a person describes a task in their own words. The competency profile is built on confirmed artifacts — closed tasks, repository changes, discussions — not on self-assessment.
The weight of a skill falls if it has not been confirmed in recent months, so the top includes those who work with the topic now. We control quality by the share of relevant hits in the top five.
Data is scattered across different systems — how do we bring it together?
We connect sources through integrations: task tracker, knowledge base, competency catalog, HR loop. Then — a unified competency model and synonym dictionary: "postgres," "PostgreSQL," and "relational database" are reduced to one concept. Indexing is incremental, on change events, so a full rebuild is not needed.
How is the confidentiality issue resolved?
Rights are inherited from the source: if an employee cannot see a project in the source system, they will not find it through search either. Restrictions apply at the level of individual records, not only sections.
Additionally — a request log and masking of sensitive fields so that search does not become a workaround access channel.
Will profiles have to be filled out manually?
No. The base profile is assembled automatically from work traces, and the person only needs to confirm or reject several key competencies. This removes the main reason why internal expert catalogs empty out a couple of months after launch.
How is the knowledge base kept up to date?
Freshness is a metric, not a wish: we monitor the share of profiles without recent confirmations and source coverage.
Outdated links are weakened automatically, and discrepancies between the source and the index are shown in a report so they can be reviewed, rather than discovered at search time.
Let's discuss the task: we'll select a search scheme for your environment
A search scheme cannot be chosen "by eye": the retrieval quality of expertise locator entirely depends on which data sources you already have and how well they are labeled.
Therefore, before estimating the project, we need inputs on the project — the architecture and scope of work depend on them.
From the customer, the following is enough:
- A list of source systems: employee catalog, profiles in internal systems, knowledge base, department structure — and the access method for each.
- How an expert is found today: a query in a general chat, an email to a manager, an oral survey — where time is lost and why the answer comes back incomplete.
- Which attributes describe competency: projects, technologies, certificates, roles — and who is responsible for their freshness.
- Access separation: who sees the full profile, who sees only confirmed competencies, what is closed by internal restrictions.
- Environment boundaries: own servers or an isolated segment, whether data processing by external services is allowed.
- Acceptance criterion: what share of queries the system closes on its own and with what accuracy it hits the right specialist.
In response, we will return an implementation scheme with stages, a project estimate by timeline and team composition, and a work plan with control points and risks for each source.
Separately, we will list what will have to be improved in the data before the start — this removes the main surprises at the launch stage.
To discuss the task substantively, it is enough to describe the current sources and how an expert is searched for now — that will be enough for us to come back with an estimate and plan.
