How to find internal experts using company knowledge

That distinction matters. A document author may have moved teams. A ticket assignee may have handled one incident rather than owning the system. A skills profile may be out of date. A fluent assistant can turn thin evidence into a very certain-sounding recommendation.

An expert-finding workflow should therefore return four things together:

• the unresolved question in the user's words;
• the sources and dates that support a possible expert;
• the confidence and permission boundary for the suggestion;
• the next human step if the evidence is stale, conflicting or incomplete.

“Who knows about this?” is too broad for a useful search. Rewrite it as a question with a subject, a situation and an intended next step.

For example:

The first version asks for a name. The other versions give the system something to match: a process, a technical object, a past decision and a source that can be checked. If the question contains a customer, employee, contract or security detail, minimize that detail before sending it into a broad search.

The expertise-location patterns described by Stan Garfield include directories, communities, content authorship and ask-the-expert routes. Those patterns are useful starting points, but they do not remove the need to confirm current ownership. An old contribution can be a clue, not a decision.

• “Who owns the approval path when a customer requests a security exception?”
• “Who can confirm the current data model for the billing export?”
• “Who handled the last migration from this vendor, and where is the runbook?”

Create a small evidence record for each domain. It is more useful than a single “expert score” because a reviewer can see what changed.

Do not treat every activity signal as equal. A named owner in a current, approved process may be stronger evidence than ten comments on an old project. A recent ticket can show who solved one problem while the service owner remains someone else. Keep those roles separate in the record.

The search layer may connect documents, project discussions, tickets, code repositories and profiles. OpenAI's Company Knowledge announcement describes connected work-app context and source-linked answers. Product pages from Mindbreeze and Starmind describe semantic connections and expertise signals. These are examples of capabilities, not proof that a particular deployment will identify the right person.

For a first workflow, prefer evidence that already has an operational owner:

Be cautious with private messages, calendar history, browser history, performance records and inferred personal attributes. They can be sensitive, hard to interpret and unsuitable as expertise evidence. A system that watches more activity is not automatically a system that routes questions more fairly.

• current process pages with a named owner and review date;
• approved architecture decisions with reviewers;
• service catalog entries and support queues;
• tickets with a resolved cause and a responsible team;
• repository ownership or review history for a defined component;
• training or skills records that the person has agreed to maintain.

The assistant's response should make it easy for the requester to contact the suggested person without pretending that the system made a final judgment.

The Kapa.ai comparison is useful for thinking about retrieval, source integration and the difference between a custom build, managed retrieval and workplace search. Whatever category you choose, keep the response contract outside the prompt. It belongs in tests, permissions and reviewable workflow logic.

The suggested expert should be able to say “I no longer own this,” “ask this other team,” or “the source is wrong.” Record the correction with its time, reason and new owner. Do not silently overwrite the evidence, because the next reviewer needs to understand why the route changed.

A small confirmation message can include:

You were suggested for this question because you are listed as the reviewer of the current billing export decision, last confirmed on 14 August. Do you still own this topic, or should it go to another person or queue?

If the person does not respond, the system should not raise their confidence. Escalate to the domain owner or queue after a defined interval. An unanswered suggestion is not a confirmed owner.

Use a question set that includes ordinary matches and uncomfortable edge cases. Run it under the identity of the requester, not only an administrator.

The test should measure the failure category, not just whether the answer sounded plausible. Was the wrong source retrieved? Was the person no longer responsible? Did the permission check run before the evidence was shown? Did the assistant confuse a contributor with an owner? Those answers tell you what to fix.

An onboarding assistant can answer a new hire's bounded question from approved material, as described in the onboarding guide. Expert routing starts when the answer is missing, disputed or owned by a person rather than a document. Link the two workflows, but do not make a new hire's private question a new expertise signal without a policy for consent and retention.

Likewise, an expert finder should not become a hidden performance-ranking system. Explain which sources are used, let people correct their records, limit visibility by role and provide an opt-out or governance route where appropriate. The goal is shorter paths to accountable help, not a permanent score for every employee.

Choose one domain, such as billing operations or IT access, and release a read-only route:

If you cannot show why a person was suggested, which source supports the suggestion, when it was last confirmed and who handles disagreement, the workflow is not ready for broad employee use. A smaller route with visible evidence is safer and more useful than a company-wide directory that quietly guesses.

• List the recurring questions and the decisions behind them.
• Register the approved sources, owners, audience and review dates.
• Define the evidence fields and response contract.
• Run the acceptance set as several requester roles.
• Invite suggested owners to confirm or correct the route.
• Review stale, conflicting and no-match questions before expanding the source set.

Build a Business Brain around authoritative sources, permissions, human review and measurable operating results. Explore AI automation services →