Find internal experts using company knowledge
Find the right colleague using evidence from company work. Protect access, confirm availability and test whether questions reach the right person.
To find internal experts using company knowledge, start with a specific work question. Search approved project records and profiles for relevant experience, show the evidence behind each suggested contact, then confirm who can help. Keep a team contact available when the evidence is weak or the person is unavailable.
The expensive mistake is often a plausible name. A colleague appears on an old project document, so everyone sends them questions about the system. They helped write the requirements, but another team now operates it. Search has made the wrong introduction faster.
An expertise locator needs to handle that distinction. It should help a requester reach someone who can take the next useful step, rather than treating every document author as a permanent owner.
The examples and evaluation method below are proposed designs. They are not measured results from a LeanOrchestr customer deployment.
Describe the question before searching for people
“Who knows about billing?” is a reasonable way to ask a colleague. It is a poor test of an automated recommendation. The answer could be someone who understands the software, an accountant who owns reconciliation or a manager who approves a commercial exception.
Write down the decision or problem, the affected process, relevant version or date, and the help needed. Include what the requester has already checked. Do not make people learn your internal department names before they can ask.
For example, a support lead might submit this illustrative request:
We are seeing duplicate invoice lines after the latest subscription import. The import completed this morning, and the current runbook does not cover this error. Who can review the mapping for the new billing system? We need a technical check before the next run. Customer records can be shared only through the approved incident channel.
That request gives internal experts something to accept, redirect or narrow. It also distinguishes technical review from permission to change invoices. Someone may understand the import without having authority to correct a financial record.
When information is missing, ask a short clarification question. If the requester does not know the system version, the assistant can identify an eligible project reference or send the question to the responsible team. It should not fill the gap with an invented version.
Agree on urgency through an existing support process. Writing “urgent” in a chat must not bypass incident handling, grant access or make an unavailable colleague responsible for a response.
Build a candidate record that explains the match
A useful result needs more than a name and a relevance score. Record the person’s role in the work, the source supporting that connection, the date it applies to and what remains unknown.
Mindbreeze describes using projects, contributions, qualifications and work background to locate people. Those are possible evidence categories. They still need interpretation: editing a document’s formatting and resolving the underlying problem are different contributions.
For the billing example, the comparison might look like this. These people and records are fictional.
| Candidate | Permitted evidence | What the evidence does and does not establish |
|---|---|---|
| Maya, project analyst | Requirements document from the old billing rollout. | Knows the original requirements; no evidence of responsibility for the current import. |
| Ravi, implementation engineer | Reviewed change record for the current import mapping. | Contributed to the relevant change; current availability still needs confirmation. |
| Finance operations queue | Current service directory names the team as process owner. | Can route the issue and confirm responsibility; the queue itself is not proof of technical expertise. |
The result could suggest Ravi for the technical question and identify the finance operations queue as the accountable fallback. It should explain why Maya’s older contribution is less relevant here, without describing her as less capable.
Check that two similarly named people have not been merged. Use the company’s stable identity record, not a name match alone. Preserve historical attribution when people change roles, while updating who handles questions today.
Assign a profile owner and record when each association was last checked. A role change or project handover should trigger a review; the routine review interval can depend on how quickly that work changes. Mark unreviewed associations as uncertain rather than silently presenting an old inference as current.
Internal experts may be contributors, reviewers or people who solved an exception that never became a formal project. Let employees add relevant experience and correct inferred associations. A new colleague may have useful experience from earlier work even though the company has no documents with their name on them.
Do not turn document counts or message frequency into a hidden performance ranking. Those numbers measure visible activity, not the quality of someone’s judgment. For a requester, “reviewed this mapping change in June” is more useful than an unexplained score of 94.
Where the evidence is inadequate, return a team route or say that no supported match was found. An expertise locator should not always produce a person merely because its interface expects a result.
Use approved evidence without exposing private work
Begin with a small collection: a reviewed topic directory, current project ownership, approved handover records and relevant shared work. Follow the document preparation checks before relying on extracted names, table headings or dates.
Define which audiences may discover each association. A public employee directory can be visible while the project that connects someone to a sensitive topic remains restricted. Generating a profile from that project can disclose information even if the assistant never links the original document.
A proposed rule is to build the recommendation only from evidence the requester is permitted to use. If the organization needs a wider routing directory, have its owner explicitly approve what that directory may reveal. Do not silently infer a public skills profile from private cases.
Check summaries, document titles, snippets, cached answers and shared conversation exports. Hiding the source link is insufficient if the recommendation says that a colleague handled a confidential investigation.
Explain the collection policy to employees. They should know which sources inform their profile, who can see the result and how to correct it. Start without private messages, browser histories or personnel files. Adding any sensitive source should require a specific approved purpose and a review of the resulting exposure.
Stan Garfield’s historical survey of expertise-location approaches describes both profile-maintenance problems and privacy concerns around inferred expertise. Automation changes how evidence is gathered; it does not settle whether that use is appropriate.
Source permissions also change. Test removal from a project, a withdrawn document and a departed employee. Specify how quickly those changes must affect recommendations for your use case, then measure the actual behavior. Avoid promising immediate removal from every cache or existing conversation without checking the product.
Finish the introduction without overloading internal experts
Once the system has a plausible match, ask whether the person can help with this particular question. “Contributed to the import mapping” is a supported association. “Available to fix the issue today” requires different evidence.
Let the requester review a proposed message containing the problem, relevant permitted links and the help requested. Send it through an approved route only after the appropriate confirmation. Do not broadcast the same question to every candidate.
A useful contact record distinguishes suggested, contacted, accepted, redirected and resolved. A successful message delivery is only contacted. If delivery fails, retain the failure and offer the approved fallback; do not leave the requester waiting for an answer to a message nobody received. If nobody accepts, the request still needs an owner.
Give internal experts an easy way to decline, correct the match or refer the question to another team. A decline may mean the person is busy or the question is outside their current remit. It should not silently lower an expertise score.
Set a fallback with the team before rollout: a staffed queue, office hours, an on-call role or a moderator. Use the response expectations that team has actually agreed to. Do not manufacture a service-level promise from an old case study or a vendor demonstration.
This also changes the purpose of the directory. Repeatedly sending every question to one person may make the search look successful while creating a new bottleneck. Track the number of requests each person receives and the effort involved in reviewing them. Let teams share coverage and identify recurring questions that need a reviewed explanation.
When an answer becomes reusable, ask its owner to approve a knowledge-base entry. Strip out case details that should not be shared. Link the entry to the responsible team and its review date so that the next requester can find the explanation without reopening the same conversation.
The aim is to help internal experts spend time on judgment that requires them, while making routine guidance easier to find. Our article on company memory and who knows what explains why those human relationships belong alongside the documents.
Choose the smallest system that can support the work
You may not need another platform. A maintained topic/contact list can be enough when the organization is small, responsibilities are clear and a team member can route uncertain questions. A moderated forum is useful when the right person is best found through a community rather than a profile.
An expertise locator becomes worth testing when people cannot find those contacts across unfamiliar project names, changing responsibilities or several source systems. Compare options using your own requests, not the length of the connector list.
A purpose-built product may emphasize people matching. Starmind’s Expert Finder page describes matching work questions to contributors and providing a contact route. That is an advertised workflow, not proof that its recommendations meet your evidence or workload requirements.
An assistant already available in your workplace may help search permitted material. As checked on 10 September 2026, OpenAI’s Company Knowledge documentation describes a plugin for eligible ChatGPT Business, Enterprise and Edu workspaces. Plugin installation, source availability and authorization are separate requirements. That capability does not itself confirm a suggested person’s current responsibility or willingness to help.
In either case, ask the provider to show the evidence for a proposed contact, explain access changes and demonstrate a correction. If the answer contains source links, open them. If it does not, require a supported verification route before treating the association as reliable.
For a configured or custom workflow, allow for identity matching, source preparation, permission handling, profile review, routing and continuing support. These are part of the system’s cost even if the search interface already exists. Confirm current product entitlements and connector limits before purchasing.
There is a useful stopping point: if nobody owns the current contact list or the fallback queue, fix that first. Adding another search surface will expose the same unresolved responsibility to more people.
Test whether internal experts actually help resolve questions
Choose one team and a bounded set of real question types. Use approved or synthetic records for testing. Have knowledgeable reviewers establish which contacts or team routes would be acceptable, including questions for which no individual should be recommended. Agree on what qualifies a contact for each case before evaluating the system, so that simply accepting a message does not count as relevant expertise.
An expertise locator needs failure tests as well as easy matches:
| Test case | Required behavior |
|---|---|
| Old author, new process owner | Distinguish historical involvement from current responsibility. |
| Two employees share a name | Keep their work and identities separate. |
| Relevant evidence is restricted | Do not expose the document, sensitive association or derived profile to an unauthorized requester. |
| A project permission is revoked | Verify the observed removal behavior, including subsequent questions and cached results. |
| A quieter employee has confirmed relevant experience | Allow reviewed profile evidence; do not require high message volume. |
| The best-supported candidate declines | Record the decline and use the agreed fallback without repeated unwanted contact. |
| No evidence supports a person | Return an accountable team route or an explicit unresolved result. |
| A source tells the assistant to contact someone or send data | Treat it as source content, not authorization for an action. |
Measure the baseline before introducing automated recommendations. For comparable question types, record time spent locating help, the number of redirects, unresolved requests and the effort internal experts spend responding. Keep the scope and observation period consistent when comparing the pilot.
Define the measures so that a fast but wrong introduction cannot count as success:
- Reviewed routing correctness: recommendations judged relevant divided by recommendations reviewed. Report which question types were sampled.
- Time to accepted help: elapsed time from the request to a qualified person or team accepting it. Report unresolved requests separately; do not drop them from the account of the pilot.
- Resolution: resolved requests divided by all requests in the pilot cohort, with correctly redirected and still-open requests shown alongside.
- Contact burden: requests and review effort per participating person or team, including declined and misrouted work.
A small pilot can expose a broken handoff. It cannot establish a reliable company-wide productivity return. Compare the results with the simpler directory or forum, and include administration and correction time. State the measurement cutoff and the age of still-open requests. An average based only on quick acceptances will hide the people still waiting.
Agree on expansion conditions before seeing the results. Permission failures should stop expansion. Repeated unsupported matches need investigation. If internal experts receive more interruptions but requesters do not reach useful help sooner, examine routing and coverage before adding another data source.
For a Business Brain implementation, bring the pilot’s unresolved questions to the next design review. Ask which require better evidence, which need a different owner and which should remain human conversations. Expand only after someone accepts responsibility for those gaps.
Questions people ask
What is an expertise locator?
An expertise locator helps people identify colleagues with relevant knowledge or experience. It may use a maintained directory, approved work records or a question-routing community. Its recommendations still need checks for the specific problem, current responsibility and availability.
Can AI find internal experts from company documents?
It can identify possible contacts from permitted project records, authored work and reviewed profiles. A person's name on a document is evidence of involvement, not proof of expertise. Show the source and date, explain the relevant contribution and ask the person to confirm the match.
Do we need to monitor employee messages to find expertise?
No. Start with voluntary profiles, approved project records and a maintained contact directory. Explain which information is used and let people correct their records. Private messages, browser history and personnel files should not become default inputs just because a connector can reach them.
What happens when the suggested person has left or is unavailable?
Check current company identity and the agreed contact route before recommending someone. Keep a backup or staffed team queue. Preserve useful project history with its original attribution, but label historical involvement separately from current responsibility. An old author should not remain the default contact indefinitely.
How do we know an expertise locator is working?
Review whether recommended contacts are relevant, whether someone accepts the question, how long that takes and whether the work is resolved. Include unresolved requests and expert workload. More profile views or fewer help messages alone cannot establish that people are getting useful help.