A free SOP template. One your team will actually open twice.

What the template covers. Five sections, not fifteen.

A free SOP template is only useful if someone actually fills it in, and most of the templates I've seen founders download never get past the first blank page, because they ask for a project plan when what's needed is a single page someone can follow under pressure. This one has five sections. That's deliberate. Every extra section past five is a reason to close the tab and come back to it later, which in practice means never.

Purpose. One line. What this task achieves and why it exists, so a new hire understands the point before they read a single step.

Trigger. The specific event that starts the task. Not "when a client joins" but "when the signed contract lands in the shared inbox." A vague trigger is the single most common reason an SOP sits unused, because nobody is quite sure when it applies.

Steps. Numbered, written in the order the task actually happens, each one an instruction rather than a description. "Log the deal in the CRM under Stage 3" reads and executes differently to "the deal gets logged."

Exceptions. The two or three variations that come up regularly: the client who pays by bank transfer instead of card, the request that arrives out of hours, the field that's sometimes missing. This is the section every rushed SOP skips, and it's the one that determines whether the document survives contact with a real week.

Owner and review date. A named person responsible for keeping it accurate, and a fixed date to check it again. Without both, an SOP degrades quietly until someone follows an outdated version and something goes wrong.

An IDC white paper commissioned by Ricoh, one of the more thorough studies of what happens when document-based processes break down, found that three in four organisations, 75.9 percent, had suffered a serious consequence in the previous five years directly tied to poor or missing process documentation: a compliance failure, a lost customer, a departed employee taking undocumented knowledge with them. None of that requires a large business or a complicated process. It requires one task that only one person knows how to do properly, and no record of what they actually do.

How to use it. Fill it once, then test it on someone who has never done the task.

Start by watching, or asking, the person who currently does the task well to walk through it exactly as they do it, not as the manual would describe it if one existed. This matters more than any formatting choice. An SOP written from memory by a manager who hasn't done the task in a year reliably misses the two workarounds that make the real process actually function.

Write the trigger and the final outcome first, before the steps in between. Knowing where a task starts and what "done" looks like keeps the middle section honest, because it's easy to pad an SOP with steps that feel thorough but don't change the outcome.

Cover the exceptions properly rather than adding "handle as needed" at the bottom. That phrase is where good intentions go to die; it tells the next person nothing and sends them straight back to whoever they were trying to avoid interrupting in the first place.

Then test it. Hand the draft to someone who has never done the task and watch them attempt it using only what's written down. Every place they hesitate or ask a question is a gap in the SOP, not a gap in their competence. I run this test with every SOP I help a client produce, and it's rare for a first draft to survive it without at least one correction, usually in the exceptions section rather than the main steps.

Assign the owner and set the review date before publishing it anywhere. A task that changes often, a client-facing process during a busy season, or anything touching pricing or compliance, deserves a three-month check. A stable back-office task can go a full year between reviews.

A worked example. A client handoff, filled in.

Here's the template applied to a task I see done badly more often than almost any other in founder-led businesses: handing a newly signed client from sales to delivery.

Purpose: Move a signed client from sales into active delivery with nothing lost and no delay the client can feel.

Trigger: The signed contract is logged in the CRM and marked Closed Won.

1. Sales rep updates the CRM record with the final scope, agreed price and any promises made verbally during the sales process that aren't in the contract.
2. Sales rep books a 15-minute handoff call with the delivery lead within 24 hours of the contract being signed.
3. Delivery lead creates the client's project workspace and sends the welcome email within one business day of the handoff call.
4. Delivery lead confirms receipt of all scope and pricing detail back to the sales rep in writing, so any gap surfaces before the client notices it.
5. Client's first working session is scheduled within five business days of contract signature.

Exceptions: If the client signed outside standard scope (a custom add-on, a non-standard payment schedule), the sales rep flags this explicitly on the handoff call rather than leaving it in contract small print for delivery to find later. If delivery capacity is full for the current sprint, the delivery lead sets client expectations on timeline during the handoff call itself, not after the welcome email has already promised a start date.

Owner: Head of Delivery. Review date: every four months, or immediately after any handoff that goes wrong.

A twelve-person consultancy I've advised had this exact handoff running entirely on a founder's memory of who to loop in and when. New clients sometimes waited ten days for a first session because nobody owned the step between "contract signed" and "workspace created." Writing this five-section SOP and testing it on a new hire who'd never seen the process cut that gap to five days without anyone doing more work, because the work already existed. It just hadn't been written down anywhere the whole team could see it.

My rule on templates like this one: fill it against a real task in the next week, not a hypothetical one. A template that sits in a folder waiting for the "right" process to document never gets used, and the task most worth writing down is usually the one currently living only in someone's head. For the wider method behind writing SOPs that survive contact with a real week, see the fuller guide to creating an SOP, and for why this is worth the two hours it takes, see why SOPs matter for a founder-led team.