The process interview: questions that get you the real steps

Ask someone to describe how they handle renewals and you'll get a clean four-step answer. It will be linear, it will make sense, and it will be missing about a third of the work.

Not because anyone is hiding anything. Because expertise goes invisible to the expert. The saved search they run first, the spreadsheet they keep because the real system doesn't fit, the two minutes spent checking whether the last person already started it — those stopped registering as steps years ago. They're just what doing the job feels like. And they are, reliably, where the money is.

So the interview isn't a conversation about the process. It's a technique for getting around the summary.

Ask for the last one, not the typical one

This is the whole thing. Everything below is a variation on it.

"Walk me through a typical renewal" asks someone to generalize, and generalizing is exactly the operation that deletes the detail you came for. You get the version from training, averaged and tidied.

"Open the last renewal you did and walk me through it" asks them to recall, which returns specifics: this client, this missing document, the call to the carrier, the forty minutes on hold. You'll hear "well, this one was a little unusual because—" and that's the sound of the interview working. The unusual ones aren't noise. If three consecutive instances are each unusual in a different way, the exception is the process, and you've just learned the most important thing about it.

When someone drifts back into the general — "normally what happens is" — steer back with "and on that one?"

Watch one happen

Better than any question: ask them to do the next one while you watch on a screen share, narrating as they go.

Ten minutes of this will show you things nobody reports. A second tab already open on the carrier portal. A copy-paste into a personal tracking sheet. A field filled in from memory because the system's default is wrong. A pause where they check something in email to make sure the request hasn't changed since Monday.

Ask about anything you see that wasn't described. Keep it curious rather than gotcha — "what's that tab doing?" — because the goal is a complete picture, and people stop volunteering things the moment they feel audited.

The questions

These are the ones that do the most work. Each is aimed at a specific thing that hides.

Trigger — "How do you know there's one to do?" The answer "I check the inbox a few times a day" is unpaid monitoring work. It never shows up on a process map and it fragments the whole day around itself.

Inputs — "What do you need in front of you before you can start?" Gathering is frequently half the elapsed time and almost never counted as part of the task. This question separates the work from the waiting.

Systems — "What's open on your screen while you do this?" The most efficient way to find shadow tools. The spreadsheet that isn't part of any system will show up here and nowhere else.

Exceptions — "When do you not do it this way?" The single most-skipped question in process capture, and the one that determines whether anything can be automated later. Ask it more than once, in different words: what makes one of these take twice as long? what kind comes back to you?

Handoff — "Who touches it next, and how do they know it's ready?" If the answer is "I email them," there's a status problem downstream. If it's "they check the folder," there's a status problem and a filing problem.

Failure — "What happens when it's wrong? When did one last go bad?" Rework is invisible in every self-report. The specific incident question gets past that, and it tends to surface the real cost of the process — not the typing, but the thing the typing occasionally causes.

Volume and duration — "How many last week? How long does one take, door to door?" Self-reported minutes run optimistic, always. Ask for a range rather than a number, or better, count a few. Door-to-door matters: people report the part they're doing and drop the part they're waiting on.

Coverage — "Who does this when you're out?" "Nobody, it just piles up" is a finding. So is a name nobody else would have guessed.

The wish — "If you could change one thing about this, what would it be?" Ask this last. Asked first, it reframes everything that follows as a complaint session, and you'll get the loudest annoyance instead of the actual shape of the work. Asked last, after someone has walked through a real instance, the answer is usually specific and usually right.

What not to ask

• "What's your process for X?" Returns the org chart's version. Every question above exists to avoid this one.
• "How would you automate this?" You've now asked someone to design a system, and people design around their own jobs — either protecting them or eliminating the wrong parts. Capture what happens; decide what to automate later, against tests.
• Leading tool questions. "Would it help if this were in the CRM?" plants an answer. Ask what's slow, not whether your idea would fix it.
• Corrections mid-flow. If they're doing something inefficiently, that's data, not a teaching moment. Interrupt once to correct and you'll get the sanitized version for the rest of the hour.

Say what this is for, out loud, before you start

Anyone answering detailed questions about how they spend their day is entitled to wonder whether they're being interviewed out of a job. If you don't address it, they'll answer carefully, and careful answers are useless — the exceptions vanish, the durations inflate, and the shadow spreadsheet never comes up.

So say what's true at the top, in one or two sentences: what the documentation is for, what happens to it, and whether headcount is on the table. If the honest answer is that some of this work will change, say that too. People handle "your job will look different" considerably better than they handle being studied by someone who won't say why.

This isn't a nicety. It's the difference between a capture you can build on and a fiction you'll discover was wrong in month three.

Write it down in fixed fields, during the session

Free-form notes feel faster and cost you later. Capture every process the same way, in the same slots: trigger, inputs, systems touched, steps, exceptions, handoff, failure mode, volume, duration, owner, coverage.

Two reasons. First, comparability — forty processes captured in the same shape can be ranked; forty pages of prose can't. Second, the volumes and durations have to be recorded while the person is in front of you. Reconstruct them afterward and you're guessing, and a guessed number is worse than an absent one because it looks like a fact in the final document.

We learned this the hard way on our own tooling: the biggest quality jump in turning interview notes into SOPs came from making the capture more structured, not from anything clever downstream. Garbage in, eloquent garbage out.

None of this is difficult, and a capable operator can run it on their own team tomorrow. What's hard is doing it forty times in two weeks, across departments, without going native on any one person's account of their own work — and then costing the result honestly. That's most of what the assessment is.