In 30 seconds

Ask the person to walk through one recent, real example from beginning to end. Keep asking what they looked at, decided, changed and did when the normal path did not work.

Your goal is not to extract a perfect process description. It is to make their expertise visible enough that you can check it together.

Start with a real case

“How does this process work?” often produces the official version. It is tidy, general and missing the details that make the work succeed.

Instead, ask:

A real invoice, service request or approval exposes the actual systems, shortcuts, decisions and handoffs. It also gives both of you something concrete to point at.

Before the conversation

Prepare a small amount of context:

  1. Write down what you currently think starts and ends the workflow.
  2. Ask for one ordinary example and, if possible, one difficult example.
  3. Make it clear that you are studying the work, not evaluating the person.
  4. Leave enough time to follow an unexpected branch.

Do not arrive with a finished solution. People will unconsciously edit their explanation to fit it.

Follow the work in order

For each step, ask five plain questions:

  • What do you receive or notice?
  • What do you look at before deciding?
  • What do you decide?
  • What do you create, change or send?
  • Who or what receives it next?

Write down the answer in the person's language. You can introduce formal terms later.

Find the decisions hidden inside routine actions

Experienced people often compress decisions into phrases such as “I check it,” “I know which one” or “then I process it.” Slow down at those phrases.

Useful follow-ups include:

  • What tells you it is correct?
  • What would make you stop?
  • Which information matters most?
  • When would another person make a different choice?
  • Where did you learn that?

The answer may be a stable business rule. It may also be judgment built from years of examples. Those require different kinds of support.

Ask what happens when the normal path fails

Exceptions are part of the workflow.

Ask about missing information, conflicting records, unusual customers, unavailable systems, urgent requests and cases that need approval. Then ask who notices the problem and how they recover.

Play back what you heard

End by describing the workflow back to the person:

This gives the domain expert a chance to correct your language and recover missing steps.

Common mistakes

  • Asking only what should happen.
  • Treating a workaround as carelessness before understanding why it exists.
  • Recording system screens but not the decisions between them.
  • Using technical language the person did not use.
  • Interviewing only a manager when other people perform the work.
  • Asking for every exception from memory instead of reviewing difficult examples.

What this does not solve

One interview does not prove that everyone follows the same workflow. Compare several examples and speak with people who handle different shifts, regions or exception types when those differences matter.

Good enough to move on when

  • You can name the trigger and the expected outcome.
  • You have walked through at least one real example.
  • The main decisions and information sources are visible.
  • At least one exception path has been discussed.
  • The person doing the work recognizes your summary.