How to Write a Standard Operating Procedure That Actually Gets Used

The work that only you can do is not a badge. It is a cap. A standard operating procedure is how you get it out of your head and into the business.

There is a job in your company that only runs when one person is in the room.

Maybe it is you. Maybe it is your best operator. When they are out, the work waits. When they are buried, the work waits. When they finally leave, the work walks out with them.

That is not a people problem. It is a documentation problem. The knowledge lives in a person instead of the business. A standard operating procedure, an SOP, is the fix: a written record of exactly how a piece of work gets done, so anyone can run it the same way every time.

This is a plain guide to writing one that actually gets used, not one that gets built once and buried in a drive nobody opens.

What a Standard Operating Procedure Actually Is

An SOP is not a policy. It is not a 40-page manual. It is not a compliance document written to sit on a shelf.

An SOP is the working truth of how one task gets done, written so a capable person who has never done it could pick it up and run it correctly. One process, start to finish, in steps.

Good SOPs are boring on purpose. "Boring" means clear. The test is simple: could someone new do this task from your document without asking you a single question? If yes, you have an SOP. If they would still need to tap you on the shoulder, you have notes.

Why SOPs Matter (What No Longer Depends on You)

Here is the question every SOP answers: what no longer depends on the owner?

When a process lives only in someone’s head, the business is capped at that person’s hours. Growth means more of their time, not more capacity. That is the ceiling most operators hit. Not a lack of demand. A lack of anything that runs without them.

Writing the SOP breaks that link. Once the work is documented:

• A new hire ramps in days instead of months.
• The task runs the same whether the expert is there or not.
• Quality stops depending on who happened to do it that day.
• And, when you are ready, the work can be handed to a person or run by an agent, because the steps finally exist in writing.

You cannot delegate, and you cannot automate, what you have never written down. The SOP is step one of both.

How to Write an SOP, Step by Step

You do not need special software to start. A document and an honest look at how the work really happens is enough.

1. Pick one process, and make it a small one. Do not try to document "sales" or "onboarding." Pick a single, repeatable task with a clear start and a clear finish. "Send a quote after a site visit." "Onboard a new client." "Close the books each month." One path, one owner, one outcome.

2. Watch it happen before you write it. The fastest way to write a wrong SOP is to write it from memory at your desk. Watch the task get done once, in real time, and note every step as it actually occurs, including the parts people do on autopilot. The gap between how you think the work happens and how it actually happens is where SOPs usually break.

3. Write each step as an action. Every step starts with a verb and names who does it. "The office confirms the scope with the tech." "The owner prices the job." Short, literal, in order. If a step has more than one action buried in it, split it. A reader should never have to guess what to do next.

4. Mark the decision points. Real work is not a straight line. There are moments where it branches: if the job is over a certain size, it needs approval; if the customer has not replied in two days, someone follows up. Write the rule for each branch plainly, so the reader knows what to do without asking. This is the part most SOPs skip, and it is the part that sends people back to your desk.

5. Define "done." Every SOP needs a clear finish line. What does a completed task look like? The estimate is sent and logged. The invoice is paid and closed. The client has access and their first call is booked. If "done" is fuzzy, work gets dropped one step short of the finish.

6. Test it with someone else. Hand the SOP to a person who does not do this task and watch them run it. Every question they ask is a hole in the document. Fill the holes. An SOP is not finished when you finish writing it. It is finished when someone else can run it without you.

7. Keep it living. The work changes. A buried SOP that describes last year’s process is worse than none, because people trust it and get it wrong. Note the date, name an owner, and review it when the process changes. A short SOP that is current beats a thorough one that is stale.

A Simple SOP Template

You do not need a fancy format. This skeleton covers what matters:

• Process name: what this SOP covers, in plain words.
• Owner: who is responsible for the process and for keeping this document current.
• When it runs: the trigger. What starts this process.
• Steps: the numbered actions, each one a verb and an owner.
• Decision points: the branches and the rule for each.
• Done means: the clear finish line.
• Last reviewed: the date, so anyone can see if it is current.

Start there. Add only what a real reader would actually need.

Common SOP Mistakes (and How to Avoid Them)

• Too long. If it reads like a manual, no one will use it in the moment. Write for the person doing the task at 8 a.m., not for an auditor.
• Too vague. "Handle the follow-up" is not a step. "The admin sends the follow-up email within one business day" is. Name the action, the owner, and the timing.
• Written from memory. The desk version and the real version are different documents. Watch the work.
• No owner, no date. An SOP nobody owns and nobody reviews quietly goes stale. Both fields are not optional.
• Built once, never opened. The goal is not a finished folder of SOPs. The goal is work that runs the same way without you in the room.

From Documented to Done

Writing SOPs is the unglamorous first move of building a business that can grow without more of your hours. It is also where most operators stall, because doing the work and documenting the work compete for the same time, and the work always wins.

That is the point where mana comes in. We start with an audit of where your business still depends on you, help capture and clarify those processes, then build company-specific agents that run the documented work inside the tools you already use. The big calls still reach you. Everything else runs on its own.

You do not need us to write your first SOP. Pick one process this week, watch it happen, and write the steps down. But if you want a clear map of what to document, what to hand off, and what to automate first, that map is exactly what a mana roadmap gives you.

Start by getting one process out of your head. That is where a business that runs without you begins.