--- title: "How to find internal experts using company knowledge" description: "Route company questions to the right internal expert with source evidence, current ownership, permission checks, and a clear human escalation path." canonical: "https://innovate-blog.com/articles/find-internal-experts-company-knowledge" last-updated: "2026-09-10" --- # How to find internal experts using company knowledge > Route company questions to the right internal expert with source evidence, current ownership, permission checks, and a clear human escalation path. By Moez Zhioua. Published 2026-09-10. Updated 2026-09-10. Category: Business Brain. Estimated reading time: 12 minutes. ## In brief - 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 short answer To find an internal expert using company knowledge, treat the result as a supported introduction, not a leaderboard. Start with the question, search approved sources for evidence of current ownership, check what the requester is allowed to see, and show why a person was suggested. Then ask that person to confirm or correct the route. 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. ## Begin with a question that can be routed "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?" ## Build an evidence map before ranking people 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. - Evidence field: Question and scope; Example: "Billing export schema for the EU account flow"; Why it matters: Prevents a broad name search from losing the actual decision. - Evidence field: Source; Example: Current runbook, approved decision, ticket or repository path; Why it matters: Gives the reviewer something to inspect. - Evidence field: Contribution; Example: Owner, reviewer, decision-maker, recent resolver or author; Why it matters: Separates responsibility from incidental activity. - Evidence field: Freshness; Example: Last confirmed date and source revision; Why it matters: Makes stale expertise visible. - Evidence field: Permission result; Example: Requester can see the source, or only a safe summary is allowed; Why it matters: Stops private evidence becoming a public profile. - Evidence field: Confidence and gap; Example: High, medium or low with a reason; Why it matters: Makes uncertainty an explicit part of the handoff. - Evidence field: Confirmation route; Example: Suggested person, team queue or domain owner; Why it matters: Gives the request somewhere safe to go. ## Choose sources that show responsibility, not surveillance 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. ## Return a route, not a verdict 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. - Situation: One current owner is supported; Response shape: Name or team, evidence link, last-confirmed date and suggested question; Required human boundary: Owner confirms that they still handle the topic. - Situation: Several people have relevant evidence; Response shape: Short ranked list with the reason for each match; Required human boundary: Requester chooses the route or asks the domain owner. - Situation: Evidence is old; Response shape: Show the old source and label it stale; Required human boundary: Ask the domain owner to confirm before contacting the person. - Situation: Sources conflict; Response shape: Display the conflict and the competing owners or dates; Required human boundary: Do not choose the winner by language-model confidence. - Situation: Requester lacks source access; Response shape: Return a safe summary or team route; Required human boundary: Never reveal restricted document text as proof. - Situation: No match; Response shape: Say that no supported expert was found; Required human boundary: Offer a queue, manager or service-desk handoff. ## Add confirmation and correction 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. ## Test the permission and freshness boundaries 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. - Test: Current runbook has a named owner; Expected behavior: Suggests the owner or team with the runbook link and revision.; Evidence to record: Source ID, revision, requester role and response reviewer. - Test: Owner left the team; Expected behavior: Labels the old evidence and routes to the service owner or queue.; Evidence to record: Effective date, correction and new route. - Test: Two sources disagree; Expected behavior: Shows the conflict and asks for confirmation.; Evidence to record: Source dates and no invented resolution. - Test: Requester cannot read the supporting file; Expected behavior: Provides a permitted summary or a team route.; Evidence to record: Permission decision and redacted response. - Test: Private message is the only match; Expected behavior: Does not expose the message or infer a public expertise claim.; Evidence to record: Safe abstention and escalation destination. - Test: No supported match exists; Expected behavior: Says the evidence is insufficient.; Evidence to record: Sources checked and next human route. - Test: Suggested expert corrects the record; Expected behavior: Updates ownership through an auditable process.; Evidence to record: Who changed what, when and why. ## Keep onboarding and expert routing separate 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. ## A small first release 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.