Turning Tribal Knowledge Into a Real SOP With Grok
Every operations team has at least one process that lives entirely in one person's head. It works, it's been working for years, and nobody has written it down because writing it down never felt urgent enough to bump ahead of everything else on the list, right up until that person is out for two weeks and everyone realizes nobody else knows how the monthly reconciliation actually gets done. If you're getting oriented with Grok generally, the Complete Beginner's Guide to Grok covers the basics this workflow builds on.
The problem with documenting tribal knowledge isn't usually a writing problem. It's that the person who knows the process doesn't know what they know, in the sense that matters for documentation. They can do the task without thinking about the fifteen small decisions embedded in it, but listing those decisions cold, staring at a blank doc, is a completely different skill from executing them. Grok is genuinely good at the specific job of pulling that knowledge out through questions, because it can interview you the way a good process consultant would, instead of asking you to just start typing.
Why an interview beats a blank template
A standard SOP template asks you to fill in "Purpose," "Steps," "Exceptions." That's the right final shape, but getting there by staring at empty fields is where most SOP efforts stall out. The person filling it in either writes something too vague to be useful ("Reconcile the accounts") or gets stuck trying to remember every step in order from memory.
Interviewing works better because it mirrors how the knowledge is actually stored, as a set of responses to specific situations, not as a linear script. "What do you check first?" gets a real answer faster than "describe your process," because the first question matches how you actually think about the task.
What you actually start with
Before any interview, the knowledge exists as something like this: the note the accounts payable lead would type into a phone in two minutes if you asked her how invoices get checked. It is invented for this article, and typical of the real thing.
Raw input: the process as it lives in one person's head
batch report comes out on the 3rd. sort by vendor first, its easier. check each invoice against the PO, if its close its fine, if its way off I dont approve it, ask the account manager. sometimes theres no PO at all, then I ask whoever ordered it. same invoice number twice happens, watch for that. if the report doesnt generate I pull it straight from AP by hand. approved ones go in the payment queue. Im the one who does all this.
Every sentence here is true and none of it is followable. "Close" and "way off" hide the $50 line. "I ask whoever ordered it" hides who that is and how long to wait. "Watch for that" hides what to do when it happens. The interview exists to convert exactly those phrases.
Building the interview as a reusable Skill
Since you'll likely need to document more than one process over time, build this as a Skill once rather than re-explaining the interview approach for every SOP. Call it something like sop-interviewer.
Create a Skill called sop-interviewer with these instructions: When I say I want to document a process as an SOP, interview me one question at a time instead of asking me to describe the whole process at once. Start by asking what triggers the process, what event or timing kicks it off. Then ask what the first concrete action is. After each answer, ask what happens next, and specifically ask about any point where I'd make a judgment call or check something before proceeding, since those are the details people skip when writing SOPs from memory. Ask about exceptions and what normally goes wrong, separately from the main flow, after the main flow is fully mapped out. Once the interview is done, write the SOP in this structure: Purpose (one sentence), Trigger, Steps (numbered, one action per step), Decision Points (called out separately, with the condition and what to do for each outcome), Common Exceptions, and Owner. Keep step language concrete and imperative, like "Open the reconciliation sheet," not passive or vague.
”Running it against a real process
Here's how the interview actually plays out, using a monthly vendor invoice reconciliation as the example, a genuinely common piece of tribal knowledge that tends to live with whoever's been doing accounts payable the longest.
- 1
Let Grok ask what triggers the process
Grok, following the Skill, opens with something like "What triggers this process? Is it a calendar date, an email, a system alert?" You answer: the invoice batch report auto-generates on the 3rd of each month.
- 2
Walk through the first few actions
Next question: "What's the first thing you actually do once that report lands?" You describe opening the report, then sorting by vendor. Grok keeps asking "and then?" until you hit a genuine decision point.
- 3
Surface the judgment calls specifically
This is where the real value shows up. You mention that if an invoice total is off by more than $50 from the PO, you hold it instead of approving it. That's exactly the kind of detail that gets left out of a from-scratch SOP, because to you it's not a "step," it's just a habit. Grok, prompted to ask about judgment calls specifically, catches it and asks what happens to a held invoice next.
- 4
Cover exceptions after the main flow is mapped
Once the standard path is fully documented, Grok asks what commonly goes wrong: a vendor with no PO on file, a duplicate invoice number, a report that fails to generate. Handling this after the main flow keeps the primary SOP readable, with exceptions in their own section instead of interrupting the main steps.
- 5
Review the generated SOP against how you'd actually explain it to a new hire
The real test isn't whether it reads well, it's whether someone who's never touched this process could follow it without you standing next to them. Read it that way and flag anything that still assumes knowledge you didn't actually state.
What the finished SOP looks like
After the interview, Grok writes the document in the Skill's structure. Here is a representative excerpt of the steps and decision points, with owners and failure modes broken out. The company, roles, and figures are invented.
Grok
Excerpt of the finished SOP as Grok might draft it, illustrated, not a real screenshot
Monthly Vendor Invoice Reconciliation
Purpose: Ensure vendor invoices match purchase orders before payment approval each month. Trigger: invoice batch report auto-generates on the 3rd. Owner: Accounts payable lead.
| Step | Action | Owner | What could go wrong |
|---|---|---|---|
| Step 1 | Open the batch report and sort by vendor | AP analyst | Report has not generated, see Exceptions |
| Step 2 | Compare each invoice total to its matching PO | AP analyst | The wrong PO is matched because two POs share a vendor |
| Step 3 | If within $50 of the PO, approve and log in the payment queue | AP analyst | Approved invoice never reaches the queue because the log step is skipped |
| Step 4 | If off by more than $50, hold and contact the vendor's account manager | AP lead | Held invoice is forgotten and the vendor chases payment |
| Step 5 | If no PO is on file, hold and ask the requesting department | AP lead | Nobody knows which department to ask |
Common Exceptions: duplicate invoice number in one batch, and report generation failure (pull the raw data from the AP system by hand).
- 1
Purpose, trigger, owner: The header a new hire reads first. The owner line answers 'who do I ask' before anyone has to.
- 2
The $50 rule as an explicit step: In the raw notes this was 'if its close its fine'. The interview forced a number.
- 3
Hold, then contact: The raw notes said 'I dont approve it'. The finished step says who to contact and what happens to the held invoice.
- 4
Exceptions kept separate: Duplicates and a failed report each get their own line, out of the way of the main flow.
Look at the "What could go wrong" column. It did not exist in the raw notes as a separate idea, it was scattered through phrases like "watch for that". Pulling failures into their own column, next to a named owner, is what turns a memory dump into a document a stranger can follow. Some of those entries, like the shared-PO mix-up, came from Grok asking "what commonly goes wrong at this step?" and may need correcting by the person who actually does the job.
Why the interview format does the heavy lifting
Grok is not smarter about accounts payable than the person being interviewed. It is doing something different: asking one question at a time, refusing to accept "close" as an answer, and treating every judgment call as a step to be named. Three habits in the Skill produce most of the value.
| Habit in the Skill | What it extracts | What you would get without it |
|---|---|---|
| One question at a time | Real answers, in the order the person thinks | A single long ramble, missing the middle |
| Ask about judgment calls explicitly | The $50 threshold, the hold rule | "Approve if it looks right" |
| Exceptions after the main flow | A clean primary path plus a separate list | Edge cases scattered through every step |
Where a person still has to check the work
Grok can only document what you tell it. If a step you glossed over in the interview was actually load-bearing, the finished SOP will confidently omit it, and it'll read as complete either way. Have someone unfamiliar with the process actually try to follow the written SOP before treating it as final, not just you re-reading your own answers. That's the step that catches the gap between "I described this reasonably" and "someone else could actually execute this."
Common mistake
Publishing the SOP straight from the interview without a trial run. The interview format makes the document feel thorough because it was genuinely effortful to produce, but effort isn't the same as completeness. A step you found obvious enough to skip mentioning is exactly the step a new hire will get stuck on.
Once you've documented one process this way, the sop-interviewer Skill is ready for the next one without any setup, which is the actual payoff. The first SOP takes the same effort it always would. Every one after that is faster, because the interview structure and the output format are already handled.