How to Write Standard Operating Procedures Your Team Can Actually Follow

Search “how to write standard operating procedures” and the top organic result is a Penn State Extension guide for running a dairy milking parlour. Scroll further and the rest of page one is pharma compliance guidance, an NIH paper on clinical trial protocols, and a Northwestern document written for clinical researchers. None of that is bad advice. It is advice written for readers who are legally required to follow the document in front of them. A parlour worker who skips a step can contaminate a batch that gets tested. A clinical researcher who improvises around a protocol can invalidate a trial. Nobody in a marketing agency is bound that way, and that single difference is most of why agency standard operating procedures get written once and then sit in a folder nobody opens.

I cover why the library matters and how to keep it alive in the wider SOP guide. This piece is about the document itself: how to write one a stressed teammate can follow cold, without pinging you on Slack. My basis for it: twelve years running delivery operations for marketing agencies and 92 completed engagements, inside ClickUp, Asana, Monday.com, Airtable, Notion and n8n.

Where do the steps actually come from?

Most bad SOPs are written from memory, days or weeks after the task, by whoever felt guilty about not documenting it yet. Memory compresses. It keeps the outline and drops the fiddly middle steps, exactly the ones nobody explains out loud anymore because everyone on the team stopped noticing them years ago. The fix is not a better memory. It is timing: write the procedure while you are doing the task, not from a mental replay of it afterward.

If you are the one doing the work, keep a document open beside it and log each action in the order you actually take it, before deciding which parts matter enough to keep. Trimming a list of real actions is easy, five minutes with a highlighter. Reconstructing a list of actions you skipped noticing is not, and you will not find out what you skipped until a new hire hits a question the document cannot answer.

If someone else does the work, do not interview them about it afterward. An interview produces the tidied, official version of a process, and that version is rarely the one that runs on a Thursday afternoon under deadline. Sit with them while they do the task, and write down what their hands actually do, including the workaround they reach for when QA fails at the last minute, and the shortcut they take when three reports are due the same day. Those are not deviations to edit out. They are the procedure.

How do you turn a task into steps someone else can follow?

An imperative, single-action step reads as a command aimed at one person doing one thing, not a description of an area of responsibility. The test I run on every draft step is the word “and.” If a step contains it, it is almost always two steps wearing one bullet, and the second half is where a new hire loses the thread.

Write each step as verb, object, location: what to do, to what, and where. The extra words are not padding. They are the difference between a step someone can execute without asking, and one that generates a Slack message asking where the field is or which report they mean.

• Too vague: “Update the project status.”
• Actually usable: “Set the ClickUp task status to Live and add the launch date in the custom field.”

Granularity has a floor, though, and it is not zero. You are writing for a competent adult who has never done this specific task, so the step can assume they know how to open ClickUp, but cannot assume they know which field you mean by “the field.” Name the field. Name the tab. Name the exact button if more than one plausibly matches. Ambiguity does not read as flexibility to the person following it. It reads as a decision they now have to make on your behalf, with no idea whether they got it right.

Where do most procedures go quiet on the exceptions?

Write the happy path first. It is the fastest thing to get down and it gives the document a spine. Then ask the harder question: what happened the last few times this went sideways? Every recurring task has a short list of ways it actually breaks, and that list usually lives in your head or a teammate’s head, not in the document.

Turn each of those into a named branch inside the same procedure, not a separate document nobody will find under pressure. Name who decides, in the branch itself. Leave the decision unnamed, and whoever is free when the ticket lands makes the call, so the same exception gets handled a different way each time, and the variation becomes a second problem stacked on the first.

• Branch: If a client cancels with deliverables already scheduled for the week, the account lead decides which ones still ship and which are dropped.
• Branch: If two reports are due the same day, the account lead decides which one ships first.

Scope still matters here: a procedure covering every conceivable exception becomes one nobody reads before acting, which defeats the purpose. Cover the branches that actually recur, and leave the rare one-off to a judgment call and a note to the process owner.

How do you know when a step is actually finished?

A definition of done is an observable state, not an action you performed. “I sent the report” is an action. “The report is sent, logged in the client record, and the next send date is set” is a state, one a colleague can check an hour later without asking you. If they have to ask, the definition does not work, no matter how confident it sounds on the page.

Write it at the end of every step that could plausibly be called finished before it actually is. Reporting, QA, and client handoffs are where this matters most, because those are the places agencies quietly downgrade work under deadline pressure, and a checkable definition of done is what stops close enough from passing as complete. It is also the easiest way to test a procedure for errors: ask whether the last sentence of each step describes something you could point to, or something you would have to take someone’s word for.

What should actually trigger the procedure?

A trigger is an event, not a process name. “QA review” is a heading. “A deliverable is marked ready to send” is a trigger, and the difference is not cosmetic. A heading describes a topic. An event tells someone exactly when to start. Procedures that open with a heading instead of an event get started late, started by the wrong person, or not at all, because nobody was watching for a topic.

Naming the trigger as an event also tells you, almost for free, whether the step belongs to a person or a tool. A specific, repeatable event is exactly what a workflow tool can watch for on its own. I build a fair number of these triggers directly into ClickUp, Asana, Monday.com, Airtable, and Notion, connected through n8n, once the procedure has proven itself with a person running it by hand first. Automating a trigger before the procedure is stable just automates the wrong version faster.

The prerequisite list belongs near the trigger for the same reason. If a step assumes access to a tool, a login, or information that has to arrive first, say so before the steps begin, not halfway through step four, when the person following the procedure discovers they cannot do what it asks.

How do you find out if the procedure actually works?

Hand the finished draft to a competent person who has never done the task, not a new hire you have already half-trained by osmosis, and ask them to complete it using only the document. Sit where you can see the screen and say nothing. Every hesitation, every re-read, every moment they look up to ask a question, is feedback about the document, not the person. Note it and keep working. Do not answer.

The first draft fails this almost every time, which is why the test happens before the procedure goes live, not after a new hire’s first bad week. Fix what tripped them, run it again with someone else, and stop only when a stranger gets through it without asking a single question. That is the actual bar for done, regardless of how polished the document reads to you.

A step that reads clearly to you, who already knows the task, tells you nothing about how it reads to someone encountering it for the first time. Comprehension is the only metric that matters, and it can only be measured on somebody who does not already have the answer in their head.

What actually goes in the document, top to bottom?

Most agencies never fix a shared format, so every SOP in the folder looks like it came from a different team. A standard operating procedure earns the word “standard” by using the same shape every time. Here is the anatomy I use, field by field, top to bottom:

Field	What goes there
Title	The task, named the way the team already talks about it, not a formal label nobody uses out loud.
Purpose	One sentence: the outcome, or objective, this procedure exists to produce, not a restatement of the title.
Scope	What this procedure covers and, just as important, what it does not. A scope line saves the next person from applying the wrong document to a task that only looks similar.
Prerequisites	Access, tools, templates, or information that has to exist before step one can start.
Roles and responsibilities	Who is involved and what each of them is accountable for, named by role, not by a person’s name that will be wrong in six months.
Process owner	One named person, visible at the top, accountable for the document staying correct.
Steps	The sequence itself, in the imperative, one action per step, covered in full in the next section.
Definition of done	The observable state that ends the task, described above.
References	Links to the templates, tools, or adjacent procedures a step points to, rather than instructions duplicated inline.
Revision history	Version number, date, what changed, who changed it.
Review date	When this document is checked again by its named reviewer, regardless of whether anything has changed.

That table is the deliverable. There is no downloadable template attached to this piece, and there will not be one added later: a template you did not build from your own process is a shape without your content in it. Build the fields yourself, in whatever tool your team already lives in, and the format will be right because you understand every field inside it. Scope and revision history are the two most often skipped, and skipping either is what lets two documents quietly contradict each other, or lets a stale procedure keep passing as current.

Whether the whole document stays trustworthy after today is a question for the wider guide, not this one: keep the review date current, and treat a missed review as a signal rather than a scheduling accident, and staleness stops being a mystery.

How do you write a step someone can actually follow?

The anatomy above tells you where a step lives on the page. This is about the sentence itself, the part most agency procedures never do well, because writing plainly is harder than most people give it credit for. Clarity is the only design goal a procedure has; every technique below just buys more of it.

Use active voice and the imperative mood. “The report should be sent by end of day” hides who is doing the sending. “Send the report by end of day” names the actor implicitly, the person reading it, and states the action as an instruction rather than a description. Every step in a well-written procedure reads like a command, because that is what it is.

Be precise about must versus should. “Must” means the task is not done without it. “Should” means a default applies, but judgment is allowed. Agencies that use the two interchangeably end up with a document nobody can rely on: a reader cannot tell which steps are safe to skip under deadline, so either everything becomes optional or nothing does, and the second is exhausting to work inside.

Expand every acronym on first use, even ones your team says out loud all day. “QA” means quality assurance to someone who has worked here two years, and means nothing to the contractor you brought on last week or the new hire in their first month, and a procedure exists precisely for people who do not already know the shorthand. The same goes for jargon specific to your agency and nothing to anyone outside it. Define the term once, in the procedure, rather than assuming the reader arrives with the same references you do.

Keep one action per step, plain language throughout, and resist writing a step the way you would explain the task out loud, in a single breath with a qualifier tacked on the end. A spoken explanation can be interrupted with a question. A written one cannot, so it has to remove the ambiguity that question would have caught, or confusion is what the reader is left holding instead.

When is a flowchart better than a numbered list?

A numbered list assumes the reader moves through steps in one direction, start to finish, with no real decision points. That holds for most procedures, which is why a list should be the default format. It is fast to write, fast to scan, and fast to update.

It breaks down once a procedure has more than two or three branches that depend on each other, where the answer to one question changes which path applies next. A flowchart or a simple diagram makes the branching visible instead of implied, so the reader follows a line instead of reconstructing the logic from prose.

The test is the shape of the decisions, not the length of the procedure. A twenty-step onboarding checklist with two exception branches near the end is still a list, with the branches called out as above. A five-step approval process where three outcomes are equally likely is a flowchart wearing a list’s clothes, and writing it as a list just hides the branching instead of removing it.

Screenshots and short screen recordings earn their place for a specific interface, a field buried three menus deep, or anything faster to show than describe. Use them sparingly: an interface changes more often than a process does, and screenshots age out the moment a vendor redesigns a dashboard, while the words describing the task stay accurate for years. A checklist is the right format for a list of items to confirm with no real sequence and no branching, QA before send being the clearest example.

Who should write it, and who owns it after?

The person who does the work drafts the procedure, not their manager, and not someone brought in from outside who has never sat with the team doing it. Distance from the task produces a document that sounds right and runs wrong, the same reason an interview produces the tidied version instead of the real one.

Ownership after the document is written is separate from authorship, and conflating the two is where most agencies lose the thread. The person who wrote the first draft is not automatically accountable for it two years later, especially once they change roles or leave. Name a process owner explicitly, as a role rather than a person’s name wherever the tool allows it, so a reader always knows who to ask when the procedure and reality disagree.

There is also a cost question nobody says out loud. Writing a procedure properly takes real hours from the person doing the billable work it describes, and if nobody has decided whose time that is, the writing quietly stops the first week delivery gets heavy. Treat it as time spent on the account it protects, the same way a status call would be.

This is also where writing the document and running the work stop being the same job. A well-written procedure tells a team member what to do. It does not put anyone in the seat that decides whether the procedure is still right, resolves an exception nobody wrote a branch for, or notices a document nobody has opened in a year. That accountability is a role, not a page, and its absence is what having someone in a fractional COO seat is for. Writing the procedure and owning it are two different pieces of work, and an agency needs both.

Can you just have AI write it?

Partly, and it is worth being specific about which part. A model is genuinely useful once you have described a process to it in rough form: it will tighten the language, catch a missing step in a sequence you talked through out loud, suggest a cleaner structure for the anatomy above, and turn a voice memo or a messy set of notes into something close to a first draft. That is a real time saver, and I would not talk anyone out of using it for that part of the job.

What it cannot do is know your exceptions. It has not sat in the room when a client cancelled mid-week with deliverables already scheduled, and it does not know which branch your account leads actually take when that happens, because that decision has never been written down anywhere a model could read it. It cannot tell you which step your team silently skips under deadline pressure, because the skipping happens in practice, not in any document a model was trained on. And it will confidently produce a plausible-sounding procedure for a task it has never seen your agency actually perform, filling every gap with something generic rather than flagging the gap as a question you need to answer yourself. A plausible paragraph reads as confidence, not as the confusion an honest blank would have signalled, which is exactly why it is the more dangerous failure of the two.

The honest version of this is that AI shortens the drafting step and does nothing for the observation step that has to happen before drafting starts. You still have to watch the real task, or sit with the person doing it, before there is anything true to hand to a model in the first place. I have written the fuller version of where AI actually saves agency hours, and where the industry numbers on that stop being honest, in a separate piece built entirely around that question. The short version for this one: use it to tighten what you already know. Do not use it to discover what you do not.

So what does writing a working standard operating procedure actually take?

Not talent, and not more time than the bad version already costs you. My verdict after twelve years of doing this work: a procedure written from the work itself, in imperative single steps, with its branches named, a checkable definition of done, and the format fields filled in the same order every time, takes roughly the same afternoon as the vague version most agencies already have sitting unused in a folder. The difference is entirely in what happens before you type the first word. Watch the real task. Do not recall it.

The craft questions above, where the steps come from, how granular to write them, where the exceptions hide, what counts as finished, what triggers the procedure, whether a list or a flowchart fits the shape of the decision, and who is actually accountable once it is written, answer almost everything that makes a document unusable. None of them are about talent. All of them are habits, and habits get easier the second time you do them, not harder.

Where to start

If writing five or six of these yourself is more time than your week has room for, that is the work I do as SOP consulting: sitting inside your delivery process and writing the documents from the actual work. If the process underneath is not settled yet, or nobody is accountable for the documents once they exist, a better-written page will not fix either problem.

Before any of that, it helps to know what should already exist in your delivery process, which is why I keep a running agency operations checklist. And if you want to know which processes your agency should write first, in what order, and who should own each, that is what the Agency Ops Audit is built to answer.