How to create an SOP
Write the procedure the second time you find yourself explaining the same task to somebody, while you still remember which parts they misunderstood. Keep it short enough to read while doing the work, be specific about what finished means, and name the step people get wrong. Then correct it the first time reality disagrees with it.
Write it from the work, not from the idea of the work
Procedures written in advance describe an imagined version of a task and tend to be wrong exactly where it matters, because the awkward parts are invisible until somebody hits them. Writing it while doing it, or immediately after explaining it, captures the decisions rather than only the steps.
Define done
Most procedures describe actions and leave the finish line implied, which is where quality quietly varies. State what a correctly finished job looks like — what has been checked, what has been recorded, what the customer has received — so that two people can agree on whether it happened.
Name the step that goes wrong
Every recurring task has one. Calling it out explicitly, with what happens if it is skipped, does more for consistency than the other steps combined, and it is the part that gets left out when somebody writes the procedure to be complete rather than to be useful.
Keep it alive
A procedure that is wrong is worse than none, because it is followed. Fix it the first time it does not match reality, and treat the correction as a normal part of the work rather than an admission that the original was bad.
Common questions
How long should an SOP be?
Short enough to read while doing the task. If it will not fit on a page, it is probably two procedures that have been written as one.
Who should write it?
Whoever does the task, not whoever manages it. The person doing it knows where it actually goes wrong, which is the valuable half.
How many do I need?
Start with the tasks that go wrong when a particular person is away. That list is short and it is the one that pays back immediately.