How to write a standard operating procedure people can follow
Dylan de Heer
To write a standard operating procedure, choose one repeatable process, define where it starts and finishes, and turn the work into ordered actions with clear conditions and expected results. Have someone other than the author try the draft, resolve the gaps they find, then approve and maintain one current version.
A useful SOP lets the intended reader complete the work without depending on the author to explain missing steps. A polished document is only an intermediate result. The stronger test is whether a colleague with the required skills and access can follow it, recognise an exception and know when the process is complete.
This guide focuses on everyday office processes, such as preparing a client review pack or handling an internal request. It includes a fictional worked example and a practical review method. Regulated, clinical, laboratory and safety-critical procedures require the relevant professional controls and approval; this article does not supply those controls.
What should a standard operating procedure contain?
An SOP describes an agreed way to carry out a recurring process. The level of detail depends on the audience, the consequences of an error and the organisation’s own documentation system. Use an existing approved structure if your organisation has one.
For an ordinary office workflow, a useful starting structure is:
Purpose and result: why the process exists and what successful completion produces.
Scope: the trigger, end point, included work and exclusions.
Roles and prerequisites: who acts, what access or knowledge they need, and the inputs required before starting.
Procedure: ordered actions, decision conditions and expected results.
Exceptions and escalation: what to do when the normal sequence cannot continue.
Completion record: what is saved and how someone can check the work is finished.
Document control: owner, reviewer or approver, version, status and review arrangements.
The authors of Ten simple rules on how to write a standard operating procedure discuss audience, detailed instructions, testing, review, approval and revision control. Their article concerns scientific work; the office examples below adapt those documentation principles rather than claiming a universal compliance standard.
1. Choose one process with a clear boundary
Start with a recurring task that people already perform or are about to pilot. Select work where inconsistent handoffs, repeated explanations or missing information cause a recognisable problem.
“Manage clients” is too broad. “Prepare the monthly client review pack from approved project updates” has a trigger, inputs and an output that a reader can inspect.
Write the boundary in a few sentences before drafting steps. For the fictional review-pack process:
Start: the account lead requests the monthly pack and confirms the review date. Finish: the approved pack is saved in the agreed client folder and its location is sent to the account lead. Excluded: changing commercial terms, approving project scope or sending the pack directly to the client.
This boundary prevents a routine preparation task from quietly acquiring decisions the preparer is not authorised to make. If the process regularly branches into unrelated work, link to a separate procedure rather than putting every possible task into one long document.
2. Identify the reader and prerequisites
Describe who will use the SOP and what they can reasonably be expected to know. A new team member and an experienced account manager may need different explanations. Avoid both unexplained shorthand and repeated instructions for skills the audience already possesses.
List the required inputs and access before the numbered procedure. In the review-pack example, the preparer needs the client name, review date, reporting period, approved project updates, the current pack layout and permission to use the relevant folder.
State what happens when a prerequisite is missing. “Get the project updates” leaves the reader guessing where to look and who can approve a substitute. Better: “Use the updates marked approved for the reporting period. If one is missing, ask the account lead whether to wait or proceed with a stated gap. Do not substitute an older update without approval.”
Include required software access by role rather than embedding credentials or private access links. A document that teaches the process should not become a collection of passwords or sensitive client information.
3. Walk through the real process before polishing it
Ask an experienced person to explain a recent ordinary case from trigger to completion. Follow with a case that did not proceed normally. The second conversation often exposes an approval, exception or decision that the routine explanation left implicit.
Useful questions include:
What tells you it is time to start?
Which input do you check first, and what makes it acceptable?
What do you do when two sources disagree?
Which decisions can you make yourself?
Where does work wait for another person?
What would make you stop and ask for help?
What do you save so the next person knows the task is complete?
Keep the current process separate from proposed improvements. If the expert says, “We normally ask the account lead, but we should automate that”, record the first as current practice and the second as a proposal. Do not silently turn an idea into an approved step.
If you capture the explanation in a recording, agree who can record, access and use it. Use synthetic or appropriately authorised examples where the real process contains private information.
4. Write actions, conditions and expected results
Write the first complete draft in the order the reader will perform the work. Begin each action with a concrete verb: check, open, compare, save, request or send. Name the object of the action and make the completion condition visible.
Compare these two instructions:
Too vague: “Check the review pack and follow up where needed.”
More usable: “Compare each project’s status in the draft pack with its approved update for the reporting period. If a status differs, correct the draft or ask the account lead to resolve the conflict before review. Keep unresolved items in the open-questions section.”
The second instruction explains the source, the check, the exception and what to do next. It avoids requiring the reader to infer what “check” means.
Use a short numbered sequence for work that happens in order. Put conditional instructions beside the step that triggers them. Where a decision has several outcomes, name each condition clearly and give each a next action. An arrow-filled diagram is only helpful if the reader can still tell which condition applies.
Avoid combining several independent actions into a single sentence. Conversely, do not split an obvious click sequence into dozens of fragments when that hides the purpose of the task. Match the detail to what the intended reader needs to perform and verify the work.
5. Add exceptions and stop conditions
An SOP needs to explain when the normal path should pause. Missing approval, conflicting source information and unavailable access are different problems and may need different owners.
For each important exception, state the condition, the next action and the boundary of the reader’s authority. “Ask your manager if anything is wrong” gives little help. “If a commercial change appears in a project update, flag it to the account lead and leave it out of the approved-results section until they confirm the wording” is more specific.
Do not invent a deadline or escalation contact to fill a blank. Mark it as unresolved in the draft and ask the process owner to decide. A visible unresolved decision is easier to review than a plausible instruction that nobody authorised.
Keep genuinely exceptional cases out of the main sequence when they would overwhelm routine work. A brief exception section can link to specialist guidance or an agreed contact. Make clear when the reader must stop rather than improvise.
A worked office example: preparing a client review pack
The following is a fictional procedure excerpt. Its roles and checks illustrate the writing method; they are not a claim about how a particular company operates.
Purpose: prepare a reviewable pack that accurately reflects approved project updates for one reporting period.
Owner: account lead. Preparer: assigned team member. Status: draft for walkthrough. Inputs: confirmed review date, reporting period, current pack layout and approved updates. End point: approved pack saved and its location shared internally with the account lead.
Confirm the request. Check the client name, review date and reporting period with the account lead. If any is missing, request clarification before drafting. The expected result is one agreed scope for the pack.
Collect the source updates. Open the approved update for each included project. Compare its reporting period with the request. If an update is absent or out of date, record the gap and ask the account lead how to proceed.
Create the draft. Use the current pack layout. Add each project’s approved status, completed work and open questions. Preserve the meaning of the source and identify unresolved conflicts rather than choosing an unsupported answer.
Check the draft against its sources. Confirm project names, reporting dates and any stated commitments. Remove private details that the intended audience is not authorised to receive. The draft should identify the source of each substantive project update.
Request review. Send the draft location and the list of unresolved questions to the account lead. Keep the pack marked as a draft until approval is explicit. If changes are requested, revise and return it for review.
Record completion. Save the approved version in the agreed client folder, using the organisation’s naming convention. Record the approval and send the location to the account lead. Direct client delivery remains outside this procedure.
Notice what this excerpt does not decide: it does not invent the folder, an approval deadline or a company-wide naming convention. Those need to be supplied and checked before the procedure can be approved for use.
6. Use AI to draft from the explanation, then verify it
A spoken walkthrough can be a useful drafting input. It still needs restructuring: a conversation can jump backwards, omit familiar steps or mix current practice with possible improvements.
Weeve’s SOP workflow can help turn a recorded explanation into a draft. Ask for ordered steps, prerequisites, decision conditions and unresolved questions, and require it to flag missing details. Weeve does not capture a sequence of screen clicks for this workflow; describe important interface actions in the explanation or add authorised screenshots separately.
Review the generated text against the recording and the process owner’s intent. Check negation, names, responsibilities and exceptions especially carefully. A missing “do not” can change an instruction, and a suggestion can be mistaken for an agreed rule.
The genuine app image uses demonstration content and shows how to open a generated document. It is not a validated SOP or evidence that the process has been tested.
Keep data handling appropriate to the content. Weeve supports local work with recordings; optional handoffs to external services such as ChatGPT or Claude can transfer relevant text when used. Review the material and your organisation’s rules before choosing an external route. The assistant’s draft remains an input to review, not an approval of the procedure.
7. Test the SOP with a colleague
Choose someone representative of the intended reader, with the prerequisites and access specified in the document. Use a safe sample case. Give them the draft and observe where they pause, ask for clarification or take a different path.
Avoid explaining each step as they go. If the author continually supplies missing context, the walkthrough is testing the author’s availability. Record each intervention and revise the document afterwards. Stop immediately if continuing could affect real customers, confidential data or other consequential work.
Ask the reader to show the result and explain why they consider the task complete. A person can follow every written action while producing an output that does not meet the process owner’s needs. Compare the result with the stated completion criteria.
Try a relevant exception as well as the ordinary path: a missing update, a conflicting date or an unavailable approver. Check that the reader knows how to pause and who can decide what happens next. The PLOS guidance likewise includes testing the procedure and using critical feedback before approval.
8. Approve and maintain one current version
Have the process owner and the appropriate reviewer resolve the walkthrough findings. Confirm who may approve the SOP under your organisation’s rules. Keep the document marked as a draft until that decision is recorded.
Include an identifier or clear title, version, owner, approval status and relevant dates. Keep a brief change record so a reader can distinguish a wording correction from a changed responsibility or process step. Store the current approved copy where the intended audience can find it and prevent obsolete copies from being mistaken for current instructions.
Set review arrangements around the process. Changes to tools, responsibilities, inputs or recurring exceptions can justify an earlier review than a calendar date. If a change alters the steps, run the affected path again and obtain the required approval.
Do not claim that a signed document proves the process works in every case. After adoption, look for recurring clarification requests, avoidable rework and exceptions the SOP does not handle. These observations can guide revisions; they do not become measured improvement claims without a baseline and evidence.
Fix common problems before approval
The draft is too long. Check whether it combines several processes, repeats reference material or gives unnecessary detail for its audience. Keep the main sequence visible and link to supporting instructions where useful.
Different experts describe different methods. Record the disagreement and ask the process owner to choose or define the conditions for each route. Do not blend incompatible methods into a procedure that no one actually follows.
The instructions become obsolete quickly. Identify whether the process changes frequently or whether the SOP contains fragile details such as individual names and temporary links. Maintain the detail the reader needs, and assign responsibility for reviewing it when the underlying system changes.
People still need the author’s help. Review the points where assistance was needed. Missing prerequisites, undefined terms and invisible completion criteria often need a specific revision. Adding more introductory prose rarely resolves an omitted decision.
Start with one bounded process, write what the intended reader must do and arrange a walkthrough before approval. The most useful next step is to observe someone using the draft and improve the instructions where their work exposes a gap.
