What is a standard operating procedure? The written version of how your business actually runs.

The short answer. One task, written down properly.

A standard operating procedure is the answer to "how do we actually do this?", written down so the answer does not live only in one person's head. It is narrower than a process map, which shows how several tasks connect, and narrower still than a policy, which sets a rule rather than a method. An SOP covers one task: onboarding a new client, closing the books at month end, responding to a support ticket, and it spells out the steps in the order a person actually needs to follow them.

The formal definition, the one used across quality standards like ISO 9001:2015, treats a documented procedure as a controlled record: it states what is done, who does it, and under what conditions, so that a task performed by two different people produces the same result. That is the practical test worth applying to any SOP a business writes. If handing the document to someone who has never done the task before would not let them complete it correctly, it is not finished yet.

Why it matters. The business stops depending on memory.

Most founder-led businesses do not lack process, they lack written process. The steps exist, they are just stored in the founder's head, or in the head of whichever employee has done the task the longest, which works until that person is on leave, moves on, or the business tries to hire someone new into the role. Michael Gerber's long-standing argument in The E-Myth Revisited, that small businesses stall not from a lack of technical skill but from a lack of documented systems, holds up as well now as when it was first published in 1995: a business that runs on undocumented knowledge cannot scale past the number of tasks its founder can personally remember or perform.

SOPs also protect against the specific failure mode of "it depends who you ask." Without a written procedure, three people will describe three slightly different versions of the same task, and none of them is definitively wrong, which means quality drifts with whoever happens to be doing the work that day. A written SOP removes the ambiguity: there is one current version, and a change to it is a deliberate decision, not an accident of someone forgetting a step.

It is worth being clear about what an SOP is not, because the terms get used loosely and that causes teams to write the wrong document. A policy sets a rule ("refunds are issued within 14 days"); it does not say how a person actually processes one. A work instruction is even narrower than an SOP, a single sub-step aimed at one tool, such as how to raise a refund inside a specific payment platform. An SOP sits between the two: specific enough to follow without guessing, general enough to survive a minor change in tooling.

How it works. What a usable SOP actually contains.

A working SOP has four parts, and little else:

• Purpose and trigger: one line on what the task achieves and what starts it, for example "a new client signs a contract."
• Owner: the role responsible for the task, not necessarily a named individual, so the document survives staff changes.
• Numbered steps: the actual sequence, written as instructions ("open the CRM record and set stage to Onboarding"), not descriptions ("the record is updated").
• Definition of done: the observable end state, so anyone can check whether the task was actually completed correctly, not just attempted.

Keep the format plain: a shared document or a single page in a wiki works better than a polished PDF, because SOPs need to be edited constantly in a business's first few years, and a format that is painful to update quietly stops getting updated. Store them somewhere the person doing the task will actually open, next to the tool the task happens in wherever possible, rather than in a folder nobody remembers exists three months after it was created.

The most common mistake is writing the steps too vaguely to actually follow, using phrases like "review the client's requirements" instead of naming what to check and where. A useful test before publishing any SOP: hand it to someone who has never done the task, watch them attempt it using only the document, and note every point where they hesitate or ask a question. Each hesitation marks a step that needs to be more specific, not a sign the reader was not paying attention.

A practical example. Writing one for client onboarding.

Take a common first SOP: what happens the moment a new client signs. The trigger is the signed contract landing in the founder's inbox. The owner is whoever runs client operations, even in a two-person business where that is also the founder. The steps might read: create the CRM record and set the stage to Onboarding, send the welcome email with the kickoff call link within one business day, add the client to the relevant shared folder, and confirm the first invoice has been raised. Done means the client has received the welcome email, the kickoff call is booked, and the CRM record shows the correct stage, all within 48 hours of signature.

Written like that, the task no longer depends on the founder remembering to do it personally, or remembering every step if someone else does it. It also becomes visible where the process breaks: if clients keep complaining about a slow first response, the SOP shows exactly which step is being missed or delayed, rather than leaving the team guessing at a vague sense that "onboarding feels slow." For the fuller model of mapping a task before writing the SOP for it, see our approach to process mapping, and for the practical step of turning this kind of documentation into a full operating manual, building standard operating procedures covers what a complete set looks like across a business.