Read summarized version with
To document a process someone else does, stop trying to write the procedure and start trying to extract it. The SOP already exists inside the head of the person who does the job, so your role is note-taker and interviewer, not author, and the single biggest mistake is handing the writing back to the expert.
I’m Yuval, founder of Glitter AI. Before this I ran Simpo, where we built no-code in-app walkthroughs for product managers. I was the one in San Francisco while the dev team sat in Tel Aviv, which meant a lot of processes lived in someone else’s head, in another time zone, and I was constantly the person asking for them in writing.
I got it wrong for years. So here’s what I’d do differently, and what works when someone hands you “document the returns process” for a job you’ve never done yourself.
Teach your co-workers or customers how to get stuff done – in seconds.
Why “can you write that up?” produces nothing, or a list of clicks
At Simpo I asked our support lead to write up the customer escalation process. Seemed reasonable. He was the only one who really knew it, he ran it several times a week, and nobody in the company did it better.
Three weeks later a page showed up. A list of clicks: open the ticket, change the status, tag the account owner, move it to the second queue, notify the customer. Every action was correct. The document was useless.
It never said which tickets get escalated in the first place, or what he checked before moving one, or what he did when the account owner was on vacation (which was constantly). He’d written down the part he could see himself doing. The part that made him good at it? Missing.
I don’t think that’s one person failing. It’s the normal outcome. “Write it up” quietly asks an expert to do three jobs at once: remember a process they run on autopilot, decide what a stranger needs to know, and write clearly in a format they have never been taught. Most people are great at one of those and stuck on the other two.
So they stall. Your request sits in the inbox next to real work with real deadlines, and the SOP loses every time. When it finally shows up it’s thin, because it got written in twenty rushed minutes on a Friday.
The two ways process documentation fails
I’d name two failure modes. Nearly every stuck documentation project I’ve seen is one or the other.
The first is the blank page. You ask the expert to write it up, and you get nothing, or you get a list of clicks with no reasons. That’s the one this post covers, since it’s where most people land by default. And the fix isn’t a template or a polite nudge. It’s changing who does the writing.
The second is the observation trap. You watch them work, or you watch a recording, you capture every action perfectly, and you still miss the part that matters: why they did it that way, what they checked first, what happens when it goes wrong. Watching is great for actions and pretty much blind to reasons. That’s a topic for another post.
Both end up in the same place: a correct list of steps nobody can follow once something’s off. The blank page gets there by asking the wrong person to write. The observation trap gets there by never asking anyone anything.
You’re the note-taker, they’re the source
What finally made process documentation workable for me was dropping the idea that I had to know the process. You don’t. You have to get it out of someone who does, then write it down accurately.
Different skill. You can be decent at it on day one without ever having processed a return. You ask, they talk, you write, they correct. The expertise stays put, and the writing moves to whoever can actually sit down and do it.
I didn’t invent this. Structured intake from the person who actually performs the work is the core of job analysis, a practice that has been used to document jobs for the better part of a century, and it explicitly pairs observation with talking to the people doing the work. The interview has always been the method.
It also kills the excuse I hear most: “I’m not a writer.” You don’t have to be. I’ve written before about why documenting processes doesn’t require a writer, and that goes double for someone else’s work, since the words you’re writing down are theirs anyway.
The format is the easy bit. If you need it, how to write an SOP covers it. What’s hard is getting true, complete material to put in it. That comes from a conversation.
Who should hold the pen, and why it is never the expert
Whoever holds the pen has to do two things the expert cannot easily do: write for a reader who knows nothing, and notice the gaps.
The expert can’t write for a beginner because they can no longer un-know this stuff. When they skip a step, it’s because it feels too obvious to mention. That’s not laziness. Expertise more or less is compressed knowledge.
You’re well placed to spot the gaps exactly because you don’t do the job. When they say “then you just approve it,” you’re the one who says “approve it where?” That question is most of what you bring, and it’s one the expert can’t really ask themselves.
The split looks like this:
- The subject matter expert supplies: the trigger, the stages, the actions, the reasons, the exceptions, the corrections.
- You supply: the questions, the structure, the writing, the read-back, the maintenance.
- Nobody supplies: anything invented. If they didn’t say it, it doesn’t go in the document.
One more reason to hold the pen. Whoever writes the SOP ends up owning it, and experts make poor owners of their own docs. They won’t notice it’s out of date. They never read it.
How to set up an extraction session
Honestly, the setup matters more than the questions, because it decides whether you get the meeting at all. Three things.
The ask. Do not say “can you document the returns process.” Say: “Can I get twenty minutes to ask you about returns? You talk, I’ll write it up, and I’ll send it back for you to correct.” You’ve moved the work onto your plate and told them exactly what they owe you. In my experience people say yes to that nearly every time, and quickly, since it sounds like less work than whatever email they’re reading.
The length. Twenty to thirty minutes for one process, booked, with an end time. Not “grab me whenever.” A time-boxed slot with a clear job gets accepted. A vague standing offer gets pushed forever. If the process is big, split it into two sessions by stage instead of booking ninety minutes. Nobody explains anything well in minute seventy.
The artifact you promise back. Say what they’ll receive and when. “You’ll get a draft by Thursday, and all I need is for you to tell me where I got it wrong.” Correcting a draft is quick. Producing one from scratch is the thing they’ve dodged for three weeks. You’re swapping their hard task for an easy one, and that’s the whole deal.
Small logistics note: record the session if they’re OK with it, and tell them why. It’s not for a word-for-word transcript. It’s so you aren’t splitting attention between listening and typing, and you’ll ask better questions with your hands free.
Teach your co-workers or customers how to get stuff done – in seconds.
If the process lives on a screen, the conversation and the screens are two halves of one job. After the interview, have them record the workflow once while talking through it. That’s where Glitter comes in: it records screen on web, desktop and mobile, transcribes and structures the narration, drops the filler words, and produces a step-by-step guide with annotated screenshots that you can then edit, reorder and export. The reasons from your interview go around those steps.
What “done” looks like when you did not do the work yourself
I get asked this more than anything else, and the answer is fairly clean. You’re done when someone who has never done this task could follow your document and get the same result, and the expert agrees.
Here’s how to test that without doing the work yourself.
- Read it back out loud. Don’t send it. Read it. “So the way I have it, a return comes in, you check the order date first, and if it’s over thirty days you…” Corrections at this stage cost you a sentence. Corrections after the document is published cost you a rewrite and a bit of credibility.
- Check every stage has a visible confirmation. How do you know the stage worked? With no observable result, a beginner can’t tell if they succeeded, and they’ll just keep going with something broken.
- Check every “usually” and “normally.” They mark a branch the expert never finished explaining. Each is a question you still owe them.
- Hand it to a real beginner. The newest person on the team follows the document while you watch and say nothing. Each pause is a gap. It’s the only test here that isn’t somebody’s opinion.
- Get the expert’s sign-off in writing. Keep it short and boring: “reviewed and approved by the person who does this.” It makes the document official and it makes them the reviewer instead of the author, which is exactly the role you wanted them in.
If you want the wider frame around all of this, from scoping to maintenance, my complete process documentation guide covers the lifecycle. This post is just about the twenty minutes where the raw material comes out.
What to do when the expert says “it depends”
“It depends” isn’t a dodge. It might be the most useful sentence you’ll hear all session: you’ve just hit a decision point nobody has ever written down.
Don’t nod and move on. Ask one question: “Depends on what?”
Ask it plainly, then wait. You’ll usually get a short list of conditions, and each becomes a branch in the document. “It depends on whether they’re an enterprise account.” “It depends on how long ago they ordered.” That’s a rule. Thirty seconds ago it was invisible.
If the list runs long, push for the two or three most common cases and mark the rest as escalate. A doc that handles eighty percent of cases and says who to ask about the rest beats one that pretends every case is identical.
And if they really can’t answer, log it as an open question in your notes. Don’t guess in the document. A named gap is a task. A papered-over gap is a bug someone finds at the worst moment.
Common mistakes when documenting someone else’s process
All of these are mine, roughly ordered by how much time they cost me.
- Sending a template and asking them to fill it in. A template is a brief for you, not a question list for them. Asking a warehouse lead “what are some FAQs for this” gets you a blank stare. Asking “what does a new person get wrong in their first week” gets you the FAQ.
- Asking about the whole process at once. “Walk me through returns” gets you a summary. “Take the first stage only: what do you open, and what do you see when it worked?” gets you a procedure.
- Writing while they’re still talking. You’ll capture words and miss the reason. Listen, paraphrase it back, then write.
- Accepting the abstract. “Then you submit it” is not a step. Which button, what does it say, and what appears afterward.
- Inventing the connective tissue. When a step doesn’t quite join to the next one, the temptation is to smooth it over with a plausible sentence. Don’t. Mark it and ask. Everything a stranger can’t verify, they’ll eventually distrust.
- Making the expert the owner. They supplied the knowledge. You own the document, its accuracy, and its next revision.
- Waiting for a calm week. There isn’t one. The real deadline is the day the expert leaves, and that date isn’t on your calendar.
The person who does the job is rarely the person who writes it down
If you take one thing away: the bottleneck in process documentation is almost never writing ability. It’s access to what’s in someone’s head. And the standard way of getting at it, asking them to write it up, is about the one method guaranteed to fail.
Book the twenty minutes. Ask, listen, write, read it back. The procedure already exists, fully formed, in the head of someone who’d probably be happy to walk you through it. You just have to ask instead of assign.
Yuval, Founder and CEO, Glitter AI
Teach your co-workers or customers how to get stuff done – in seconds.
Frequently Asked Questions
How do you document a process you don't perform yourself?
You interview the person who does perform it, then write the document yourself and read it back to them for corrections. Book twenty to thirty minutes, walk through the process one stage at a time, and ask what they check, what they decide, and what they do when it goes wrong. Your job is extraction and writing, not expertise in the task.
Should the subject matter expert write the SOP or should someone else?
Someone else should write it. The expert is too close to the work to notice the steps they skip, and writing for a beginner is a separate skill from doing the job. Keep the expert as the source and the reviewer, and put the pen in the hands of the person who will also maintain the document.
How long should a process documentation interview take?
Twenty to thirty minutes for a single process is usually enough, and it should be booked with an end time rather than left open. If the process is large, split it into two sessions by stage instead of booking one long block. Attention drops sharply after half an hour of explaining something you do on autopilot.
What do you do when the expert says "it depends"?
Ask "depends on what?" and wait. That answer is a decision point that has never been written down, and it usually comes back as a short list of conditions you can turn into branches in the document. If the list is long, cover the two or three most common cases and name who to escalate the rest to.
Why do experts struggle to write down what they do every day?
Expertise compresses knowledge, so the steps that matter most stop feeling worth mentioning. Writing it up also asks them to recall a process they run on autopilot, judge what a stranger needs, and write clearly, all at once. Most people are good at one of those three and stall on the other two.
What questions should you ask when documenting someone else's process?
Start with what triggers the process and how they know it is finished, then take one stage at a time and ask what they open, what they click, and what they see when it worked. Follow with the reasons: what has to be true before they start, where they have to choose between two options, what goes wrong most often, and who owns the fix. Finish by reading the whole thing back and asking what you got wrong.
How do you document a process when the expert has no time?
Change the ask so it costs them less. Twenty minutes of talking while you take notes is far less work than writing a document, and correcting your draft is far less work than producing one. Say exactly what you will send back and when, so their only obligation is to point out mistakes.
What is the difference between observing a process and documenting it?
Observation captures actions and screens with high fidelity, and it cannot capture reasons. Watching shows you what was clicked but not what was checked first, why one path was chosen over another, or what happens when something fails. Documenting means combining the observed actions with the reasons you get by asking.
How do you verify an SOP you wrote for someone else's job?
Read it back to the expert out loud before you publish, then have a genuine beginner follow it while you watch in silence. Every pause is a gap. Finish with a short written sign-off from the person who performs the process so the document has a named reviewer.
How do you document a process before the person who does it leaves?
Work in short interview sessions rather than waiting for a long handover document that will never arrive. Prioritize the processes only they perform, capture the trigger, stages, decisions and exceptions for each, and write up and read back each one before moving to the next. A rough document you verified with them beats a polished one written after they are gone.
