How to mine expertise

Most companies ask experts the wrong question. They ask: what do you do? The expert gives a job description. That is not expertise.

The better question is: how does the work really move? Not when everything is clean. Not when the case is easy. When the case is messy. When the data is missing. When the customer is angry. When the policy is too simple. When two sources disagree. When someone has to decide. That is where expertise appears.

Start with a real case

Do not start with the org chart. Do not start with the process document. Do not ask the expert to explain everything they know. Start with one real case. A quote. A claim. A ticket. A renewal. A supplier issue. A customer complaint. A contract exception.

Ask: walk me through this from the moment it reached you to the moment it left you. Real cases stop people from giving abstract answers. When people talk in general, they describe the official process. When they talk about a real case, they reveal the work.

Find the real path

Every process has two paths. The official path is what the company says should happen. The real path is what people do when the work matters. Both are useful. The gap between them is where expertise lives.

• What was supposed to happen?
• What actually happened?
• Where did you follow the normal path?
• Where did you leave it?
• Why?

That last question matters most. Without why, you only have steps. With why, you start to get judgment.

Follow the decisions

A process without decisions is just movement. Expertise lives in decisions. Should we approve this? Should we stop? Should we escalate? Should we trust this source? Should we treat this as normal or risky?

For every decision, ask three things. What did you decide? What did you check? Why did it matter? The expert may say: I checked the customer's history. Keep going. What part of the history mattered? Payment? Complaints? Contract size? Renewal risk? A previous exception?

Look for exceptions

The standard case is useful. The exception is more useful. Experts often do not notice their expertise in the easy case. The easy case feels obvious to them. So ask about what breaks.

• What makes this case hard?
• What makes it risky?
• What happens more often than people think?
• What is rare but dangerous?
• What is not written anywhere?

Exceptions show the real shape of the work. They show where the process is too simple. They show where the system is stale. They show where a new employee will get stuck. They show where an agent would fail. Do not treat exceptions as noise. Often, they are the point.

Ask what sources they trust

Companies have official sources. Experts have trusted sources. They are not always the same. The CRM may be official, but one field may be wrong. The policy may be official, but the team may use a newer version. The dashboard may be correct in general, but wrong for this case.

• What did you check?
• Which source did you trust?
• Which source did you ignore?
• Which field is often wrong?
• Who do people ask when the source is unclear?

This is not yet a tech question. It is a truth question. Before you connect systems, you need to know which sources people believe.

Trace the handoffs

Work moves between people. A lot breaks in the handoff. Ask: who gave this to you? What did they include? What was missing? Who did you send it to? What did they need? What usually gets lost? Who can block this work?

Handoffs show the social map of the company. They show who really owns the work. They show where the process depends on trust. They show where knowledge is trapped between teams.

Separate habit from expertise

Not everything an expert does should become company truth. Some of it is style. Some of it is habit. Some of it is a workaround. Some of it is old. Some of it is wrong.

Expertise mining is not transcription. It is not writing down whatever the senior person says. Ask: Would another strong person do the same thing? Is this always true? Is this your style or the company rule? Is this still current? What happens if someone does it differently? Who should approve this?

The goal is not to copy the expert. The goal is to find the reusable knowledge inside the expert's work.

Validate it

Raw expertise is not truth. It is evidence. One interview is not enough. One workshop is not enough. The expert should review the output. Another strong person should challenge it. The owner should approve it.

Disagreement should not be hidden. If two experts do the work differently, find out why. Maybe one is wrong. Maybe both are right in different cases. Maybe the company has two different expertises with the same title. Validation is not paperwork. It is how expertise becomes safe to use.

Package it

The output should not be a transcript. It should be a package. A useful expertise package says:

• what the work is for
• how the work moves
• what decisions matter
• why decisions are made
• what exceptions change the path
• what sources are trusted
• what tools are used
• who hands off to whom
• what needs approval
• what risks matter
• what is still unknown
• who validated it

It should be clear enough for a person. It should be structured enough for a machine later. That is the trick. Do not turn judgment into vague prose. Do not turn judgment into dead data. Turn it into operating knowledge.

Keep it alive

Expertise changes. Tools change. Customers change. Policies change. The workaround becomes the normal path. The normal path becomes old. So the package cannot be a monument. It has to be a version.

When someone corrects it, learn. When a new exception appears, learn. When a new employee gets stuck, learn. When an agent fails, learn. When a handoff breaks, learn. Then update the expertise with approval. Do not let the system change itself in secret. But do not let the knowledge freeze either.

The simple method

1. Start with a real case.
2. Walk the real path.
3. Find the decisions.
4. Ask why.
5. Find the exceptions.
6. Find the trusted sources.
7. Trace the handoffs.
8. Separate habit from expertise.
9. Validate it.
10. Package it.
11. Keep it alive.

That is how expertise becomes operating knowledge. Once a company has that, many things get easier. Onboarding gets easier. Process improvement gets easier. Succession gets easier. Quality gets easier to manage. Automation becomes possible.