The questions that actually uncover the current state

A useful current-state map needs exactly five ingredients: who is involved, what starts the process, what happens, where it branches, and every way it can end. The question bank below is organised around those five, plus the two things people always forget to mention: handoffs and exceptions. Capture the answers in the structure at the end of this guide and the map will draw itself.

1. Participants: who touches this?

You are separating two things here. Roles inside the organisation become swimlanes. Independent parties, such as customers, suppliers, or regulators, become separate pools that exchange messages with you.

• Who touches this process, from the very first signal to the final outcome?
• Which of those are teams or roles inside your organisation, and which are outside parties?
• For each step we discuss today, who actually performs it? Not who owns it, who does it?
• Is there anyone who only gets informed, or only gets consulted? What do they receive, and when?

Listen for the difference between a role and a person. If they say "Sandra checks it", ask what Sandra's role is called. Sandra will change jobs; the lane will not.

2. Trigger: what starts it?

The trigger becomes your start event, and its nature matters: a message arriving is different from a scheduled run, which is different from someone deciding to act.

• How do you know this process needs to happen? What actually arrives: a form, an email, a call, an alert?
• Can it start more than one way? Which way is most common?
• Does anything happen on a schedule rather than in response to something?
• What is the very first thing anyone does after the trigger arrives?

3. Activities: what happens, step by step

The single most effective discovery question is not "what is the process?" It is:

• Walk me through the last one you personally handled. What happened first?

The last real case beats the idealised description every time. Then, for each step they mention:

• What do you call that step? Try to name it as a verb plus a noun: review application, send contract, log request.
• Do you do that in a system, on paper, or in your head? Which system?
• Is that done by a person, or does a system do it automatically?
• What do you send to anyone else at that point, and what do you wait to receive?

The system and automation answers matter later: a human step, an automated step, and a send or receive step are different task types on the map, and the difference is often where the improvement opportunity hides.

4. Decisions: where does it branch?

Every decision becomes a gateway, and a gateway needs two things: the question being asked, and the possible answers. Get both in the room.

• Where in this process do you make a judgment call or apply a rule?
• What question are you answering at that point? Phrase it so it ends in a question mark.
• What are the possible answers, and what happens on each one?
• Which answer is most common? What percentage, roughly?
• Is there a default path when none of the conditions apply?
• Are there steps that happen at the same time, in parallel, rather than one after another? When do those paths meet again?

5. End states: every way it can finish

Processes rarely have one ending, but workshops usually only surface the successful one. Push for the full list; each distinct outcome is its own end event on the map.

• How does this end when everything goes well? What is the final act: an email, a record update, a payment?
• How else can it end? Rejected, cancelled, abandoned, escalated, timed out?
• When it ends badly, who tells the customer or requester, and how?
• How do you know it is finished? Is there a state you can point to in a system?

The two follow-ups that expose reality

• When did this last go wrong? What happened, step by step?
• Where does work queue up or wait? Who are you usually waiting for?

The first question surfaces the exception paths that never appear in the official description. The second surfaces the handoffs, which are where most processes actually lose their time.

Capture it so the map draws itself

Write your workshop notes in this structure. It reads naturally in the room, and it contains exactly the five ingredients a process map needs:

Process: [name]

Participants:
- [Role or party 1]
- [Role or party 2]

Trigger: [what starts it]

Steps:
1. [Role] does [verb + noun activity]
2. Decision: [question]?
   - If [answer A]: [what happens]
   - If [answer B]: [what happens]
3. [Steps that happen in parallel, if any]

End states:
- [Outcome 1]
- [Outcome 2, including the unhappy ones]

This is the same structure Swimdraft suggests in the studio, and that is not a coincidence. Paste notes in this shape, or attach the raw workshop transcript, and Swimdraft turns them into a BPMN 2.0 diagram validated against the OMG specification, with your participants as lanes, your trigger as the start event, your decisions as labelled gateways, and every end state accounted for. You can then edit every shape and label before exporting.