How to Write an SOP (Free Template, and a Tool That Writes It For You)

A standard operating procedure is a written, step-by-step record of how a task actually gets done: who does each step, what tools are involved, what information moves, and where it breaks. The fastest way to write one is to map the process first and generate the SOP from the map, instead of staring at a blank template. This post gives you both: the template, and a free tool that fills it in for you.

What an SOP Actually Is (and What It's For)

An SOP is how a process survives without you. It is the written version of something that currently lives in someone's head. When it's good, a new hire can run the process correctly on their first day, and you can take a vacation without your phone going off.

Here's the test I use after 40 years of building systems for businesses: if the one person who knows how to do something got hit by a bus tomorrow, would the work stop? If the answer is yes, you don't have a process. You have a person. An SOP is how you turn that person's knowledge into something the business owns.

The Fast Way: Map It, Then Generate It

Here's the thing nobody tells you. The reason SOPs feel like a chore isn't the writing. It's that a blank document asks you to recall a messy, branching, real-world process in perfect linear order, from memory, in prose. That's hard. Humans are good at recognizing a process when they see it laid out, and bad at reciting it cold.

So flip the order. Lay the process out visually first: the people, the steps, the decisions, the spreadsheets and apps it runs on. Once it's in front of you, the gaps jump out, and the writing becomes mechanical.

We built a free tool that does exactly this. You drop the pieces of your process onto a canvas, connect them, flag the parts that hurt, and click once. It hands you a clean SOP your team can follow and a developer-ready brief, if you ever want the process built into real software. No account, no signup, and your map never leaves your browser unless you ask us for help.

How to Write an SOP, Step by Step

Whether you map it first or write it straight, the bones are the same. Five steps.

1. List every step in order

Write down each thing that happens, start to finish, in the order it actually happens. Not the ideal version you wish were true. The real one, workarounds and all. The real version is the only version worth documenting, because it's the one people actually run.

2. Put a name on every step

Every step has an owner: a person or a role. Go through and name them. The valuable part of this step is the steps where you can't name an owner, or where the honest answer is "me, because nobody else knows how." Those are the spots that will bite you, and they belong in the document.

3. Note the tools and files

Mark which spreadsheet, app, or system each step touches, and what information moves between them. This is where most processes quietly leak: the same data gets typed into two systems by hand, and nobody owns the gap. Write it down. Seeing it on paper is usually the moment someone says "wait, why are we doing that twice?"

4. Flag where it breaks

Mark the steps that cause double entry, delays, errors, or depend on one person's memory. Most SOP templates skip this entirely, which is a mistake. The breakage is the most useful thing a reader can know, because it tells them where to be careful and where the business is exposed.

5. Turn it into a written procedure

Now write each step as a plain instruction: who does it, what they use, what they produce, and what to watch for. Short sentences. No jargon. Read it out loud, and if it doesn't sound like a normal person explaining the job to a new hire, rewrite it. Or skip this step and let the tool generate it from your map.

A Free SOP Template

Here's the whole structure. Copy it, fill it in, done.

That "known risks" row is the one most templates leave out, and it's the one that turns a document into something useful. The free Process Mapper fills all of this in for you from a map, including the risks, from the parts you flag as painful.

Why Most SOPs Rot (and How to Stop It)

Here's the honest part. Most SOPs are written once, saved in a folder, and never opened again. Within a few months the process has changed and the document is a lie. People stop trusting it, and you're back to the knowledge living in someone's head.

The root cause is that a written document and the real process drift apart the second something changes, and nobody wants to rewrite a doc by hand every time. The fix is to keep the map and the document tied together. Change the map, regenerate the SOP. The map is the document. That's the whole idea behind the tool, and it's why we give it away: a clear process is the first step toward a business that runs without depending on any one person.

Which brings up the question worth sitting with: is your tech running you, or are you running it? Writing the process down is the small first move of taking it back.

Common Questions

What is a standard operating procedure?

A written, step-by-step record of how a task gets done: who does each step, what tools are involved, what information moves, and where it tends to break. A good one lets someone else run the process correctly without you in the room.

What's the fastest way to write an SOP?

Map the process first, then write it up from the map. The blank template is the slow way. Laying the steps out, then turning that into prose, is faster and catches gaps. The free Process Mapper does the second half automatically.

Where should SOPs live?

Wherever your team already looks every day. But the deeper fix is keeping the map and the document tied together so the SOP updates when the process does, instead of going stale in a folder.