There’s a particular kind of standard operating procedure that everyone has seen. It’s formatted beautifully. It has a revision table and a logo. It describes a process in confident, numbered steps. And the person who actually does the job reads it, laughs quietly and goes back to doing it the way that works.
The problem isn’t the formatting. It’s the source. That SOP was written from the org chart: from a manager’s understanding of how the process is supposed to run. Useful SOPs are written from the hands: from the person who does the work, every week, including the parts nobody thought to mention.
This how-to covers the method: interview the person who does the work, capture the gaps, draft a short SOP, and dry-run it with a second person.
What is an SOP, really?
Strip away the corporate associations and an SOP is simple: a short, shared write-up of how a recurring job actually runs. Short, because nobody follows a forty-page procedure. Shared, because its purpose is to let someone other than the current owner do the job. Actually runs, because a procedure describing an imaginary process is fiction with numbered steps.
Why interview instead of writing it yourself?
Because the person who does a job knows things that never make it into any description of it:
- The real trigger. Not “when an order comes in” but “when the order email arrives and the payment has cleared, which can take a day.”
- The exceptions. What happens when the customer’s name is misspelled, the item is out of stock or the system is down.
- The workarounds. The spreadsheet they keep on the side because the official tool doesn’t do something.
None of this is visible from the outside. All of it determines whether the SOP works.
Who figured out that the hands know best?
Three very different traditions arrived at the same insight.
Diderot’s Encyclopédie. Beginning in 1751, Denis Diderot and his collaborators published an encyclopedia that gave unusual attention to the mechanical arts. Diderot sought out craftsmen to learn how trades were actually practiced, and the work’s famous plates illustrated tools and processes in remarkable detail. Knowledge of how things were made, he believed, deserved the same respect as philosophy.
The Gilbreths’ motion studies. In the early 1900s, Frank and Lillian Gilbreth studied work by watching it closely, including bricklaying, where Frank analyzed the motions involved and redesigned the work to need fewer of them. Their method began with observation of the person doing the job, not with theory about how it should be done.
The Foxfire project. In 1966, students at a high school in Rabun County, Georgia, began interviewing older people in their Appalachian community about traditional skills and crafts, publishing the results in a magazine called Foxfire. The interviews preserved practical knowledge that existed nowhere in writing.
The common thread: the most accurate account of how work is done comes from the people doing it, asked the right questions.
What should the interview cover?
Eight elements, which together make a complete picture of any recurring job:
- Trigger. What starts the job? Be precise about conditions.
- Owner. Who is responsible for it, and who covers when they’re out?
- Inputs. What information, files or materials does the job need?
- Decisions. Where does the person make a judgment call, and what guides it?
- Exceptions. What goes wrong, and what do they do then?
- Permissions. What access, logins or approvals does the job require?
- Outputs. What does the job produce, and where does it go?
- Evidence of done. How does anyone know the job was completed correctly?
The last one is the most often skipped, and arguably the most important. Without it, “done” means “the owner says so.”
How do you run the interview?
A few techniques that make the difference:
- Ask about the last time, not the usual time. “Walk me through the last time you did this” produces specifics. “How do you usually do this?” produces the official version.
- Ask for the exceptions explicitly. “What’s the most annoying thing that goes wrong?” surfaces what step-by-step questions miss.
- Watch if you can. If the job happens during the interview window, observe it. People skip steps they’ve stopped noticing.
- Ask what they’d tell a replacement. “If you were training someone tomorrow, what would you warn them about?”
- Record their words. The owner’s phrasing is usually clearer than a rewrite.
- Don’t fix the process yet. The interview captures what is. Improving it comes later.
What do you do with what you learned?
Separate what you observed from what’s missing. After the interview, list the observations, what you saw and heard, and then list the gaps: elements from the eight that you don’t yet have a clear answer for. “Unclear who covers when the owner is on vacation.” “No defined evidence of done.”
Gaps aren’t failures. They’re the most valuable output of the interview. Each one is either a question for a follow-up or a decision someone needs to make.
What does this look like for an ordinary job?
Take the fictional bookstore example the kit uses: a customer calls to ask the store to hold a book. A manager writing from the org chart might produce three steps: take the request, put the book aside, notify the customer.
An interview with the clerk who handles holds surfaces much more:
| Element | What the interview revealed |
|---|---|
| Trigger | Requests arrive by phone, email and in person, and email ones are easy to miss. |
| Owner | Whoever answers, but the morning clerk reconciles them. |
| Inputs | Title, customer name, a phone number and whether they want a call or a text. |
| Decisions | Whether to order a copy if none is on the shelf. |
| Exceptions | Two customers want the last copy; the customer never picks up. |
| Permissions | Only some staff can place orders with the distributor. |
| Outputs | A labeled book on the hold shelf and a note in the hold log. |
| Evidence of done | The hold log entry, with the date the customer was notified. |
Notice how many of those details matter. The missed-email trigger is the most common source of failure. The two-customers exception needs a rule. The permissions row explains why holds stall when certain staff are off. None of it would appear in the three-step version, and all of it would surface the first time someone new tried to follow it.
How do you write the gaps list well?
Each gap should be a specific, answerable question, with a name next to it: who can answer or decide. “How long do holds last before the book goes back on the shelf? Ask the owner.” Vague gaps, like “clarify holds process,” never get closed. Specific ones usually get closed in a two-minute conversation.
How short should the draft be?
As short as it can be while covering the eight elements. Most good SOPs for a single recurring job fit on one or two pages. A completeness check helps: before calling the draft done, confirm each of the eight elements is present. If one is missing, it goes back to the gaps list.
What happens after the draft?
The dry-run. Give the draft to the owner or, better, a second person, and have them do the job using only the SOP. Every place they hesitate, ask a question or improvise is a place the SOP needs work. A procedure isn’t finished until someone other than its author has followed it successfully.
What mistakes should you avoid?
Six common ones:
- Writing from the org chart instead of interviewing the owner.
- Asking about the usual case instead of the last specific time.
- Skipping exceptions, which is where procedures actually fail.
- Fixing while documenting, which mixes two jobs and confuses both.
- Omitting evidence of done, leaving “finished” undefined.
- Skipping the dry-run, so the first real test happens when the owner is gone.
What’s in the kit?
The Process-to-SOP Interview Kit follows the method from interview to validation. Its workbook has six tabs: Start Here, an Interview Guide built around the eight elements, Observation + Gaps, an SOP Draft with a completeness check, Validation for the dry-run, and a fictional Book Hold example from an ordinary bookstore. A five-page guide covers the SOP definition, the workflow, the example and common mistakes. Markdown templates cover the interview, observation and gaps, the SOP itself, a validation checklist and the example.
It’s built for founders documenting how things actually get done, ops leads and VAs interviewing process owners, and freelancers delivering SOPs to clients.
Quick answers
How long does an interview take?
For a single recurring job, often under an hour. Complex jobs may need a follow-up for the gaps.
What if the owner can’t explain what they do?
Watch them do it. Then ask about what you saw.
Can I use this for my own processes?
Yes. Interview yourself, honestly, then have someone else dry-run the draft.
Go to the source
The best SOPs aren’t written. They’re collected, from the person whose hands know the job, and then tested by someone else’s. That’s what makes them worth following.
Get the Process-to-SOP Interview Kit and run your first interview this week, about the job you’d least like to explain from scratch.
The Process-to-SOP Interview Kit is on Content & SEO Workflows.
Leave a Reply