Turning Tribal Knowledge Into a Real SOP With Copilot
Every small business has a process that lives entirely in one person's head. Denise has handled every damaged-shipment claim at a specialty coffee roaster for six years, and she's good at it, fast, consistent, never loses a supplier relationship over a dispute. Nobody has ever written down how she actually does it, because she's never had to explain it to anyone. The problem shows up the day Denise takes a two-week vacation and a $4,000 shipment arrives with half the bags crushed, and whoever's covering for her has no idea whether to file a claim with the carrier, the supplier, or both. If you're new to Copilot, the Complete Beginner's Guide to Copilot covers the basics this walkthrough builds on.
The hard part of writing a SOP for a process like this was never the writing. It's that the person who knows the process usually can't see what's implicit in it anymore. Denise doesn't consciously think "step one, check whether the packaging was visibly damaged before opening it," she just does it, because six years of experience turned it into instinct. Getting that instinct back out into a document a new hire can follow requires being interviewed, not asked to write a summary from memory.
Why "just write down the process" doesn't work
Ask Denise to write her own SOP and she'll produce something like "receive shipment, check for damage, file a claim if needed, notify the supplier." Every word of that is true and none of it is usable. It skips every judgment call that actually makes her good at this job: how she decides whether damage is bad enough to warrant a claim versus something to just note and move on, what she says differently to a supplier she's worked with for years versus a new one, what she does when the carrier and supplier each blame the other.
Copilot in Word is genuinely useful here for a specific reason: it can ask the follow-up questions Denise wouldn't think to answer unprompted, the way a good interviewer would, instead of accepting the first flat answer and moving on.
- 1
Start with the flat version, on purpose
Have the process owner describe the process the way they naturally would, in a few sentences. This isn't the SOP, it's the raw material for the interview that produces the SOP.
- 2
Ask Copilot to find the missing decisions
Feed in the flat description and ask specifically for the judgment calls it implies but doesn't explain. This is the step that surfaces what six years of instinct actually contains.
- 3
Answer each question directly, in the process owner's own words
The value here isn't Copilot's phrasing, it's Denise's actual answers. Resist the urge to let Copilot guess at an answer to save time.
- 4
Build the structured document from the full interview
Only once the judgment calls are answered does the SOP get its final numbered-steps structure, so the document reflects decisions that were actually made, not decisions Copilot inferred.
- 5
Have someone unfamiliar with the process test it
A SOP that makes sense to the person who wrote it is not proof it works. Handing it to someone who's never done this job and watching where they get stuck is the only real test.
The interview, in practice
Denise's flat starting description:
I handle damaged shipment claims when coffee arrives from our green coffee suppliers with bags that are torn, wet, or crushed. Usually I check the shipment, take photos if there's damage, and then either file a claim with the shipping carrier or contact the supplier directly, depending on the situation. I want to turn this into a SOP someone else could follow if I'm out. Before writing anything, ask me the questions you'd need answered to actually document this well, the decisions I'm making that I didn't explain above.
”A useful response here surfaces exactly the gaps a flat description leaves open: how she decides whether damage warrants a formal claim versus a note-and-monitor response, how she decides whether the carrier or the supplier is responsible when the packaging looks fine but the product inside is damaged, what the actual claim filing process looks like step by step, how much time she gives a supplier to respond before escalating, and what she does differently for a long-standing supplier versus a new one.
Tip
If Copilot's first batch of questions still feels generic, ask again with a nudge: "these are still fairly generic, ask me about the specific judgment calls that come up in this exact process, like how I decide who's at fault when it's ambiguous." A second pass usually surfaces sharper questions once it has the first round of answers to work from.
Denise's answer to just the fault-determination question, which turned out to be the most important judgment call in the whole process:
On deciding who's at fault: if the outer packaging is visibly torn, crushed, or wet, it's almost always the carrier's fault and I file a claim with them directly, using the shipment's tracking number and photos taken before I open anything else in the shipment. If the outer packaging looks completely fine but bags inside are damaged, that's usually a supplier packing issue, so I contact the supplier directly instead, not the carrier. If I genuinely can't tell, I default to contacting the supplier first, since they're the ongoing relationship and can usually tell me which carrier they used and whether other customers have reported the same issue recently.
”That answer alone turns one bullet point, "file a claim if needed", into an entire decision procedure a new hire could actually follow, including the fallback rule for the ambiguous case, which is exactly the situation that would otherwise land back on Denise's desk while she's on vacation.
Don't let Copilot fill in an answer you skipped
If a question feels tedious to answer, there's a temptation to say "just use your best judgment" and move on. Resist it. Copilot's best judgment on a question like this is a generic best practice, not Denise's six years of actually knowing which suppliers respond fast and which ones need an escalation email by day three. A SOP is only as good as the real judgment calls it captures, and a generic filler answer defeats the entire point of writing it.
Building the final document
Once every judgment call has a real answer, ask for the structured version:
Now build the full SOP document from everything above: a numbered step-by-step process a new hire could follow without me in the room, including the fault-determination logic, the claim filing steps, the escalation timeline, and a short section at the end covering exceptions, what to do if none of the standard cases fit. Write it for someone who has never done this job before, not someone who already understands shipping terminology.
”Note
Agent mode in Word can build this directly as a formatted document with real numbered steps and section headings, rather than a wall of text you have to reformat yourself.
What the finished document actually looks like
It's one thing to say the document gets "a numbered step-by-step process." Here's a representative excerpt of what that section actually contains, built from Denise's real answer on fault determination above.
Word
Excerpt of the finished SOP, illustrated, not a real screenshot
Damaged Shipment Claims, Step 4: Determine Fault Before Filing
| Step | Action | Responsible Party | What Could Go Wrong |
|---|---|---|---|
| 4a | Inspect the outer packaging before opening the shipment further, and photograph any tears, crushing, or moisture | Warehouse receiver | Shipment gets opened before photos are taken, losing the evidence a carrier claim depends on |
| 4b | If the outer packaging is visibly damaged, file the claim with the carrier directly, using the tracking number and the photos from Step 4a | Claims coordinator | Claim gets filed with the supplier by default, delaying resolution and straining a relationship that wasn't at fault |
| 4c | If the outer packaging looks intact but bags inside are damaged, contact the supplier instead of the carrier | Claims coordinator | Carrier is blamed for a packing issue that was never theirs to fix |
| 4d | If fault genuinely can't be determined from the packaging alone, default to contacting the supplier first, since they can identify the carrier used and whether other customers reported the same issue | Claims coordinator | No default rule gets applied, and the claim stalls while everyone waits to find out whose responsibility it is |
Every cell in that table traces back to something Denise said out loud during the interview, not something Copilot inferred to fill a gap. The "what could go wrong" column in particular didn't exist in her original flat description at all. It came from asking, separately, what happens when someone gets Step 4 wrong, the same way the escalation timeline and the exceptions section came from asking what happens outside the normal case.
Why this actually survives Denise going on vacation
A wiki page that says "file a claim with the carrier or supplier depending on the situation" is not resistant to tribal knowledge loss, even though it's technically written down. It hands the reader the same ambiguity Denise resolves silently, without giving them any of the six years of pattern-matching she uses to resolve it. The knowledge that was actually load-bearing, the judgment call, never made it onto the page.
The structure above resists that failure for a specific, mechanical reason: it forces the ambiguous case, "I genuinely can't tell," to become its own numbered row with its own named default (contact the supplier first) instead of being silently absorbed into whichever case the writer happened to think of first. A new hire covering for Denise doesn't need her instinct if the document already contains the fallback rule her instinct would have produced. And the "what could go wrong" column does something a plain instruction never does: it tells the reader what failure looks like before they cause it, which is exactly the kind of thing Denise would only think to mention if someone asked her directly, since she stopped making that mistake years ago and no longer thinks about it as a risk at all.
That's the actual mechanism. Tribal knowledge isn't lost because nobody writes a document, most operations teams have some version of a process page. It's lost because the document that gets written captures the steps and skips the decisions, and the decisions are precisely what the six years of experience were for. A document built from an interview that explicitly hunts for those decisions, and gives each one a named owner and a named failure mode, is a different kind of artifact than a document written from memory in one sitting. It's the difference between a page that describes the job and a page that could actually replace the person doing it for two weeks.
The test that actually matters
A finished-looking SOP is not the same as a working one. Before treating this as done, hand the document to someone who has genuinely never handled a damaged shipment claim, ideally without Denise in the room to answer questions, and watch where they hesitate. Every hesitation point is either a missing step or an assumption the document made that isn't actually obvious to someone new. That feedback loop, not a second AI-assisted editing pass, is what turns a plausible-looking document into one that survives Denise actually being on vacation.
Start with the flat, natural description as raw material, not the SOP itself
Ask Copilot to surface the judgment calls the flat version skips
Answer every question in the process owner's real words, don't let Copilot guess
Push for a second round of questions if the first round feels generic
Include an exceptions section for cases the standard steps don't cover
Test the finished document on someone who has never done the job
Official sources
Checked on September 21, 2026. Features, plans and names change often, so the vendor's own pages are the final word.