SOP Documentation
SOP documentation: procedures a team can follow
SOP documentation turns work that lives in people's heads into procedures someone else can run: which processes to write first, what a usable procedure contains, how it is drafted with the person doing the work, and how it is kept current. Deliverables and scope are agreed in writing before drafting starts.
What an SOP is here
A short, owned, testable description of how one process runs: its purpose, its trigger, the steps in order, the decisions and exceptions inside it, where the record ends up, and when it is next reviewed. It is written in the team’s own vocabulary rather than in policy language, because the goal is use rather than audit.
This scope does not reproduce a certification framework or impose a documentation standard from outside. The structure above is the minimum that makes a procedure usable; anything beyond it is added only where your business genuinely needs it.
The guide on writing SOPs people actually follow covers what a usable procedure contains and how to test it with someone new.
What a usable procedure contains
01 · Purpose
What the procedure is for
One sentence naming the outcome the procedure produces and who it is written for. If the purpose cannot be stated in a sentence, the process may be two processes.
02 · Owner & trigger
Owner and trigger
The role accountable for keeping it current, and the event that starts it — a signed agreement, an inbound request, a scheduled date. Not a person's name; a role, so it survives staff changes.
03 · Steps
Steps in order, with the decisions marked
What happens, in sequence, in the vocabulary the team already uses. Decision points are shown as decisions, with the criteria for each route, rather than buried in a paragraph.
04 · Exceptions
Exceptions and escalation
The cases where the normal path does not apply, and who to escalate to when it happens. Exceptions are where undocumented processes cause the most rework, so they get written down rather than left to judgement.
05 · Review
Review date and change history
When it is next checked, who checks it, and what changed last time. A procedure without a review date quietly becomes wrong.
06 · Evidence
What good looks like
Where the record ends up and what a completed instance contains, so the procedure can be checked without asking the person who did it.
How the documentation is written
01 · Select
Choose what to document first
Candidates are the processes that are repeated, that a new hire has to learn, that carry risk when done wrong, or that only one person can currently run.
02 · Observe
Observe the work
The procedure is drafted from watching and asking, not from a template or from the way it was described in a meeting.
03 · Draft
Draft with the owner
The person who does the work reviews the draft. Anything they would not follow is either wrong or an unnecessary step.
04 · Test
Test it on a real instance
Someone else runs the procedure against live work while it is being written. Where they get stuck, the document is corrected.
05 · Publish
Publish and place it
Stored where the work happens — the same system, folder, or tool — with an owner and a review date attached.
06 · Maintain
Set the review rhythm
A schedule for review, and a rule for who may change a procedure and how the change is recorded.
What has to be settled first
Documentation cannot fix an undecided process. Where two teams run the same work differently because nobody has decided which is correct, writing both down makes the disagreement permanent. In those cases the process is settled first — ownership, sequence, and decision rights — and documentation follows. That work sits in the operational consulting scope, and where both are needed they are scoped together and quoted separately.
When SOP documentation fits
A fit when
- Knowledge of a key process sits with one or two people.
- New hires take longer than they should to become productive.
- The same process runs differently depending on who picks it up.
- An internal owner exists who will keep the documents current.
Not the right scope when
- The process has not been agreed yet — settle ownership and sequence first.
- You need a compliance certification pack rather than operating procedures.
- Nobody inside the business will own review, in which case the documents will age immediately.
- The real problem is a system that will not let the process run as designed.
Related operations scopes
Scope SOP documentation
Tell us which process only you can run
The clearest starting point is the process the business could not absorb losing. Describe it and we will say how many procedures it becomes and what the scope would cover.
SOP documentation: common questions
Which processes should be documented first?
Those where undocumented knowledge carries the most risk: work that only one person can run, work a new hire must learn quickly, work that recurs on a predictable rhythm, and work where a mistake has a real cost. A useful starting set is the processes a new starter needs in their first weeks plus the ones the business could not absorb losing.
How long should an SOP be?
As long as it takes to run the process and no longer. A procedure someone can follow in one sitting is more likely to be used than a manual nobody opens; where a process is genuinely large, it is split into procedures with a clear parent.
Do you write the SOPs, or do we?
We draft them with the person who does the work, and they own the final version. A procedure written without the operator present describes an imagined process; a procedure written only by the operator tends to leave out the steps that feel obvious.
Where do the documents live?
Where the work already happens, wherever that is sensible — an internal wiki, a shared drive, or attached to the system the process runs in. The document is placed with its owner and review date rather than in a folder nobody revisits.
What does SOP documentation cost?
A scoped quote based on the number of processes, how many roles each touches, and how much of the process has to be established before it can be written. It is quoted in writing before work starts; no per-document rate is published.
Does documentation replace training?
No. Documentation is the reference; training is what makes the first run of a process correct. Where a process is new or changing hands, documentation is paired with a walkthrough, and CRM-specific training is scoped separately.
Keep reading
Related resources
Sales Leadership
What a Fractional Sales Leader Does and When to Hire One
What a fractional sales leader actually owns, the signals that you need one, 30/60/90-day expectations, and how to tell whether it is a fit.
Read resourceProcess
How to Build a Repeatable B2B Sales Process
Define the stages every deal moves through, the exit criteria at each one, who owns it, and what to measure — with a worked example.
Read resourceOperations Leadership
What a Fractional COO Does and When to Hire One
What a fractional chief operating officer owns, the signals operations have outgrown the founder, and how the role differs from a consultant or a full-time hire.
Read resourceStart the Conversation
Bring us the opportunity, challenge, or next step. We'll start by understanding where you are, where you want to go, and what it will take to get there.