Methods and frameworks

The formulas that make documentation actually work

Each formula here is a structured approach to a specific documentation challenge. Not theory. Actual methods with clear starting points and defined outputs.

Formula 01

The Fifteen-Minute Capture Method

Most documentation projects fail at the start because people approach them as writing projects. The moment you open a blank document and try to write a process from memory, you're fighting against how memory actually works. You'll remember the main steps and forget the small decisions that matter most.

The fifteen-minute capture method flips this. Instead of writing, you do the task while narrating. The output is raw, but it captures what actually happens rather than what you think happens.

1

Start a screen or voice recording

Open whatever tool you use for the task and start recording. Don't prepare anything. Just begin the task as you normally would and speak out loud as you go.

2

Narrate decisions, not just actions

The most valuable part of any SOP is the decision logic. Say "I'm choosing this because..." whenever you make a judgment call. That's the part that can't be inferred from a list of steps.

3

Stop and flag edge cases as they appear

When you hit a step where you'd normally think "it depends," say that out loud and explain what it depends on. Don't skip these moments. They're exactly what a new person needs to hear.

4

Spend two minutes on cleanup

After the recording, write a five-line summary: what this process is for, when to use it, who owns it, where the output goes, and where the recording lives. That's your SOP header.

The recording itself can serve as the SOP for visual or software-based tasks. You don't always need to transcribe it. The header document plus the recording is often enough.

Formula 02

Video vs. Written: A Decision Framework

The format you choose for a process document matters more than most people realize. A written SOP for a task that involves navigating complex software is often harder to follow than a five-minute screen recording. But a video for a simple checklist creates unnecessary friction.

Here's a straightforward way to decide before you start creating anything.

Choose video when...
Choose written when...
The task involves navigating software with many screens
The task is a short checklist with clear pass/fail steps
Visual context is essential to understanding the step
The reader needs to reference specific items while working
The process involves judgment calls that are hard to write out
The process rarely changes and is used frequently
Writing the steps would take longer than recording them
Multiple people will need to search for specific steps within it

A hybrid approach often works well: a short written summary with a linked video for the complex parts. The written doc provides searchability. The video provides clarity. Use both where the task warrants it.

Formula 03

The Day-One Findability System

Here's a test for any SOP library: give a new person a task and ask them to find the relevant document without help. If they can't do it in ninety seconds, your organization system is failing them regardless of how good the documents are.

Most small teams organize SOPs the way they think about their business, which is by department or function. But a new hire doesn't know your departments yet. They know the task they've been asked to do.

1

Organize by trigger, not by function

Instead of "Sales" and "Operations" folders, try "When a new client signs" and "When we receive an invoice" folders. The trigger is what the person knows when they need the document.

2

Build a single entry-point index

One document. Every SOP linked from it. Organized in plain language. This is the first thing a new hire reads and the only thing they need to bookmark. Everything else flows from here.

3

Name documents for search, not for filing

A document called "Client Onboarding Process" is harder to find than one called "How to set up a new client account in [your software]." Name for the search term someone will use when they need it urgently.

Formula 04

The Lightweight Maintenance System

Documentation rot is real. You create a great SOP in January. In March, the software changes. By June, the document is actively misleading people because it describes a process that no longer exists. This happens to every team that doesn't have a maintenance system.

The fix is not a quarterly review process. That never gets done. The fix is building maintenance into the moment things change.

1

Add a "last verified" date to every document

Not a "last updated" date. A "last verified" date. Someone checks it against current reality and confirms it's still accurate. This creates accountability and a searchable list of stale documents.

2

Assign process ownership

Every SOP has one owner. When the process changes, the owner updates the doc. This is a two-minute task when done immediately and a two-hour archaeology project when done six months later.

3

Flag outdated documents visibly

When someone finds a step that no longer matches reality, they mark the document as "Needs Review" at the top. This is faster than fixing it immediately and ensures nothing quietly misleads the next person.

4

Review flagged documents weekly, not monthly

A weekly ten-minute pass through flagged documents keeps the library clean without requiring a major time investment. Monthly reviews create backlogs. Weekly reviews stay manageable.

Apply this to your situation

See how these formulas apply to local businesses specifically

Physical location businesses have documentation needs that generic SOP advice doesn't address. The local business page covers these directly.