15 Process Discovery Questions That Find Your Bottlenecks

Key Takeaway

Process discovery questions are the questions you ask to learn how a process really runs and where it breaks. Most published lists are business analyst templates for interviewing managers and stakeholders, and they produce the version of the process people think happens. The questions that find bottlenecks are short, concrete, and asked of the person who does the work, about the last real time it ran. Below are 15, grouped by what they find: triggers and starts, handoffs, waiting, workarounds and side spreadsheets, exceptions and judgment calls, single points of failure, the definition of done, and frustrations. Each comes with what it uncovers and a follow-up for when the answer is vague. Ask them in one recorded conversation, fix nothing while you are in the room, then sort the answers into the four stages of business process improvement. Across 16 businesses we studied, only 27% of the work was documented, so for most processes, asking is the only way to see them.

What Are Process Discovery Questions?

Process discovery questions turn a process nobody has written down into one you can see: what starts it, who touches it, where it waits, where it breaks, and how anyone knows it is finished. They come before mapping, before improvement, and long before software. The answers are what a process mapping session draws.

They are not requirements questions. Requirements gathering asks what a new system should do. Discovery asks what the current work actually does, including the side spreadsheet and the call made from memory.

That matters because so little is written down. When we gap-analyzed 16 small businesses across 68 roles and 461 process areas, the average business had 27% of its work documented. In 50.3% of role areas there was no documentation at all, and 82% of teams were below 50% coverage. On discovery calls, owners describe their operation with some version of the same sentence: it all lives in my head. One owner put the stakes plainly: unless all the use cases from end to end are captured, you have no idea what is truly wasted. Discovery questions are how it gets out of their heads and onto the table.

Who to Ask and How to Run the Conversation

Who answers and how matters as much as the questions. Five rules decide whether you get the real process or the official one.

Ask the doer, not the manager. The manager knows how the process is supposed to run. The person who runs it every day knows how it does run, including the workarounds the manager has never seen. If you can, add the newest person on the team, who still notices what everyone else has stopped seeing. Choosing that person is covered in how to interview subject matter experts.

Ask about the last real instance, not the typical case. "How does this usually work?" gets an average, and averages have no exceptions in them. "Walk me through the last time you did this" gets a specific day, a specific customer, and the thing that went sideways.

Record it. Put the work on a screen share and record the session. People compress what they do automatically, so a dozen clicks become "then I process it." The recording catches what the narration skips, which matters most with experienced people who have unconscious competence: they do the job well and describe it badly.

Use roles, not names. Write "the estimator hands it to dispatch," not a person's name. The process outlives whoever holds the seat this year, and an answer tied to a role is about the step, while one tied to a name starts to sound like blame.

Do not fix anything during the interview. The moment you suggest a fix, the person stops describing and starts reacting, either defending the current way or politely agreeing. You will also fix the first problem you hear instead of the biggest one. Park ideas in a separate column and come back once the whole process is on paper.

The 15 Process Discovery Questions

These are the questions to ask employees about the processes they run, grouped by the kind of break each one finds, in the order the work flows.

Triggers and Starts

1. What starts this process?

What it uncovers: the trigger, or the absence of one. A clear answer names an event: a signed proposal, a submitted form, a date. "When I get to it" means the step runs on memory.

If the answer is vague, ask: "What happened right before you started it the last time?"

2. How do you find out it is your turn?

What it uncovers: how work arrives. Some arrives through a system that says so. A lot arrives through a hallway comment, a text, or a habit of checking a folder. Every step that depends on someone noticing can be missed.

If the answer is vague, ask: "If you were out for a week, how would your replacement know there was something to do?"

Handoffs

3. When your part is done, who gets it next, and how do they know it has arrived?

What it uncovers: whether the handoff has a receiver. Listen for a group chat, a shared inbox, or "the team." A message to a group is not a handoff, because everyone on the receiving side can assume someone else has it.

If the answer is vague, ask: "Last time, how did you confirm they picked it up?"

4. Where does it usually fall?

What it uncovers: the crack itself. Of everything we ask on discovery calls, this question does the most diagnostic work, because people can almost always point at the spot. Owners often call a manual process workable: it works, though things can slip through the cracks. This finds out which crack. The usual locations are laid out in things falling through the cracks.

If the answer is vague, ask: "Think of the last thing that slipped. Where was it the last time you knew it was on track?"

Waiting

5. Where does the work sit and wait, and what is it waiting for?

What it uncovers: queues. Waiting is often the biggest part of how long a process takes, and it is invisible from inside any single step, because nobody is working on the job while it waits.

If the answer is vague, ask: "On the last one, what was the longest stretch where nothing happened to it?"

6. How long does this take from start to finish, and how much of that time is someone actually working on it?

What it uncovers: the gap between elapsed time and working time. If the work takes an afternoon and the customer waits two weeks, the rest is waiting, and the step where it piles up is your constraint. Finding the bottleneck in your business covers how to time it.

If the answer is vague, ask: "What day did the last one start, and what day was it finished?"

Workarounds and Side Spreadsheets

7. Do you keep anything on the side to make this work?

What it uncovers: shadow systems. The personal spreadsheet, the notebook, the email folder used as a to-do list. These often hold the real data, they show what the official system cannot do, and they leave when the person who keeps them leaves.

If the answer is vague, ask: "Show me what you have open when you do this. Is anything on screen that nobody else uses?"

8. Where do you type the same information more than once?

What it uncovers: double entry. The same customer name or job number keyed into two or three places by hand. It is slow, it creates mismatches, and it is the clearest signal a tool may help later, once the process is clean.

If the answer is vague, ask: "On the last one, which screens did you have open, and what did you copy between them?"

Exceptions and Judgment Calls

9. When does this not go the normal way?

What it uncovers: exceptions. The rush job, the customer with special terms, the order that arrives incomplete. The standard path is usually understood. Exceptions are handled from memory, which is why misses cluster around them.

If the answer is vague, ask: "Tell me about the last one that was different. What did you do?"

10. Where do you have to make a call, and what do you look at before you make it?

What it uncovers: decision points, where the right answer depends on context. These are the steps two people do differently and the ones a checklist leaves out. Getting the rule on paper is the work of documenting decision points.

If the answer is vague, ask: "What would a new person get wrong here?"

Single Points of Failure

11. What happens to this when you are out?

What it uncovers: whether the process depends on one person. If the honest answer is "it waits until I get back," the person is the process. That is a risk before it is an inefficiency, and capturing tribal knowledge is how you remove it.

If the answer is vague, ask: "The last time you took a few days off, what was waiting for you when you came back?"

12. What can only one person do, decide, or approve?

What it uncovers: the approval or knowledge bottleneck, very often the owner. Every step that needs one specific person moves at that person's pace. Owners who suspect it is them can confirm it with the interruption log.

If the answer is vague, ask: "Last time you needed a sign-off, who did you ask, and how long did you wait?"

Definition of Done and Quality

13. How do you know it is finished?

What it uncovers: whether a definition of done exists. "When it looks right" means it does not, so the output varies by who did it. Ask about the record too: is the job finished when the work is done, or when the report is filed and the invoice goes out?

If the answer is vague, ask: "On the last one, what was the very last thing you did before you moved on?"

14. What gets sent back or redone, and who catches it?

What it uncovers: rework, and where quality is really checked. Rework usually traces to a missing definition of done or a missing input upstream. Where it gets caught tells you how far an error travels before anyone notices.

If the answer is vague, ask: "Tell me about the last one that came back. What was wrong, and where did that start?"

Frustrations

15. What other frustrations have you noticed?

What it uncovers: the breaks the other 14 questions missed. We end every session with the same question: what other frustrations have you noticed, things out of your control, places where other people are inconsistent? Frustration clusters where processes break: the workaround, the double entry, the report rebuilt by hand.

If the answer is vague, ask: "If you could change one thing about this process tomorrow, what would it be?"

What the Answers Tell You

Each kind of answer points at a specific break, and each break belongs to a stage of the four-stage method: document, diagnose, improve, solve. Sorting answers this way keeps you from buying software to fix what is really a missing decision.

Notice how few rows end in software. Most of what discovery finds closes with a decision, an owner, or a written rule, which is why the four-stage method puts tools last.

What to Do With the Answers Afterward

• Draft the same day. Turn the recording into a written process while it is fresh, with each answer attached to the step it came from. That draft is the document stage.
• Tag every answer with its break. Use the table above. When several answers land on the same step, look there first.
• Turn gaps into the next session. Anything the recording cannot answer becomes a gap flag that opens the next conversation. A week back in the job also shows the doer what they missed, which is why we run a second interview about a week later.
• Pick one break and find its cause. Start where answers cluster, or where one miss costs the most. Run root cause analysis on it: ask why until you reach a step the business controls, never a person.
• Fix the process before the tools. Most breaks close with a trigger, a receiver, a decision rule, or a definition of done. Software comes last, with a clear job to do.
• Show the doer what changed. People support what they helped build, and the next round of questions gets easier.

Where to Start

Pick the process people complain about most, find whoever actually runs it, and book an hour with a screen share. Ask about the last time it ran. Open with "What starts this process?", close with "What other frustrations have you noticed?", and fix nothing until you have sorted every answer against the table.

That loop of asking, drafting, and correcting is the work The Systems Effect does: we interview the people who hold a business's undocumented knowledge and turn what they say into SOPs, process maps, and training their teams actually follow.

Frequently Asked Questions

What are process discovery questions?

Process discovery questions are the questions you ask the people who run a process to learn how it really works and where it breaks. Good ones are short and concrete: what starts this, who gets it next, where does it wait, where does it usually fall, how do you know it is finished. The answers become the first written version of the process.

What questions should you ask employees about their processes?

Ask about the last real time the work ran, not the typical case. Cover what triggers the work, how handoffs happen, where it waits, what workarounds and side spreadsheets exist, where judgment calls come up, what depends on one person, how anyone knows it is done, and what frustrates them.

Who should you interview during process discovery?

The person who does the work every day, not the manager who oversees it. The manager knows the intended process; the practitioner knows the real one, workarounds included. If you can, also talk to the newest person on the team, who still notices problems veterans have stopped seeing.

What is the difference between process discovery and process mapping?

Discovery is the questioning; mapping is the drawing. Discovery questions find the trigger, steps, handoffs, waits, exceptions, and breaks. A process map lays them out so everyone can see and correct them, often in the same session.

What should you do with the answers from a process discovery interview?

Draft the process the same day, with each answer attached to its step. Tag each answer with the break it reveals, such as a handoff with no receiver or a single point of failure. Pick the step where answers cluster, find its root cause, and fix the process before deciding whether a tool should hold the fix in place.