Vol 1 · Issue 86 · Wednesday, August 5, 2026

A client of mine spent an entire weekend last February building out an operations manual.

Sixty something pages. Nested pages inside nested pages. Screenshots. A table of contents with links that actually worked. He was proud of it, and honestly he should have been, because it was a genuinely impressive document.

He rolled it out on a Monday. Told the team it was the source of truth. Sent the link.

Six weeks later I asked him how it was going. He pulled up the analytics on it.

Eleven page views. Total. Across five people. And four of those were him.

Meanwhile he was still answering the exact same questions he had been answering in January.

This is the most common failure in the entire small business operations world, and it is not a discipline problem. His team was not lazy. The document was just built wrong, in a very specific and very predictable way.

It gets written for completeness instead of for use.

When you sit down to document a process, your brain goes into encyclopedia mode. You want to capture everything. The edge cases, the history, the reason you do it this way instead of that way, the four exceptions, the vendor who is difficult on Fridays.

That is a reference document. Reference documents are for people who already know the process and need to look something up.

But the person opening your doc is not looking things up. They are standing at the start of a task they do not know how to do, and they need to get through it in the next twenty minutes without bothering you.

Those are opposite needs. And when you hand somebody a sixty page reference document at the moment they need a twelve step instruction, they do the rational thing. They close it and they text you.

There is a second failure baked into the same problem. Documentation written by the expert is always missing the hard parts. Not because you are careless. Because after the four hundredth time you do something, whole chunks of it become invisible to you.

You write "pull the client file and update the status." You do not write which of the three places the client file might be, what to do when the status field is greyed out, or that Marcus needs to be copied but only on the commercial accounts. Those are not steps to you anymore. They are reflexes.

So the doc is simultaneously too long and missing the only three things the reader actually needed.

Here is the standard I hold every process doc to, and it has never once let me down.

Could a competent stranger complete this task correctly using only this page?

Not a stranger who knows your industry. Not your best employee. A competent adult who has never seen your business. If the answer is no, the doc is not done. If the doc is nine pages long, the answer is also no, because they will not read nine pages.

One page. Five sections. That is the whole format.

That is it. If a process genuinely cannot fit on one page, it is two processes that got glued together, and you should split it.

Here is why most of these never get written. Writing them is miserable and slow, and you are busy, so it lands on the someday list and dies there.

So do not write it.

Next time you do the task, hit record and narrate it out loud like you are training somebody standing behind you. Just do the work and talk. "Okay, I am opening the intake form, and heads up, if this field is greyed out it means the deposit has not cleared yet, so you would go check Stripe first."

You just captured the guardrails. Out loud, in context, in real time, because you were doing the thing instead of trying to remember the thing. That is the whole trick. Your reflexes only show up when your hands are moving.

Then take the transcript and have an AI turn it into the five section format. Drop it into Claude or whatever you have access to through Galaxy.ai if you would rather not juggle four separate subscriptions, and tell it exactly what you want. Trigger, outcome, numbered steps, guardrails, who to ask. Tell it to cut anything that is not an instruction. Tell it to keep every warning you said out loud.

For recording the walkthrough itself, Fathom works well if you are already using it for calls, because you get a clean transcript without adding another tool to the stack. And if you want the messy version of this where somebody just talks through a process on their phone while driving between jobs, Littlebird.ai handles that kind of loose capture better than most.

Twenty five minutes, start to finish, for a document that would have taken you three hours to type and would have been worse.

Then you do the part that actually matters. You hand it to somebody and watch them use it. Every place they hesitate is a missing step. Every place they ask a question is a missing guardrail. You fix those two things and the doc is done forever.

You should not document everything. Most owners who get excited about this go on a two week documentation bender, produce forty documents, and then never look at any of them again because thirty of them covered things that happen twice a year.

Here is the filter I use. Document it the second time somebody asks you.

First time is a question. Second time is a pattern. The second time somebody asks how to handle a chargeback, you do not answer in Slack. You record yourself answering, turn it into a page, send the page, and then send that same page to the next person who asks.

This does two things. It means you only ever build documentation for things that are actually recurring, and it means the docs get built during work you were already going to do, instead of during a weekend you were hoping to have off.

Rank what to build by two factors. How often does it happen, and how bad is it when it goes wrong. A weekly task that occasionally torches a client relationship gets documented today. A quarterly task that is annoying but harmless can wait until next quarter, or forever.

Every process document is wrong within about four months. Software changes, a vendor changes, you change your mind about a step.

Most companies handle this by having the owner do a "documentation review" once a year, which is a task that has never once been completed by anyone in the history of business.

Here is the version that works, and it is a rule rather than a project.

Whoever hits a wrong step fixes the step. Not flags it. Not tells you about it. Fixes it. You give everyone edit access and you tell them explicitly that updating a doc when reality has moved is part of doing the job, not a favor to you.

People will be nervous about this at first because they will worry about breaking something. Tell them the version history exists, nothing is permanent, and you would rather have a doc somebody improved imperfectly than a doc everybody knows is wrong and nobody touches.

One place. Not a folder tree. Not a Drive folder and a Notion space and a pinned Slack message. One place, linked from wherever the work actually happens, so somebody hits the doc at the exact moment they need it rather than having to remember it exists.

That last part is worth more than the writing. A perfect document nobody can find at the moment of need is identical to no document. If you want to close that gap without relying on memory, wire it into the workflow. Make.com can drop the right link into the right channel the second a job hits the stage where somebody needs it. The doc shows up where the work is instead of waiting in a folder to be remembered.

On Monday I made the case that most of your day is decisions your team could make with permission. Today is the other half of it.

Permission without process is just faster guessing. You can tell somebody they are cleared to handle refunds all day long, but if the refund process lives exclusively in your head, all you have done is move the moment they have to interrupt you from the start of the task to the middle of it.

Ten one page documents covering the ten things that come up most often will kill more interruptions than any amount of delegating. And unlike the sixty page manual, they get used, because they were built for the moment somebody is stuck instead of for the fantasy of a complete system.

My client with the sixty page manual? We killed it. Pulled out the nine processes that came up weekly, rebuilt them as one pagers using the recording method, and put them where the team already worked.

His question volume dropped by more than half in about three weeks. The sixty page document is still sitting there, by the way. Nobody has opened it. Which is fine, because it turns out the problem was never that his team would not read. It was that he had written something nobody could use.

On Friday we go after the next piece, which is what happens when you have finally got permission and process sorted and you are ready to hand real work to a real person. Most owners hire exactly the wrong person first, for reasons that feel completely logical at the time.

Reply with SOP and I will send you the one page template. Five sections, prompts in each one, plus the AI prompt I use to turn a rambling walkthrough transcript into a clean doc in a single pass.

Talk Soon,
Dan
Dan Kaufman
Founder, Dead Simple Growth and Pinnacle Masters

P.S. Quick sanity check on any doc you already have. Open it, read the first ten lines, and ask whether those lines tell somebody what to do or explain to somebody how things work. If it is explaining, you have a reference document. Reference documents are fine, they are just not the thing that stops your phone from buzzing.