SOP extraction from interviews

The workflow goes: interview the senior operator about how they actually do the work, transcribe the conversation, run it through an AI pipeline that pulls out steps, inputs, outputs, and decision points, then do a gap-finding pass that flags everything the operator forgot to mention. The operator narrates. The pipeline writes.

The reason this matters: every growing company has the operator who keeps the books closing on time, the office manager who knows every vendor and lease, the customer-success lead who handles every executive escalation. The standard ask is “write up your SOPs.” It’s also the standard failure mode. Senior operators are bad at writing SOPs about their own work because the work is too obvious to them — they leave out the steps they consider too basic to mention, and those are usually the ones that trip a new hire.

This piece walks through the pipeline end to end: the interview structure that captures real workflow, the extraction that produces a follow-able document, and the gap-finding pass that catches the institutional knowledge the operator forgot to mention.

Use this if you have senior operators with tribal-knowledge workflows, the workflows are operationally important (closing the books, handling escalations, managing vendors), and the documentation gap is real. Common fits: companies past 30 employees, ops teams where founders are still doing operator work, services businesses where the principal’s workflow is the product, any team facing a senior-operator transition.

Don’t use this if the workflow is already well-documented (use what exists), the operator is willing and able to write the SOP themselves (let them — the result is better), or the workflow involves heavy software / UI interaction (use a screen-recording tool like Tango or Scribe instead, which captures the UI steps automatically). For workflow types where the operational knowledge is mostly in software (a specific reporting workflow in Salesforce), screen capture beats interview extraction.

• A senior operator willing to be interviewed — usually 30–60 minutes per workflow.
• A transcription tool — Otter, Fireflies, or your meeting platform’s native transcription. Quality of transcript matters; live transcripts with poor accuracy cost more time than they save.
• A model API key with reasonable context window — Claude, GPT, or Gemini. Interviews can run to 10–30k tokens; all three handle this comfortably.
• A draft SOP structure for each workflow type. “Customer escalation procedure” has a different shape than “monthly close” has a different shape than “vendor onboarding.” Pre-built skeletons accelerate extraction.
• A reviewer who will validate the extracted SOP — usually the operator themselves, plus one person from the team that will execute the procedure.

1. Pre-write the interview structure — open-ended, scenario-driven, not yes/no

   The interview is the input quality lever. Structure it around three prompt types: (a) walk-through (“walk me through the last time you did X — what did you do first?”), (b) edge cases (“what happens when Y goes wrong? When did you last have to handle that?”), and (c) decision points (“when you see Z, how do you decide between option A and option B?”). Avoid yes/no questions — they produce checklists, not workflows. Avoid hypotheticals — operators describe what they wish they did, not what they actually do.

2. Record and transcribe — high-quality audio matters more than fancy tooling

   Record the conversation with a meeting-recording tool. Good audio matters more than the tool brand. Live transcription tools (Otter, Fireflies) save a step; post-meeting transcription from a clean audio recording is more accurate. For workflows involving specific terminology (medical, legal, financial jargon), pass a glossary to the transcription tool ahead of time or post-process with terminology correction.

3. Extract the workflow with structured output — steps, inputs, outputs, decision points

   Pass the transcript to the LLM with a schema: list of steps in order, each step with a description, required inputs (data, tools, information), expected outputs (deliverable, state change, downstream trigger), and decision branches (when does the operator choose differently). For each step, ask the model to extract the verbatim quote from the transcript that supports it — the audit trail makes the SOP trustworthy and lets reviewers verify against the source.

4. Run the gap-finding pass — what did the operator skip over?

   The most valuable extraction step is finding what’s missing. Pass the extracted SOP back to the LLM with a different prompt: “what gaps exist in this procedure that a brand-new hire would need? What background knowledge is assumed? What systems / tools are referenced without explanation?” The model surfaces the obvious-to-the-operator-but-not-to-anyone-else gaps. Some of these are real (the operator genuinely forgot to mention something); some are signals to ask a follow-up question in a second interview.

5. Draft the SOP — structure for the executor, not the author

   The output document is optimised for someone executing the procedure, not for someone who wrote it. Standard structure: purpose (one sentence), prerequisites (tools, access, prior knowledge), steps (numbered, with inputs and outputs per step), decision branches (visual flowchart for non-linear procedures), edge cases (a few common ones; reference the operator if more arise), success criteria (how do you know the procedure was done correctly). Keep verbatim operator-voice in the steps where it adds clarity; rewrite for clarity where the operator was clearly speaking conversationally.

6. Validate with the operator and a test execution

   Two-stage validation. First, the operator reviews the extracted SOP and corrects misinterpretations — usually 15–30 minutes for a 45-minute interview’s output. Second, someone other than the operator executes the procedure following the SOP. The test execution catches the gaps the operator-review missed: steps that assume context, jargon that needs definition, decision branches that the SOP didn’t capture. Most SOPs need one revision after the first test execution; mature SOPs are stable after that.

The operator’s time investment is small for the institutional-knowledge value created. The transition-time savings is the strategic ROI; the immediate one is just having the SOPs exist at all.

Screen-recording workflow tools (Tango, Scribe, Loom + transcription). Right answer for software-heavy workflows where the operator interacts with specific tools. Tango and Scribe capture click-by-click; the AI generates the step descriptions automatically. For pure-software workflows, this beats interview extraction every time. Complement: use interview extraction for the judgement layer (“when do you choose A vs B?”) and screen capture for the mechanical layer (“click here, then here, then here”).

Pair-write with the operator. A documentation specialist or junior operator sits with the senior operator and writes the SOP collaboratively. Slow, high-quality, builds shared understanding. Works at small scale; doesn’t scale across many SOPs. Useful for the most critical workflows where the highest fidelity is worth the time.

Operator writes the SOP themselves (the default, often the failure). The cheapest path on paper, the most common in practice, the most likely to produce no SOP at all. Senior operators are busy; SOP-writing is low-leverage from their perspective; the work slips. Most teams that have tried this end up at the AI-extraction approach because the SOPs the operator was supposed to write never materialised.

Don’t document — accept the institutional-knowledge risk. Honest answer for some very-small teams. Becomes increasingly indefensible as headcount grows past 20 and the cost of any operator transition becomes meaningful. The AI extraction pipeline lowers the threshold where documentation is worth doing; for many ops workflows, “worth doing” arrives sooner than teams had assumed.

For the underlying meeting-transcription tooling, see Voice transcription for sales calls and customer interviews. For the comparison of transcription services that often handle the interview audio, see Whisper API vs Deepgram vs AssemblyAI. For making the resulting SOPs searchable by the team that needs them, see Internal Q&A bot over company docs. For the onboarding-document pattern that builds on SOP extraction, see Onboarding documentation generation for new hires.