SOP Development
A standard operating procedure is finished when someone who has never done the task completes it unaided. That is the acceptance test we run, with a person new to the task, and every point at which they stop is a defect we fix before sign-off.
Procedures someone new could actually follow
Most SOPs are written by the person who knows the task best, which is precisely why they fail. Expertise makes steps invisible: the field you always tab past, the value that is obvious, the check you do without thinking. The document is complete to its author and full of holes to everyone else.
So the acceptance test is not review by a subject-matter expert. It is a person who has not done the task following the document while we watch. Where they hesitate, ask a question, or get it wrong, the procedure has a defect, and we fix it before sign-off.
That test also reveals when the problem is not the document. If a task needs eleven screens because nobody ever simplified the configuration, a well-written SOP produces accurate, slow work — and we will say so.
What SOP development covers
Six workstreams, with the usability test as the gate.
Task inventory and prioritisation
Which procedures are needed, ranked by how often the task is performed, how many people perform it, and what the cost of doing it wrong is.
Procedures to a house template
A consistent structure — purpose, scope, roles, prerequisites, steps, exceptions, escalation — so that a reader knows where to look regardless of which SOP they open.
System steps from your configuration
Screenshots and steps captured from your own system with your master data and naming, because generic screens produce readers who cannot find the field.
Roles, RACI and escalation
Who performs, who approves, who is consulted, and who to contact when the procedure does not cover the situation — named by role rather than by individual.
Usability test
A person new to the task attempts it using only the document, observed. Every hesitation is recorded as a defect and corrected before sign-off.
Ownership and review cadence
A named owner and a review date per procedure, because an SOP without either is trusted for exactly as long as it takes for something to change.
How an SOP engagement runs
Prioritise tasks
Procedures ranked by frequency, population and cost of error, so effort goes where it returns rather than spreading evenly.
Capture and draft
Steps captured from your configured system with real data, drafted to the house template with exceptions included.
Test with a newcomer
Someone who has never done the task follows the document unaided while observed, with every stopping point recorded.
Correct and sign off
Defects fixed, the test repeated where the changes were substantial, then sign-off by the process owner.
Assign and schedule
Owner named and review date set per procedure, with version control in your own tooling.
How SOPs are usually validated
Why the validation method determines whether the document works.
| Validation method | Catches | Misses | Confidence |
|---|---|---|---|
| Author review | Typos | Every invisible step | Low |
| Expert review | Technical errors | Assumed knowledge | Low to moderate |
| Peer review | Structural issues | What experts share | Moderate |
| Newcomer observed attempt | Assumed knowledge, gaps, ordering | Rare edge cases | High |
| Live use over months | Everything, eventually | Nothing | Highest, and slowest |
What an SOP cannot carry
An SOP cannot substitute for judgement. Where a task genuinely requires weighing an unusual situation, the honest procedure documents the decision framework and names who to escalate to, rather than pretending the judgement can be reduced to steps. Over-specified procedures for judgement tasks get ignored, which then discredits the ones that matter.
Nor can an SOP fix a process nobody agreed to. If two departments dispute who approves a purchase over a threshold, writing one version down does not settle it. That belongs in process documentation and a decision, and we will pause and ask for it rather than encoding one side’s view.
- The author is the worst possible validator; expertise makes steps invisible.
- Test with someone new to the task, observed, and treat every hesitation as a defect.
- Capture screens from your own configuration, with your master data and naming.
- Name an owner and a review date, or the SOP is trusted only until something changes.
Questions buyers ask about this
How do you know the SOP is good enough?
Someone who has never done the task follows it unaided while we observe. Every place they stop, hesitate or ask a question is a defect, and we fix it before sign-off. Expert review does not find these, because the whole difficulty is the knowledge experts do not know they are assuming.
Can you cover SAP transactions?
Yes, captured from your client with your master data, so screens, field names and document types match what the user will actually see. Generic SAP screenshots produce readers who cannot locate the field being described, which is the most common failure in inherited SAP documentation.
How many SOPs do we need?
Fewer than most organisations attempt. We prioritise by task frequency, how many people perform it, and the cost of getting it wrong. A comprehensive library that nobody maintains is worth less than fifteen procedures that are current, owned and tested.
What if the task requires judgement?
Then the procedure documents the decision framework, the factors to weigh, and who to escalate to — rather than pretending judgement reduces to steps. Over-specifying a judgement task produces a document practitioners ignore, and that habit spreads to the procedures that genuinely are prescriptive.
Who should own SOPs after handover?
The process owner, by role rather than by name, with a review date per procedure. We set both at handover. Documentation owned by "the team" is owned by nobody, and it is stale within two quarters.
Marked up as FAQPage structured data, matching the visible text exactly.
Still not sure this is the right service?
Answer four questions and we will tell you which one fits — or that none of them do.
Tell us what you are trying to fix.
A short conversation about the objective, the constraints and the timing. If we are not the right fit, we will say so.