Most SOPs fail for the same reason. The expert writes them from memory, for readers who already know the task. The steps below fix both problems: you write from a real run, and you test on someone new.
The method works the same for an insurance agency endorsement, a medical office eligibility check, an accounting firm's month-end reconciliation, or a trucking office's carrier setup.
What are the steps to write an SOP?
- Pick one task and define its boundaries. Choose a task that repeats and has a clear start and finish, such as "issue a certificate of insurance" rather than "account servicing." Write one sentence for what starts it (the trigger) and one for what done looks like. If you cannot write both sentences, the task is too big, so split it.
- Name the owner and the reader. The owner is the person or role who keeps the SOP accurate; "the team" is not an owner. The reader is the least experienced person who will use it, usually a new hire doing the task alone for the first time. Write for that reader, not for the expert.
- Capture a real run. Watch or record the task being done on a real request, not a demo, and note every action and every point where the person paused to decide. Memory skips the steps that have become automatic, and those are the steps a new person misses. Notes and screenshots by hand work; so does a recording tool.
- Write each step as an instruction. Start each step with a verb, keep it to one action, and name the exact field, button, or document as it appears on screen. Add a short reason wherever a step would otherwise look optional. If a step changes something, say what the reader should see next.
- Document the decision points. At every place the path branches, write the question, the options, when each option is right, and what a wrong choice costs. Use the choice made in the real run as the worked example. This is the part a click-by-click record leaves out, and the part a new hire needs most.
- Add exceptions and a completion check. List the cases the normal path does not cover and where each one goes: another SOP, a person, or a stop. End with a check the reader can run to confirm the task was done right, such as "the request and the confirmation are both saved to the client record."
- Test it with someone who has never done the task. Have them do a real one using only the SOP while you watch and stay quiet. Every question they ask and every place they hesitate is a missing or unclear line. Fix it and test again until they finish without asking.
- Publish it where people look mid-task. Put the SOP where the work happens: linked from the system, in the shared folder the team already opens, or pinned where the team asks questions. A procedure people cannot find while doing the task might as well not exist.
- Set a review trigger. Write down what forces a review: a system update, a new form, a carrier or payer rule change, a repeated question, or an error traced to the SOP. Name the owner who does the review and record each real change in the revision history.
How do you capture a real run without starting from a blank page?
Sit with the person who does the task and have them handle a real request while you take notes. Ask them to say out loud what they are checking, not just what they are clicking. Capture four things:
- The trigger: the email, call, form, or queue item that started the task.
- Every system they open, in order, including the ones they forget to mention: a spreadsheet, an email thread, a sticky note.
- Every pause. A pause usually means a decision. Ask what they were deciding and how.
- Every outside check, such as asking a coworker or looking up a carrier's rule. That is where the undocumented knowledge lives.
If you cannot sit with them, a screen recording plus a short follow-up conversation covers most of it. Record a real request, not a clean demo; demos skip the branches.
One option for browser-based work is SopWow. It is a browser extension for Chrome and Edge that rides along while the person does the task normally. It captures which buttons, fields, and pages were used rather than the values typed, asks about the decisions a recording cannot explain, and flags anything its AI added until a person approves the SOP. It does not capture desktop applications or paper steps, so add those by hand. The trade-offs are laid out in writing SOPs by hand versus drafting them from a recording.
How do you write a step someone can follow?
A good step has five qualities.
- It starts with an imperative verb. "Open," "Select," "Confirm," "Save." Not "The user should" and not "Endorsements are processed."
- It holds one action. "Open the client record, check the policy dates, and add the endorsement" is three steps. Splitting them lets the reader check each one off and find their place after an interruption.
- It names things exactly as they appear. If the button says Add driver, write Add driver, in bold. Do not write "the add button."
- It explains why when a step looks skippable. "Save the bank statement to the client folder before reconciling. If a figure is questioned later, the reviewer needs the statement it came from."
- It says what should happen next. "The status changes to Pending." Readers use that confirmation to know they are on track.
Here is the difference on a real task, adding a driver to a personal auto policy at an insurance agency.
A weak step says:
Update the driver info in the system and send to carrier.
A usable version says:
1. In the client record, open the Drivers tab and click Add driver. 2. Enter the name, date of birth, and license number from the written request, not from memory or a phone note. 3. Select the driver's relationship to the named insured. The carrier uses it to decide whether the driver must be listed.
The second version is longer and faster to follow. Nobody has to guess.
How do you handle branches and decisions?
For every branch, write four things: the question, the options, the rule for choosing, and the cost of choosing wrong. Then note which option the real run took, as a worked example.
With two options, an inline "If, then" works. A medical office example: "If the plan shows inactive, call the patient before the visit. If it shows active, save the result and mark the visit verified."
With three or more options, or a choice that depends on more than one input, use a decision table. A trucking office handling carrier updates might write:
| Situation | What to do | Why |
|---|---|---|
| New carrier | Follow the full carrier setup SOP | Nothing is on file to compare against |
| Returning carrier, same payment details | Update the insurance certificate on file | Coverage lapses are the usual gap |
| Existing carrier asks to change bank or remit-to details | Call the carrier at the phone number already on file, not one in the request, before changing anything | Payment detail changes are a known route for fraud |
- New carrier
- What to do
- Follow the full carrier setup SOP
- Why
- Nothing is on file to compare against
- Returning carrier, same payment details
- What to do
- Update the insurance certificate on file
- Why
- Coverage lapses are the usual gap
- Existing carrier asks to change bank or remit-to details
- What to do
- Call the carrier at the phone number already on file, not one in the request, before changing anything
- Why
- Payment detail changes are a known route for fraud
If one branch has several steps of its own, give it its own SOP and link to it. An SOP with branches inside branches is hard to follow and harder to keep current.
How should you handle screenshots and redaction?
Screenshots help the reader find things. They should not carry the instruction. The text of each step should work on its own, with the screenshot showing where to look.
- Crop to what matters and highlight the one control the step refers to.
- Use a test or sample record if the system has one, so there is less real data to hide.
- Redact before publishing: client names, policy and account numbers, Social Security numbers, dates of birth, addresses, and anything else that identifies a person. Use a solid box, not a light blur.
- Check the whole image, not just the form. Browser tabs, notification pop-ups, recent-client sidebars, and email previews all leak data.
- Retake screenshots when the screen changes. A screenshot that no longer matches the system teaches readers to distrust the text next to it.
Redacting screenshots is good practice, but it does not by itself make a document compliant with any privacy rule. Check your own obligations for the data your team handles.
What are the most common SOP writing mistakes?
- Writing from memory. The expert's memory skips the automatic steps. Capture a real run.
- Writing for the expert. If the SOP assumes the reader knows the system, it will not survive a new hire.
- Documenting clicks instead of decisions. A list of clicks describes one run. The reader needs to know how to handle the next one, which may go differently.
- One SOP for a whole job. "Commercial lines servicing" is a binder, not an SOP. Split it into tasks.
- Vague verbs. "Process," "handle," "as needed," "if appropriate," and "per usual" are placeholders for knowledge that never got written down.
- No owner. An SOP without an owner starts going stale the day it is published.
- Skipping the test. The test with a new person is the step that turns a draft into an SOP. It is also the step most often skipped.
- Filing it where nobody looks. A perfect SOP in a folder nobody opens has the same effect as no SOP.
For the habits that keep SOPs useful after they are written, see SOP best practices for procedures people follow. If you want a structure to fill in, the free SOP template already has fields for the trigger, decision points, exceptions, and completion check.
Frequently asked questions
How long does it take to write an SOP?
It depends on the task's length and how many decisions it has. Typing the steps is rarely the slow part. Capturing a real run, working out the decision rules with the expert, and testing with a new person take most of the time, and they are the parts that make the SOP work.
Should the expert write the SOP?
The expert should supply the knowledge, but not work alone. Experts skip the steps they do on autopilot and assume context a new person lacks. The best results come from the expert doing the task, someone else capturing it, and a newcomer testing it.
Do I need special software to write an SOP?
No. A word processor, a shared document, or a wiki works, especially with a template. Software helps with capture (recording the run so nobody has to take notes) and with upkeep (finding and updating SOPs when a system changes). Choose based on where your team will actually look for the SOP.
How detailed should an SOP be?
Detailed enough that the newest reader can finish the task without asking anyone, and no more. Name every field and button the reader has to find. Skip actions nobody gets wrong, like "move the mouse to the menu." Put the detail where the decisions are.
Can you write an SOP for work that is not on a computer?
Yes. The method is the same: capture a real run, write one action per step, document the decisions, and test with someone new. For physical tasks, photos usually replace screenshots, and the completion check is often something the reader can see, such as a signed form in the right tray.
Ready to write your first SOP?
Start from the template, or record the task once in your browser and let SopWow draft it for your review.