How to Run a Process Discovery Workshop

Before you invite anyone, decide what you are discovering. A discovery session that tries to cover "everything the operations team does" will produce nothing useful. Pick one process. Give it a name. Define where it starts and where it ends.

Use the trigger-to-outcome pattern: "This process starts when [trigger] and ends when [outcome]." For example: "This process starts when a customer submits a support ticket and ends when the ticket is closed."

If the process is large, break it into sub-processes and run separate sessions for each. A 90-minute workshop can usually cover 10 to 20 steps with reasonable depth. Beyond that, people lose focus.

Fabian's take

"I use what I call the "one-up, one-down" rule. Map one step before the trigger and one step after the outcome. This captures handoffs that participants might otherwise forget. The scoping article on how to map a process covers this in more detail."

The room needs people who do the work, not just people who manage it. A common mistake is inviting only team leads or department heads. They know the official process. The people on the ground know the real one, including the workarounds, exceptions, and shortcuts that no policy document mentions.

Aim for 3 to 8 participants. Fewer than 3 and you miss perspectives. More than 8 and the session becomes a meeting where half the room checks email.

Good discovery is structured conversation, not free-form brainstorming. Prepare questions in advance, but be ready to follow the thread when participants reveal something unexpected.

Opening questions

These get the conversation moving. Start broad, then narrow down.

• -"Walk me through what happens when [trigger]. Start from the very beginning."
• -"Who touches this process? In what order?"
• -"How do you know when this process is done?"

Drill-down questions

These uncover the details that make or break a process model.

• -"What happens if [step] goes wrong? Who handles it?"
• -"Is there a decision point here? What determines which path is taken?"
• -"How long does this step usually take? What causes delays?"
• -"What information do you need to start this step? Where does it come from?"
• -"Is this step always done the same way, or does it vary? What causes the variation?"

Validation questions

Use these near the end to check your understanding.

• -"Let me play it back: [summarize the process]. Does that match how it works?"
• -"What did I miss?"
• -"If a new hire joined tomorrow, what would surprise them about this process?"

Fabian's take

"The best question I know for uncovering the real process: "What would you tell a new colleague on their first day?" People drop the official language and describe what actually happens, including the shortcuts nobody documents."

A discovery workshop has a rhythm. Get it wrong and the session turns into a debate about edge cases at minute 15. Get it right and participants leave feeling heard and aligned.

The 90-minute structure

The gap between discovery and modeling is where most information gets lost. Participants said specific things. The modeler remembers a general impression. The diagram ends up reflecting assumptions, not facts.

To close this gap, capture notes in a structured format during the session. Each sticky note or line item should answer: Who does what, when, and what happens next.

Some teams model live during the workshop using a projected BPMN tool. This works well if the facilitator is comfortable modeling in real time. Others prefer to capture on sticky notes first and model afterward. Both approaches are valid. The key is that whoever models the result was in the room.

If you record the session (with consent), tools like AI-assisted process discovery can help convert transcripts into initial BPMN drafts. This is especially useful for distributed teams where the facilitator cannot model live while also managing the conversation.

Within 48 hours of the workshop, produce a clean diagram. The longer you wait, the more context fades. Send it to all participants and ask two questions: "Is this what we discussed?" and "What did we miss?"

Expect corrections. The first diagram is never perfect. That is fine. The point of the review is to catch misunderstandings before they become permanent. Two rounds of review are typical before the model stabilizes.

Once validated, the as-is model becomes the foundation for improvement work. The natural next step is as-is vs to-be modeling where you compare the current state with a designed future state.

Five mistakes that derail discovery workshops

Discovery workshop checklist

Related guides

Frequently asked questions