How to Write an SOP: A Free Template You Can Copy

A fillable standard operating procedure template, reverse engineered from real SOPs we have built for clients, plus a plain English walkthrough of how to fill in every section.

To write a standard operating procedure you do not need a fancy platform or a 40 page manual. You need a repeatable structure. The template below is the exact skeleton the SOPs in our client library share: a clear title, a short metadata block, a Why This Matters section, a Trigger that names when the process runs, the numbered steps, a definition of what Done looks like, and an Edge Cases section for the exceptions. Copy it, fill it in for one task, and you have a usable SOP in under an hour.

Why Most SOPs Fail Before the First Step

When an owner finally sits down to document a process, the instinct is the same: open a blank page and start typing steps. Step one, step two, step three. The result is a flat list with no context, no stakes, and no acknowledgment of the ten ways the task goes sideways in real life. Nobody follows it, and three months later it is wrong.

The fix is not more discipline, it is a better structure. When we pull apart the SOPs that actually get used inside real businesses, the same seven bones show up every time, whether the document covers how a service specialist handles a client call or how a rep responds to a new lead. That pattern matters because the gap it closes is enormous. Across the 16 businesses we have systematized, only about 27 percent of core processes were documented before we walked in, and fully half had documented nothing at all. These are good companies running on knowledge trapped in a few people's heads. The template below is how you start getting it out.

The Seven Parts of a Real SOP

Every part earns its place. Skip one and you can predict exactly how the SOP will fail.

Section	What Goes In It	The Mistake to Avoid
Title	An action plus an object, so the name tells you what the SOP does. "Process a New Vendor Invoice," not "Invoices."	Vague nouns. A title that is a category, not a task.
Metadata block	Subject or group, the owner role, everyone who touches it, and the date it was last reviewed.	No owner. If nobody owns it, nobody maintains it.
Why This Matters	Two to four sentences on what the task protects and what breaks when it is done wrong.	Skipping it. Steps with no stakes get skipped too.
Trigger	The exact event that starts the process and the result that means it is finished.	Starting mid-stream, so the reader never knows when to begin.
The Steps	Numbered actions, each a verb plus an object, with the standard for that step baked in.	Fuzzy verbs like "handle" or "manage" with no bar attached.
What Done Looks Like	The short checklist that proves the work is finished and correct.	Ending on the last step with no way to confirm it worked.
Edge Cases	The exceptions, the judgment calls, and the mistake that costs the most.	Pretending the process is always clean. It never is.

The two sections almost everyone leaves out, Why This Matters and Edge Cases, are the two that decide whether the document lives or dies. The Why earns buy-in; the Edge Cases earn trust, because they prove the SOP was written by someone who has done the job on a bad day. For the deeper argument on why documents without them get ignored, see why your SOPs collect dust.

The Free SOP Template (Copy This)

Everything in brackets is a prompt for you to replace. The structure stays; the content is yours. This is the same skeleton behind every finished SOP in our library.

How to Fill In Each Section

Here is how to fill each part so the finished SOP is one people can pick up and run without asking you a single question.

1. Title and metadata at the topName it the way the doer would say it out loud, an action plus what it acts on ("Respond to a New Inbound Lead," not "Leads"), then add the owner role, everyone else who touches it, and a last-reviewed date. An SOP with no date is one nobody trusts is current.
2. Write Why This Matters for the person, not the bossTwo to four sentences on what goes wrong if this is skipped. Ours read like "if a statement gets missed, the escrow tracking goes stale and a charge slips past for a month." Concrete stakes get a distracted team member to care about step four.
3. Name the trigger and the finishThe exact event that starts it and the result that ends it: "Starts when a web form hits the CRM, ends when the appointment is logged." This also draws the boundary of what the reader owns versus what belongs upstream or downstream.
4. Write each step as a verb, with the standard baked inNot "respond quickly" but "make first contact within two minutes." Not "name the file properly" but a literal convention like YYYY-MM_Property_Lender.pdf. Where a step involves talking to someone or producing a document, drop in the exact script or format. Vague steps are where SOPs quietly die.
5. Define what Done looks likeA short checklist that is all true when the job is finished: the record updated in every system, the confirmation sent, the file archived. Without it, people stop at the last step and never confirm the outcome landed.
6. Capture the edge cases honestlyList the frequent exceptions, the judgment calls with their default answer, and the single most expensive mistake. "If you cannot tell which entity a cost belongs to, default to the parent and flag it" beats three pages of ideal-world instructions.

The Rules That Separate SOPs People Follow From SOPs That Collect Dust

The template gives you the structure. These three rules give you the quality.

Write in the doer's language, not corporate speak

Use the words the team already uses. If they call it "the launch binder," the SOP says launch binder, not "client onboarding documentation package." An SOP that sounds like a compliance memo gets read like one, which is to say, not at all. It should sound like a competent coworker explaining the job, because that is what it replaces.

Be specific and finished, with no placeholders

A live SOP has no vague steps and nothing left as a bracketed to-do. A procedure that ships with "TBD" in the middle teaches the team the whole document is optional. And bake the standard into each step: "follow up" becomes "send a holding reply the same business day, with a specific date for the answer." The standard is what makes an SOP enforceable instead of a suggestion.

Validate it against a second person who does the job

Hand the draft to a second person in the role and watch them follow it without help. Every place they hesitate is a gap. Fix those and you have a document that works, not just one that reads well. For more on reaching that follow-it-without-asking bar, see how to write SOPs your team will actually follow.

Where the Template Fits in the Bigger Picture

An SOP documents one step done correctly, and it lives inside a larger system. Above it sits the process map, the flowchart of how a whole process moves from trigger to finish and who owns each part. The map is the skeleton; your SOPs are the muscle. If you have not mapped the process yet, our complete guide to process mapping shows you how, and the map tells you exactly which SOPs you need and in what order. To document a whole business rather than a single task, the wider method is in how to document business processes.

One template, filled in well, for one painful process, is a genuine unlock. Do it across the handful of jobs that only live in your head and you have built what most owners never do: a business that runs whether or not you are in the room. For the full method behind a single procedure, see how to write an SOP, and when choosing what to document first, start with the first five SOPs every small business should write rather than boiling the ocean.

The Bottom Line

Writing an SOP is not a writing problem, it is a structure problem, and the structure is already solved: seven parts, from the title to the edge cases. Copy the template above, sit with the person who does the work, and fill it in one honest section at a time. Skip the corporate voice, refuse to leave placeholders, and tell the truth about the exceptions. Do that and you will have written the rare kind of SOP that people open, trust, and follow, which is the only kind worth writing.