The 30-Minute Process Discovery Interview: How to Capture a Process Before You Map It

The promise of AI-native process mapping is that you upload any document describing a process and get back a clean BPMN diagram in two minutes. That promise holds, but it implicitly assumes the document exists in the first place. For most SMBs and most consultants picking up a new client, it does not. The Standard Operating Procedure has not been updated since 2019, the workshop notes are scattered across three Notion pages, and the actual current state of the process lives in the heads of the two people who run it every day. Before the upload, there is a step that gets very little attention: capturing that knowledge into a single, faithful, AI-ready document. The good news is that this step takes 30 minutes, not 30 hours.

The single biggest determinant of the quality of an AI-generated BPMN is not the model, the prompt engineering, or the post-processing. It is the input. A clean 5,000-word transcript of a stakeholder describing how they actually do their job produces, on the first pass, a more accurate diagram than a 50-page SOP that has been politically negotiated to consensus. This is not a bug in AI tooling. It is a feature: the AI is a faithful translator from prose to structure, and faithful translation of a polished lie produces a polished lie.

The most common discovery interview mistake is interviewing the manager. The manager describes the policy: how the process is supposed to run, what the official handoffs look like, what the SLAs say. The doer describes the reality: which steps everyone skips because the system is slow, which approvals are rubber-stamped because the rule is unenforceable, and where the process forks based on who happens to be on duty. The diagram that comes out of a manager interview is the diagram that should exist. The diagram that comes out of a doer interview is the one that does.

For a typical 20-task process, the doer is the operations associate, the customer service rep, or the analyst who sits in the middle of the workflow. They are not the most senior person involved, and they are very rarely the person who originally designed the process. Look for the person who would train the next new hire, because that person is the practical authority on how the work actually moves.

What to do when the process spans several roles

Many real processes cross three or four roles. Resist the temptation to gather all of them into one round-robin meeting: that format produces a transcript dominated by the most senior or most talkative person, with the actual operators speaking last and least. Run separate 20-minute interviews with each operator instead, then concatenate the transcripts before upload. The AI multi-source classifier will surface contradictions between the accounts as clarifying questions, which is the moment the most valuable insights show up: the contradictions almost always mark the parts of the process that nobody documented.

A productive process discovery interview has four phases, in this order. The order matters because each phase prepares the AI for a different stage of its pipeline: trigger and outcome anchor the start and end events, the walkthrough produces the as-is task list, exceptions populate the gateway logic, and the wishlist gets stored as a separate target-state intent rather than mixed into the current diagram.

1. Phase 1, Trigger and outcome (5 minutes). What event causes this process to start? What is the visible end state from the customer's perspective? Capture both clearly: the AI uses these as the start event and end event of the BPMN. A process with a fuzzy trigger ('whenever the team feels ready') and a fuzzy outcome ('the customer is happy') generates a diagram with weak boundaries that drifts into adjacent processes.
2. Phase 2, Walkthrough as-is (15 minutes). Ask the interviewee to walk through one specific recent example, end to end, in the order it happened. Use a real case from the past two weeks, not an abstract typical case. Talk-aloud format: 'so the order arrived in my inbox at 9:14, then I checked the customer account in CRM, then I noticed the address was a PO box so I forwarded it to John in shipping...'. Do not interrupt for clarifications during the walkthrough. Note your questions and ask them after the story is complete. Interruption fragments the narrative; the AI extracts sequence better from a continuous account.
3. Phase 3, Exceptions and KPIs (8 minutes). What goes wrong in 1 case out of 10? What goes wrong in 1 case out of 100? What is the typical end-to-end time? How many cases per week or per month? Roughly what does each step cost in time and tools? You are populating the gateway logic and the KPI fields here. Approximate numbers are infinitely more useful than no numbers: a duration of '15 minutes' is better than a duration of 'a while', and the AI cannot estimate cost from 'a while'.
4. Phase 4, Wishlist parking lot (2 minutes). What would you change if you had a free hand? What is the most painful step? Capture this faithfully but separately. The AI will treat it as target-state intent rather than current-state fact, which is exactly what you want.

Every productive question in a discovery interview falls into one of five categories: actors, sequence, decisions, exceptions, and KPIs. Each category targets a specific part of the BPMN that the AI needs to produce. The questions below are formulated to be open-ended, because open-ended phrasing produces narrative answers that the AI extracts cleanly, while closed phrasing produces yes-or-no answers that strip out the context.

1. Actors: who does each step

• Who else is involved in this process besides you?
• When you finish your part, who is the next person to touch this work?
• Are there any steps where the same person plays a different role depending on the case? For example, sales person in some, account manager in others?

2. Sequence: what happens after what

• Walk me through one specific case from the last two weeks, in the order it happened. Don't summarise: tell me what came first, what came second, what came third.
• When you receive [trigger event], what is the very next thing you do, before anything else?
• Is there ever a step that happens out of order, like later in the process you have to circle back to an earlier system or earlier role?

3. Decisions: branches and conditions

• Are there moments where you have to decide between two paths? What is the criterion?
• Is there ever a case where you skip a step entirely? What triggers the skip?
• Are there approvals that can be self-served versus approvals that have to be escalated? Where is the line?

4. Exceptions: what breaks, how often, what then

• When does this process not go to plan? What is the most common breakdown?
• What happens roughly 1 time in 10 that would surprise an outsider?
• Have you ever had to redo a step because of an upstream error? Walk me through what triggers the rework.

5. KPIs: duration, frequency, cost

• Roughly how long does the whole process take, end to end, on a normal case?
• How many of these do you handle per week, or per month?
• Of the steps you described, which one is the most time-consuming in active work? Which is the most expensive in tools or external fees?

These five mistakes account for almost every weak first-pass BPMN we see in support tickets. Each of them is invisible in the input document but obvious in the output diagram, which is why they fall on the human-preparation side rather than the model side.

1. Mixing as-is and to-be in the same transcript. The interviewee describes the current process in one sentence and a hoped-for future improvement in the next ('we currently route by hand, but we want to add an automatic credit check'). The AI will treat both as factual current-state unless multi-intent detection catches it, and even when it does catch it the result is two muddled half-diagrams. Solution: when the interviewee shifts into wishlist mode, mark it explicitly in the transcript or save it for Phase 4.
2. Bundling several processes into one interview. Onboarding, renewal, and cancellation are three separate processes with three separate triggers. An interview that drifts across all three produces a transcript the AI either splits weakly or merges incoherently. Solution: pick one process per interview, period.
3. Designing the future state during discovery. Discovery is a documentation activity, not a design activity. The moment the conversation turns into 'and then we should add an approval here', you have stopped capturing reality and started inventing it. Both are useful, but they belong in different interviews. Solution: park improvement ideas explicitly in Phase 4, and run a separate target-state interview later.
4. Recording the policy instead of the reality. The interviewee describes what is supposed to happen rather than what actually happens. This is especially common when a manager is in the room. Solution: ask 'walk me through the most recent case' rather than 'how does this normally work', because real cases are concrete and policies are abstract.
5. Over-cleaning the transcript before upload. Some users feel obligated to rewrite the transcript into clean SOP format before uploading, on the assumption that polished input produces polished output. The opposite is true: the AI extracts process structure better from raw, slightly disordered prose than from a sanitised summary, because the summary loses the qualifications, edge cases, and tacit decisions that the AI uses to populate gateway branches and KPI estimates. Solution: upload the transcript exactly as it came out of the transcription service. Typos and umms included.

The output of a 30-minute discovery interview is the input you want for an AI process mapping run. Concretely: a 3,000 to 6,000 word transcript, in the interviewee's own voice, organised in the order they walked through the process, with KPI numbers from Phase 3 attached and wishlist items kept in a separate section. Upload it directly, without rewriting.

If you have multiple sources, drop them all at once: the discovery transcript, plus any existing partial SOP, plus screenshots of the systems involved, plus a couple of representative emails. The upload flow is built to ingest several documents in a single session and treat them as one unified source. The AI will surface contradictions between them as clarifying questions, which is exactly the moment your most valuable insights appear: contradictions usually mark the parts of the process that nobody documented.

What format works best

• Plain text or markdown wins on reliability. The transcript service output, pasted as-is into a .txt or .md file, parses cleanly and preserves prose structure.
• Word documents (.docx) work equally well for the AI but add a layer of formatting that occasionally hides content (footnotes, comment threads). If you receive a Word doc you did not write, paste the text into a plain .txt and upload that instead.
• PDFs are fine for SOPs and policy documents, especially when layout matters (tables, diagrams). They are not ideal for transcripts, where the formatting adds nothing and sometimes interferes with parsing.
• Multiple short sources beat one polished long source. A 3,000-word raw transcript plus a 1,500-word SOP plus three screenshots is a stronger upload than a single 8,000-word polished document, because the contradictions across sources surface insights that a polished document smooths over.