7 sections for an SOP a new colleague can follow

A usable standard operating procedure tells a colleague when to use it, what they need, what to do and how to recognise completion. Write for the person performing the task, then test the instructions with someone who did not draft them.

This structure suits routine business processes. Specialised, regulated or safety-critical work may need additional expert review and controls. Do not use a general writing checklist as authority to perform work outside your role or training.

1. Purpose and scope

State the task the procedure covers and the situation that triggers it. Identify important exclusions so readers do not apply it to a different case. A clear scope prevents a routine process from being used for an exception it was never designed to handle.

For example, an SOP for updating a mailing address might exclude bank-detail changes, which need a separate approved process. Keep the purpose practical. A long history of the department is rarely necessary before the reader can understand the task.

2. Owner, version and effective date

Identify who is responsible for the procedure, which version is current and when it applies. Explain where the approved copy is kept. This helps readers distinguish an authorised instruction from a draft or saved attachment.

Use a simple change note when the procedure is revised. Do not label a file final without a way to tell whether it has been superseded. The owner should be able to explain how changes are reviewed and communicated to people who use the process.

3. Prerequisites and permitted access

List the information, approvals and access needed before starting. Put these before the action steps so the reader does not discover a missing requirement halfway through. Link to approved request routes where appropriate.

Do not include shared passwords or instructions to bypass access controls. If a prerequisite is unavailable, say what the reader should do next. For a practice example, a report procedure might require the confirmed reporting period and access to the approved source file.

4. Actions in the order they occur

Write observable steps using clear verbs. Separate decisions from actions and explain meaningful branches. Avoid vague instructions such as process as normal or check everything.

Where a screenshot helps, make sure it matches the current interface and contains no private information. Do not let screenshots replace essential wording. A reader should understand what to do even if the visual layout changes slightly. Keep optional background separate from the main sequence so the task remains easy to follow.

5. Checks before moving on

Add checks at points where an error would affect later work. State what a satisfactory result looks like. For example: “Confirm that the report period matches the request before sending the draft.”

Avoid instructions that merely say ensure accuracy without explaining the relevant check. Choose checks that address real failure points rather than adding signatures to every step. If a result is unexpected, direct the reader to the exception route instead of encouraging them to continue and hope the issue resolves itself.

6. Exceptions and escalation

Describe common exceptions and who can decide what happens next. Distinguish actions the reader may take from those requiring approval. Include how to record an unresolved issue so the next person can understand it.

Do not attempt to list every imaginable scenario. Cover known important exceptions and provide a clear route for unfamiliar ones. Avoid instructing readers to improvise specialist decisions. The procedure should make uncertainty manageable, not create false confidence that every case fits the normal path.

7. Completion and record location

State what marks the task complete and where the approved result or record belongs. Identify any handover or notification required. A task is not necessarily complete when the final screen is closed.

Test whether a colleague can locate the result and understand its status. Keep records according to the applicable organisational and legal requirements rather than inventing a universal retention period. If the procedure creates sensitive information, ensure its storage and access are reviewed through the appropriate process.

Test the SOP before relying on it

Ask a suitable colleague to follow the procedure using a permitted example. Observe where they need clarification. Check whether they can identify the starting conditions, complete the steps and recognise an exception. Revise the instructions and obtain the required approval before release.

Hypothetical finding: the tester reaches step four but does not know which report period to use. The revision moves that requirement into prerequisites and adds a confirmation check. This is more useful than adding a general reminder to be careful.

How long should an SOP be?

Long enough to support the task safely and clearly. Remove background that does not help the reader act or decide.

Can an SOP replace training?

It can support training, but some tasks require demonstration, supervised practice or specialist competence.

For maintaining the approved version, see HR document version controls.