You find out your SOPs are rotten on the day you're not there. Someone covers your shift, opens the doc you wrote eighteen months ago, and discovers step three references a tool you stopped using last summer. Or a new hire reads the customer-onboarding SOP and asks the question that makes your stomach drop: "is this still how we do it?"
Most operators don't have an SOP problem. They have an SOP-maintenance problem. The first version gets written in a burst of energy — usually right after something went wrong. Then the process changes, the doc doesn't, and a year later the doc is historical artifact, not instructions.
This post is about how to write SOPs that survive contact with reality. Not in a dedicated wiki tool that becomes its own chore. In a notes app where the AI can read every SOP you have, notice when one contradicts another, and help you keep the shelf current.
Why SOPs rot — and why a wiki tool doesn't fix it
The honest reason SOPs go stale is that updating them is invisible work. Nobody notices when the doc is current. Everybody notices when it's wrong. So the doc gets written once, used a few times, and then quietly drifts behind whatever the team is actually doing.
Wiki tools were supposed to fix this. In practice they added a second problem on top of the first: now you have to remember to open the wiki, find the right page, edit it in a structured editor, and hope the formatting survives. The friction of opening the wiki at all is usually enough to push the update to "later," which means never.
The shape that works better is simpler. Your SOPs live as plain markdown pages in the same notes app where you already write everything else — meeting notes, project plans, the Tuesday to-do list. Updating one is the same gesture as editing any other note. Because the format is plain text, the AI agent can read across all of them at once. The same shape covers adjacent operational work — see AI Notes for Customer Onboarding Documentation and Building an Employee Handbook From the Notes You Already Have.
SOPs as markdown pages — versionable, pasteable, portable
In Docapybara, every SOP is just a markdown page. That sounds boring. The boring part is the point.
Plain markdown means you can paste the SOP into an email when a contractor needs it, drop it into a Slack message when someone asks how to handle a refund, or hand the file to a new vendor. There's no proprietary block format to flatten or export. What you see is what you can send.
Markdown also means version history is legible. When the page changes, the diff reads like English — "you added a sentence about the new payment processor, removed the old phone number, swapped the screenshot." You can scan a year of edits in a few minutes and tell the story of how the process evolved.
Because markdown is the same format the agent reads natively, asking it to summarize a 4,000-word SOP into a one-page quick reference takes about ten seconds. No conversion step, no "open this in another app first."
The agent reads every SOP in your vault — and knows when two of them disagree
Here's where it stops being a notes app and starts being something more useful. Docapybara's agent has 27 tools and a habit of reading across your entire vault when you ask it a question. That changes what you can ask.
A few real examples:
- "What's our process for onboarding a new commercial customer?" — the agent finds the relevant SOP, summarizes it, and tells you which page it pulled from.
- "I just changed how we handle deposit refunds. Which SOPs reference deposit handling, and where do they need updating?" — the agent surfaces every page that mentions the old process so you can see in one shot what needs a pass.
- "My customer-onboarding SOP says we email the welcome packet on day one. My client-success SOP says day three. Which is right?" — the agent reports the contradiction. You decide which one to fix.
That third one is the part that pays for the rest. Wiki tools assume each page is self-contained. Real SOPs overlap — onboarding touches billing touches support touches refunds. When the agent can read them all at once, it spots the inconsistencies humans miss because nobody re-reads twelve docs in one sitting. That cross-document agentic behaviour is the differentiator described in Claude Code for Documents.
Turning a walkthrough recording into a draft SOP
The fastest way to write an SOP for a process you do every week is to not write it. Record yourself doing it.
Open a new page, hit record on the audio capture, and walk through the process out loud the same way you'd train a new hire. "First I check the morning report. If there are any open tickets from overnight, I handle those before opening the till. The till key is in the second drawer. The opening float is two hundred dollars in the following denominations…"
When you stop the recording, Docapybara transcribes it with speaker labels. You ask the agent: "Turn this transcript into a draft SOP with numbered steps, called out exceptions, and a checklist at the bottom." What comes back is a structured first draft you can edit, instead of writing from a blank page.
This matters more for tacit knowledge — the stuff you do without thinking about it. Writing those steps cold is hard because they live in your hands, not your head. Talking through them while you do them surfaces the details that matter, including the ones you'd forget in a written draft.
PDFs of old SOPs can come along too
Most operators have a folder somewhere — Drive, Dropbox, an old shared drive — full of SOPs in PDF form that someone made years ago. They're useful as historical reference and frustrating as living documents because PDFs aren't really editable in any meaningful way.
Drop those PDFs into Docapybara and the conversion pipeline turns each one into searchable markdown under the hood. The agent can now read them, search them, and incorporate them into answers the same way it reads your hand-written pages. When you ask "what does our existing closing-procedure PDF say about cash drops?", you get the relevant excerpt back as text, with the source PDF one click away.
The next step is usually to ask the agent to draft a markdown rewrite of the PDF, edit it in place, and retire the PDF to an archive folder. The institutional knowledge stays accessible; the format stops being a bottleneck.
A live database of SOPs, embedded in the SOP index page
This is the part that usually surprises people. Docapybara lets you embed a live database directly inside any markdown page using a :::database::: directive. It's not a separate tab you open, not a linked-out Notion-style "open this database" button. The database lives in the same doc as your prose.
For SOP maintenance, that means your SOP index page can be both a written index and a live tracker:
- One column for SOP title (linked to the page)
- One for the responsible owner
- One for last-reviewed date
- One for next-review-due date
- One for status (Current, Needs Review, Out of Date, Retired)
You sort by next-review-due and you know what to look at this week. You filter by owner and you know who to nudge. The columns are right there, alongside the written context that explains why you review SOPs quarterly and what a "current" status actually means.
Six column types are supported, which is enough for almost any SOP-tracking shape we've seen. Asking the agent to "find every SOP that hasn't been reviewed in the last 90 days and add a Needs Review row to my SOP queue" is a one-sentence request.
Nesting SOPs the way your business is actually shaped
Operators usually don't have a flat list of twelve SOPs. They have categories that nest — Customer Onboarding has a sub-process for commercial vs. residential, each of which has steps for credit checks, deposit handling, equipment delivery, and so on.
Docapybara doesn't put a depth cap on page nesting. You can build the tree the way the business actually works — Customer Operations → Onboarding → Commercial → Equipment Delivery → Step 4: Inspection — without flattening or compromise. Each level is a real markdown page that can hold its own content, not a folder placeholder.
That structure also helps the agent. When you ask a scoped question — "summarize all the equipment-delivery steps across our commercial onboarding tree" — the agent walks the relevant subtree instead of scanning the whole vault. Faster answer, more relevant context, no manual hand-holding about which folder to look in. The same nesting also works for the long-tail operational record — Build a Company Wiki from Casual Notes covers that pattern.
A maintenance routine that doesn't take long
The whole point of all of this is that maintenance becomes cheap enough that you'll actually do it. The routine that works for most operators we've talked to:
- Weekly (5 minutes): open the SOP index page. Look at the database. Are any rows red? If a process changed this week, mark the SOP as Needs Review.
- Monthly (15 minutes): ask the agent "have any of my recent meeting notes contradicted anything in my SOPs?" — it looks across notes from the last 30 days and surfaces the mismatches. Fix the obvious ones in place.
- Quarterly (30 minutes): walk the Needs Review pile. For each one, either confirm it's still right (update the last-reviewed date) or rewrite the relevant section. Ask the agent to draft the rewrite based on what's true now.
That's it. No wiki tool to maintain on top of the SOPs. No structured editor to fight. The agent does the heavy lifting of cross-referencing; you do the small, valuable work of deciding what's actually true.
The SOPs that survive aren't the ones in the prettiest tool. They're the ones in the tool with the least friction between "I noticed something changed" and "the doc reflects it." A markdown notes app with a built-in agent gets that friction close to zero.
Try Docapybara free — your SOPs live in one searchable vault, not in someone's head. Bring your PDFs, your last meeting recording, and your messiest folder of half-written process notes.