How to write a standard operating procedure (SOP) people follow

A standard operating procedure is a shared answer to a recurring question: how do we do this job here? It is useful when somebody other than its author can complete the work correctly. A long document that nobody opens is not a better process than a short checklist that gets used.

Choose one task with a clear finish

Start with something repeated and bounded, such as processing a return, preparing a quote or closing a support request. Avoid writing an entire department's handbook first. Watch the person doing the job and record the actual decisions, including the awkward exceptions, rather than the process everyone assumes happens.

Trigger: what starts the task?
Owner: who is accountable for finishing it?
Inputs: which records and permissions are needed?
Done: what observable result marks completion?

Write actions, not vague instructions

'Check the order' leaves a new colleague guessing. 'Match the order number, item and purchase date against the customer record' describes something verifiable. Use a numbered sequence where order matters. Put screenshots or field names beside the step they explain, and keep sensitive customer information out of training examples.

Worked example: preparing a service quote

In a hypothetical repair business, the procedure starts when a customer provides the location, problem description and access requirements. The coordinator checks service coverage, asks for missing details and selects the applicable labour and materials assumptions. A qualified colleague reviews any unusual work before the quote is sent.

Record the scope and exclusions in plain language.
Name the person who can approve a nonstandard price.
Save the version sent and the agreed next-contact date.
Finish only when the customer has received the quote and ownership of follow-up is assigned.

Test the document without coaching

Give the draft to someone who knows the business but has not done this task. Ask them to use it on a safe example. When they have to ask a question, the document has found a missing input or decision. Fix the instruction instead of blaming the reader. Record which exceptions require escalation rather than pretending every case is identical.

Keep one current version

Assign an owner and a last-reviewed date. Review the SOP whenever a tool, policy or responsibility changes; a calendar reminder alone will not catch those events. Archive outdated copies and link to the current procedure from the place people start the work. Measure errors and rework before and after the change, not the number of pages written.