Every company has a version of the same conversation. Someone asks how a process works, and the answer is a name. "Ask Maria — she handles the returns." Maria has done it a thousand times and does it well. Nothing is written down, because nothing needed to be written down until the day Maria was on vacation, or got promoted, or left.
The usual fix is a documentation push. Someone records a screen-share, someone else writes a wiki page, and a folder fills up with material nobody reads. Then a year later the company buys AI tools and discovers those same documents are useless to a model, too. That's not a coincidence. Human readers and AI assistants fail on the same documentation for the same reasons — and if you fix it once, you fix it for both.
Why your current documentation doesn't work for either reader
Most SOPs are written by the person who already knows the answer. That person can't help skipping steps, because the skipped steps feel obvious. A new hire hits the gap and guesses. An AI assistant hits the gap and invents.
The common failure patterns look like this:
- Screenshots and video with no text. A human can squint at a screen recording. A model can't retrieve from it, and neither can your search bar.
- Steps without decision rules. "Review the order and approve if it looks right" tells nobody what "right" means.
- Undefined terms. "Route it to ops" assumes the reader knows which queue, which person, and what happens next.
- No exceptions. Real processes are mostly exceptions. If the document only covers the happy path, it will be wrong most of the time it's opened.
- No owner and no date. Documentation without a maintainer decays quietly, and stale instructions are worse than none.
The shape of an SOP both readers can use
You don't need a documentation methodology. You need a consistent structure, applied the same way every time, so a person can scan it and a retrieval system can chunk it sensibly.
Start with the trigger: what event starts this process? An email arrives, a record hits a status, a date passes. Then the inputs: what information and access do you need before you begin, and where does each piece live? Name the actual system and the actual field, not "the portal."
Then the steps, written as instructions someone could follow without you in the room. Where a step involves judgment, write the judgment as a rule: if the amount is under this threshold, do X; if the customer is in this category, do Y; if neither applies, escalate to this role. Vague verbs are where both humans and models go off the rails. Replace "review," "check," and "handle" with what you'd actually do.
Finish with exceptions and a definition of done. The exceptions section is the most valuable part of the document and the one people skip. What are the three or four situations that break this process, and what's the play for each? And how does someone know they're finished — which record shows what state, who gets notified, what's the paper trail?
Where it lives matters as much as what it says
A perfect SOP in someone's personal drive is tribal knowledge with extra steps. Documentation needs to sit somewhere with structure: a single source per process, plain text or markdown, one owner, a last-reviewed date, and a link from the place the work actually happens. If the process runs in your ERP, the SOP should be reachable from the ERP.
This is also what determines whether AI can help. When people ask why their AI assistant gives confident wrong answers about internal processes, the cause is usually upstream — the source material is thin, contradictory, or spread across four tools with three versions of the truth. A model retrieving from clean, structured, owned documents behaves very differently than one guessing from a folder of screenshots. Your data foundation isn't just databases. It's your written knowledge.
Where to start, and how to test it
Don't try to document everything. Pick processes by three filters: how often they run, how much damage a mistake causes, and how many people they pass between. High frequency plus high handoff count is where undocumented knowledge costs you the most. Five processes done properly beats fifty done as an afternoon exercise.
Then run the two-reader test. Hand the document to someone who has never done the task and watch where they stop and ask a question — that's a missing decision rule. Then give the same document to an AI assistant and ask it to walk through a real scenario, including a messy one. Where it hedges or guesses, your document has a hole. Both readers are pointing at the same defect.
Done consistently, this is how a business starts running on systems instead of memory — and how AI stops being a demo and starts being leverage. If you're staring at a business that only Maria fully understands, that's a solvable problem. We'd be glad to talk through where to start.