SOPs · 4 min read
How to write an SOP: steps and a worked example
By 1explain · Updated
An SOP, or standard operating procedure, describes how a recurring process should be carried out. It gives people a shared starting point, a sequence to follow, and a way to tell whether the work is complete.
This 2026 guide uses an example: handing off a customer request to another teammate. You can apply the same writing method to onboarding, routine administration, and other repeatable work. Adapt the actual rules to your team rather than copying someone else’s process.
In this guide
Decide what belongs in the SOP
An SOP explains when a process applies, who owns it, what happens, and how completion is checked. Detailed work instructions can sit underneath it and explain a particular action, such as updating a field in a tool.
Keep the scope narrow enough to test. ‘Handle all customer requests’ hides too many branches. ‘Hand off an unresolved request at the end of a shift’ has a clear trigger and result. If a branch takes a different owner or a substantially different sequence, give it its own procedure.
Capture what the team actually does
Walk through a real, suitable example with the person who does the work. Ask what starts the task, what information they need, what they check, and what usually goes wrong. Notes, a screen recording, or a spoken explanation can help capture details that are easy to miss from memory.
Separate current practice from proposed improvements. If two people follow different rules, resolve the difference with the process owner before publishing a single official procedure. Writing the disagreement more neatly does not resolve it.
Worked example: hand off an unresolved request
Use this example as a writing model. Names, roles, deadlines, and systems must match your own workflow before anyone follows it.
Purpose: Make the next action and owner clear before a shift ends. Applies when: A request is still open and the current owner is leaving. Owner: Support team lead. Before you start: Open the request and confirm the next available teammate. 1. Add a note summarizing the request, actions already taken, and the next action needed. 2. Include links to the relevant records. Keep sensitive information in its approved system. 3. Assign the request to the teammate who has agreed to take it. 4. Ask the new owner to acknowledge the handoff in the request. 5. Confirm the request shows the new owner and the next action. If no teammate is available: Contact the shift lead using the team’s agreed way to ask for help. Complete when: A new owner has acknowledged the handoff and can identify the next action. Review: [Named owner] checks this procedure when the handoff process changes.
Make exceptions visible at the point of need
A process that only describes the easiest case leaves the reader stranded when something differs. Put an exception beside the step it affects: what condition to look for, what to do next, and who can decide if it is unclear.
Avoid vague fallbacks such as ‘escalate if necessary.’ Name the role and the condition. In the handoff example, an unacknowledged assignment is not a completed handoff. The final check protects the outcome rather than merely checking that someone clicked Assign.
Review, publish, and keep one reference version
Have the process owner check the rules, then ask a teammate to run the procedure on a suitable example. Record any decision they had to guess. Update those points and repeat the test until the final check is clear.
Put the owner and review date near the procedure. Share a reference link so people can return to the current instructions instead of circulating disconnected copies. When a tool label or responsibility changes, update the affected step and tell the people who use it.
You can write and share the action sequence in 1explain. If your organization requires formal approvals or revision records, keep those in its approved system; a shared guide by itself does not establish that approval.