Process Discovery Interviews: Questions, Steps, and Follow-Up

A process discovery interview is a structured conversation with the person who does the work, aimed at capturing what they actually do, in what order, with which tools, and why they choose one path over another. Done well, it surfaces the exceptions and judgment calls that no written procedure holds. This guide covers how to prepare, which questions to ask, how to document what you hear, and how to check it afterward.

TL;DR

• Interview the people who do the work, not only the people who manage it. Two or three performers per process beat one "expert."
• Ask about the last time something happened, not about how it "usually" goes. Specific cases expose exceptions; generalities hide them.
• Probe for decisions: what the person looked at, what they ruled out, and what would have changed their mind.
• Write up the findings within a day, sort them into categories, draw the current-state map, and have the interviewee correct it.
• Pair interviews with observation or document review when the work is visual, rare, or heavily tool-driven.

Table of Contents

• What a process discovery interview is for
• Prepare before you sit down
• A question bank that works
• Running the conversation
• Document what you hear
• Validate before you trust it
• Techniques that complement interviews
• Using interviews to keep knowledge and speed up onboarding
• Our perspective
• Put it into practice with Kept
• FAQ
• Sources

What a process discovery interview is for

Most organizations already have documents describing their processes. Those documents tend to describe the process as designed. A discovery interview finds the process as practiced: the workaround someone built three years ago, the customer who always gets a phone call first, the approval that is technically required but actually happens in a hallway.

In our experience, a good interview uncovers four things a document rarely contains:

• Steps that never made it into the SOP, often because they feel too obvious to the person doing them.
• Decision points and thresholds: the "if it's over this amount, do that" rules that live in someone's head.
• Handoffs and dependencies: who sends what to whom, in which tool, and what happens when the receiver is out.
• Exceptions and their reasons: the cases where the standard path fails and what experienced people do instead.

That last category is the one that walks out of the building when someone leaves. Interviews are the most direct way to get it onto paper before then.

Prepare before you sit down

Define the process boundary

Pick one process and write down where it starts and where it ends. "Customer onboarding" is too wide. "From signed contract to first invoice sent" is an interview you can finish in an hour. If you cannot name the trigger and the finished state, you will collect a pile of anecdotes instead of a process.

Choose whom to interview

Aim for a small, deliberate mix:

1. The performer. Someone who does the work weekly. They know the real sequence.
2. The most experienced person. They know the exceptions and the history.
3. A neighbor in the chain. Someone who hands work in or receives it. They will describe the handoff from the other side, which often contradicts the first account.
4. The owner or manager. They know the intended design and the metrics, but treat them as a check against what performers say, not as the main source.

Interview individually first. In a group, people tend to agree with the most senior voice, and nobody wants to describe a shortcut in front of their boss.

Gather what already exists

Read the current SOP, any checklist, and a few recent examples (tickets, emails, forms) before the call. This lets you spend interview time on the gaps instead of asking the person to recite what is already written. It also gives you concrete artifacts to point at.

Set expectations

Tell the interviewee, in plain words, that you are documenting the work, not evaluating the person. Say how the notes will be used, who will see them, and that they will get to review the result. People describe their real habits only when they trust that those habits will not be used against them.

A question bank that works

Questions fall into stages. Move through them in order, and expect to jump back when an answer opens something new. For a deeper manager-focused version, see our four-stage process interview questions.

Stage 1: Scope and trigger

• What kicks this process off? Who or what sends the first signal?
• What does "done" look like, and who confirms it?
• How often does this happen, and how long does one run usually take?

Stage 2: Walk through a real case

Ask for the most recent instance, not an average one.

• Think of the last time you did this. What was the very first thing you did?
• Then what? And after that?
• Which tools or systems did you open at each point?
• Was anything different from how you would normally do it?

Recent cases are easier to recall accurately than habits, and they surface variation honestly.

Stage 3: Decisions and judgment

This is where most interviews stop too early. Keep going.

• At that point, what were you looking at to decide?
• What would have made you choose the other option?
• Is there a number, a customer type, or a warning sign that changes what you do?
• Which step could a new hire skip without anyone noticing for a month? Which one could they not skip?

Research on expert elicitation supports this approach. The critical decision interview method uses probing questions to move people beyond their espoused theories about their actions and toward their actual practice. In plain terms: ask what happened and why, then ask again.

For a compact set of prompts built on this idea, see our five SME questions for capturing tacit decisions.

Stage 4: Handoffs, exceptions, and pain

• Who gives you work, and in what form? Who receives yours?
• What do you do when the input is incomplete or late?
• Tell me about a time this went wrong. What happened, and how did you fix it?
• Where do you lose the most time? What do you re-enter or double-check?
• What do you wish someone had told you in your first month?

The last question reliably produces the content you want for onboarding.

Stage 5: Close the loop

• What have I not asked that I should have?
• Who else does this differently from you?
• If you were out for three weeks, what would break first?

Running the conversation

A few habits make the difference between a useful hour and a polite one.

Ask for the story, then for the rule. Let the person narrate a case. Only afterward ask, "Is that always how it goes?" The gap between the two answers is your exceptions list.

Stay neutral about the process. Do not suggest improvements during discovery. The moment you critique a step, the interviewee starts defending it or hiding the next one.

Follow vague words. "Usually," "it depends," "just check it": each one hides a decision. Ask, "Depends on what?" and "Check it against what?"

Use silence. Experts often pause before giving the nuance. Wait.

Keep it to about an hour. Past that, answers get shorter and more general. Schedule a second session rather than stretching the first.

Document what you hear

Notes taken during the interview are raw material. Turn them into something others can use within a day, while the context is fresh. A practical sequence, in line with university guidance on synthesizing interviews, is to take detailed notes, group them into categories, and then build a current-state swimlane diagram.

Here is how we would adapt that for a discovery project:

1. Clean the notes. Separate what the person said from what you inferred. Mark inferences with a question mark.
2. Sort into categories. Steps, decisions, exceptions, tools, handoffs, pain points. Anything that does not fit goes in a "parking lot" list to ask about later.
3. Draw the current-state swimlane. One lane per role or system, steps in sequence, decisions as branches. Draw what happens, not what should happen.
4. Attach the reasoning. Next to each decision, record the condition and the reason. A map with boxes but no reasons is a flowchart of ceremony.
5. Link the evidence. Reference the example case that produced each step, so a reviewer can trace it back.

If you want to see what good output looks like, our process documentation examples show how exceptions can be captured alongside the main path. And for an end-to-end approach, see our seven steps to process documentation.

Validate before you trust it

An interview is one person's account. Treat the first draft as a hypothesis.

• Play it back. Show the interviewee the map and ask them to correct it. People will fix a diagram much faster than they will recall a step unprompted.
• Cross-check with a second performer. Differences between two people doing the same job are information. Some are harmless style; some are two versions of the process that produce different results.
• Test against real cases. Pick three recent instances, including one that went badly, and trace them through the map. If the map cannot explain one of them, something is missing.
• Check the handoffs from both sides. Ask the receiving role to confirm what they get and when.
• Confirm with the owner. Show where practice diverges from the designed process and let them decide which one is right.

Only after this step does it make sense to talk about improvement or automation. When automation is the goal, mapping first matters: confusing process with procedure is a common reason automation projects stall. For leaders weighing which steps are candidates, a practical guide to AI process automation covers the enterprise side of that decision.

Techniques that complement interviews

Interviews are strong on reasoning and exceptions, and weaker where memory is poor or the work is visual. Combine them with other techniques.

Contextual inquiry deserves a note. Nielsen Norman Group describes it as a method in which observation and collaborative interpretation uncover hidden insights about people's work that other methods can miss. A healthcare study on workflow analysis makes a similar point, noting that contextual inquiry can reveal the motives, patterns, and structure behind how tasks get done. A short shadowing session after an interview is often the fastest way to catch what the person forgot to mention.

For a wider comparison, including the limits of log-based methods, read our process discovery methods overview. If your next step is a group session, our process mapping workshop guide covers the steps and how to capture decisions.

Using interviews to keep knowledge and speed up onboarding

The same interview serves three purposes at once.

Continuity. Interview the people whose departure would hurt most, before they leave. Focus on stage 3 and 4 questions: decisions and exceptions. A retiring specialist's last month is better spent being interviewed twice than writing a thirty-page handover nobody reads.

Onboarding. New hires learn fastest from real cases. Use the recorded scenarios ("here is what happened last quarter and why") as training material, alongside the map.

Oversight and complex workflows. Project managers and enterprise teams gain a shared, current-state picture before they change anything. When a workflow spans several departments, interview each side of every handoff and reconcile them on one map. Our guide on capturing decisions, not steps goes deeper on why this matters for teams.

A practical way to start: choose one process that a single person owns today, schedule two one-hour interviews, and draft the map within a day of the second one. If you want a place to keep the resulting notes searchable and linked to their sources, a knowledge workflow built on saved notes shows one way to organize it.

Our perspective

We have sat through a lot of documentation projects, and the pattern repeats. A team writes the procedure, files it, and a few months later discovers that the person who actually did the work was following something quite different. The document held the steps. The person held the judgment.

That is why we think the interview is the real unit of process discovery, and why we built Kept around it. The problem with a traditional interview is that it depends on a skilled interviewer being in the room, on notes being typed up, and on the interviewee having patience for a second round. Most organizations never get past the first conversation.

Kept is designed to run that conversation as a guided interaction. People describe their work in their own words, and the questions follow up on the exceptions and reasoning, not only the rules. The result is a structured workflow that keeps the context behind each decision. Workspaces are opt-in, with clear control over who sees what and the ability to review and delete what was captured.

If a process matters enough to document, it matters enough to capture how the best person on the team thinks about it. We would rather you start with one real interview this week than plan a perfect program for next year.

Anthony

Put it into practice with Kept

If you want guided interviews without scheduling a facilitator for each one, Kept lets employees describe a process in their own words and turns it into a structured, searchable workflow, with the exceptions and reasoning attached. Individuals can use a personal workspace, and teams can set up a business workspace with access controls. See the options on the Kept pricing page.

Teams most often start with expert handoffs or with onboarding new staff. Both begin with the same thing: one good conversation about how the work really gets done.

FAQ

How long should a process discovery interview take?

Plan about an hour for one well-bounded process. If the process has many branches or the person is walking through several cases, book a second session instead of extending the first. Shorter, focused sessions produce more specific answers.

How many people should I interview for one process?

Two or three performers plus one person from each adjacent handoff is a good starting point. Add the process owner as a check against the intended design. Keep going until new interviews stop revealing new steps or exceptions.

What is the difference between process discovery questions and customer discovery questions?

Customer discovery asks about the needs and behavior of potential buyers. Process discovery asks employees about internal work: steps, decisions, tools, handoffs, and exceptions. The interviewing skills overlap, such as asking about past behavior and avoiding leading questions, but the output is a process map, not a product hypothesis.

Should I record the interview?

Recording helps you capture exact wording, but only with the interviewee's clear consent and in line with your company's policies. Tell them how the recording will be stored and who can see it. If they hesitate, take notes instead.

When should I use observation instead of an interview?

Use observation when the work is highly visual, happens too quickly to describe, or involves many small tool switches. Many teams do both: interview first for reasoning, then shadow for a short session to catch what the person did not mention.

Sources

• A Critical Decision Interview Approach to Capturing Tacit Knowledge (ResearchGate)
• How to Synthesize Interviews (University of Maryland IT)
• Contextual Inquiry: Inspire Design by Observing and Interviewing Users (Nielsen Norman Group)
• Approaches to Workflow Analysis in Healthcare Settings (PubMed Central)

Recommended

• Process Discovery Methods: 7 Steps, Model Tests, and What Logs Miss
• Managers’ Process Interview Questions: Four Stages That Catch Gaps
• 5 SME Questions Team Managers Use to Capture Tacit Decisions in 1 Hour