Most ignored SOPs are not wrong. They are just less convenient than asking the person at the next desk. Every practice below is about closing that gap, so the document becomes the faster answer.
The examples come from insurance agencies, medical offices, accounting firms, and trucking offices, but the practices apply to any back office.
What should an SOP actually say?
1. Write decisions, not clicks
A list of clicks describes one run of a task. The next run will be different: a different client, a different answer on a form, a request the last one did not include. What a reader needs is the rule for each choice.
Compare two versions of the same step in an insurance agency's certificate process:
- Click version: "Check the Additional Insured box."
- Decision version: "Check Additional Insured only if the policy carries an additional insured endorsement for this holder. If it does not, stop and start the endorsement SOP. A certificate cannot add coverage the policy lacks."
The first is a record. The second is a procedure. For every question, toggle, or dropdown, write when each option is right and what a wrong choice costs.
Recording tools make the click path cheap to capture. SopWow, for example, asks about each branch point after a recording and writes the rule into the step, but a person still confirms the rule is right before the SOP is approved.
2. Write for the newest person
Write for the least experienced person who will ever do the task alone. The expert does not need the SOP. The new hire, the temp covering a leave, and the coworker from another team all do.
In practice, that means naming screens and buttons exactly as they appear, spelling out abbreviations the first time, and never assuming the reader knows which system to open. A medical office SOP that says "check elig in the portal" works for the person who wrote it. "Open the payer portal and search the member by ID and date of birth" works for everyone.
3. Explain the why
One short reason attached to a step does two things. It stops people from skipping steps that look optional, and it lets them handle cases the SOP did not anticipate.
"Save the bank statement to the client folder before reconciling" gets skipped when the team is busy. "Save the bank statement to the client folder before reconciling, because the reviewer needs the source if a figure is questioned" gets followed. The reason also helps the next person who edits the SOP understand what they must not remove.
How big should an SOP be, and who owns it?
4. One task per SOP
An SOP covers one task with a clear trigger and a clear finish. "Add a driver to a personal auto policy" is a task. "Personal lines servicing" is a job made of dozens of tasks.
One task per SOP keeps documents short enough to use mid-task, lets people find the one they need by title, and means a change to one task only touches one document. If an SOP has its own table of contents, it is probably several SOPs.
5. Name an owner
Every SOP needs a named owner: one person or role responsible for keeping it accurate. "The team" and "operations" are not owners.
The owner does not have to write every change. They approve changes, answer questions about the task, and notice when the SOP has drifted from how the work is actually done. When an owner leaves, reassign their SOPs before they go, the same way you reassign their accounts.
In a small office, the owner is often the person who does the task most. That works, as long as someone else has tested the SOP, so the owner is not the only person who can follow it.
Where should SOPs live, and what should they show?
6. Put SOPs where the work happens
People look for help in the middle of a task, in the place where they are working. An SOP three folders deep in a shared drive loses to a question shouted across the office.
Link SOPs from the system itself where you can, keep them in the folder or wiki the team already opens every day, and use titles that match how people describe the task. A trucking office's billing clerk searches "rate confirmation mismatch," not "Accounts Receivable Procedure 4."
Format matters here too. A written SOP can be scanned and searched mid-task; a long video has to be scrubbed through. For how each works for training and reference, see video walkthroughs versus written SOPs.
7. Keep screenshots honest and redacted
A screenshot that no longer matches the screen teaches readers that the whole SOP is out of date. Retake screenshots when the system changes, and cut ones that only show what the text already says clearly.
Every screenshot also needs a redaction check before publishing. Look past the form in the middle: client names in tabs, recent-record sidebars, email previews, and pop-ups all show up in captures. Use a test record where the system allows one. Redaction is a practice, not a guarantee, so a person should look at every image before it is shared.
How do you keep SOPs trusted over time?
8. Version and date only real changes
A revision history is useful only if each entry means something. Record a new version when the way the task is done changes: a new step, a new decision rule, a new exception. Fixing a typo is not a new version.
Each entry should say what changed and who approved it. "Added the two-plan exception. Approved by the office manager" tells the next reader something. A date that updates every time someone opens and saves the file tells them nothing, and teaches them to ignore dates entirely.
When a change affects how the work is done, tell the people who do the task. A silent update only helps the people who happen to reread the SOP.
9. Review on triggers, not calendars
An annual review catches changes months after they happened. Tie reviews to the events that actually make an SOP wrong:
- The system is updated or replaced.
- A form, carrier rule, payer rule, or client requirement changes.
- Someone asks the same question about the task twice.
- An error is traced back to the SOP.
- The owner leaves or changes roles.
A calendar review is a reasonable backstop for SOPs nobody has touched in a long time. It should not be the main way changes get in.
10. Measure use, not word count
Word count, page count, and the number of SOPs in the library measure effort. They say nothing about whether anyone is helped.
Watch signals of use instead: whether the SOP gets opened, how many questions about the task still come to the expert, whether errors on the task go down, and whether a new hire can do the task alone from the document. If the questions keep coming, the SOP is missing something. Ask what, and add it.
One habit makes this easy. When someone asks the expert a question the SOP should have answered, the expert answers by pointing to the SOP and adding the missing line. The questions become the SOP's to-do list, and the expert gets asked less over time.
How do you audit an existing SOP?
Run this checklist against any SOP in your library. Each unchecked item is a specific fix.
- The title names one task and starts with a verb.
- The trigger says exactly what starts the task.
- A named person or role owns it, and that person still works here.
- The scope says what the SOP does not cover and where those cases go.
- Prerequisites list the access and information needed before step one.
- Every step starts with a verb and holds one action.
- Buttons, fields, and screens are named exactly as they appear.
- Every branch point states the options, the rule for choosing, and the cost of a wrong choice.
- Steps that look optional say why they matter.
- Exceptions are listed, each with a destination.
- A completion check tells the reader how to confirm the task was done right.
- Screenshots match the current system and have been checked for client data.
- The revision history records only real changes, with who approved each one.
- Review triggers are written down.
- Someone who had never done the task has followed it start to finish.
- It lives where people look while doing the task.
If you are rewriting from scratch, the step-by-step guide to writing an SOP covers the method, and the free SOP template has these parts built in.
Frequently asked questions
What is the most important SOP best practice?
Documenting decisions. Most SOPs that fail describe what to click but not how to choose, so readers stall at the first question the screen asks. Close behind is testing with someone who has never done the task, because that test finds the decisions the expert forgot to write down.
How many steps should an SOP have?
There is no right number. An SOP should have as many steps as one task needs, with one action per step. If the step count keeps growing, check whether the document covers more than one task, or whether a long branch should become its own SOP.
Should SOPs include screenshots?
Include them where they help the reader find something on screen, and make sure the step text works without them. Keep them current, crop them to what matters, and check every one for client data before publishing. A stale or unredacted screenshot does more harm than none.
How do you get people to actually follow SOPs?
Make the SOP the fastest way to get an answer. That means one task per document, titles people would search for, placement where the work happens, and decision rules that answer the real questions. When someone asks a question the SOP should have answered, update the SOP and point them to it.
Who should own an SOP?
The person or role closest to the task who has the authority to approve changes, usually a team lead or the most experienced person doing the work. The owner keeps it accurate, approves edits, and reviews it when a trigger fires. Reassign ownership whenever the owner leaves.
Ready to put these practices into your next SOP?
Start from the template, or record the task once in your browser and let SopWow draft it for your review.