What Is a Standard Operating Procedure (SOP)? Examples and Writing Steps

Key takeaways

• An SOP describes the agreed method for recurring work, including its scope and responsibilities.
• Useful steps identify observable actions, decision criteria, and the evidence of completion.
• Exceptions need a defined route so staff do not have to invent a process when the normal path fails.
• Ownership, version control, training, and review keep the procedure aligned with the work.

A standard operating procedure, or SOP, is a written set of instructions for carrying out a recurring activity consistently. It describes when the procedure applies, who performs the work, the steps to follow, and the checks or records needed to establish the result.

Consider a support team receiving requests to add users to a customer workspace. One person accepts an email from a colleague, another asks the workspace owner, and a third copies the permissions of an existing user. Everyone completes the task, but they are making different decisions about authority and access.

An SOP can turn those decisions into an agreed process. Its value depends on whether that process is workable and whether staff can identify the situations it does not cover.

How an SOP Differs From a Policy or Checklist

A policy states a rule or expectation. For this workspace, a policy might say that additional access needs authorisation from the designated customer administrator. The SOP explains how support establishes that authorisation and carries out the request.

A checklist can provide a short reminder of important checks within the procedure. It may be sufficient for an experienced person doing familiar work, but it should not conceal decisions that require fuller instructions.

The EPA’s guidance on preparing SOPs provides a reference for documenting routine activities within a quality system. Its context is specific, but the underlying need is familiar: a repeatable task should have instructions that can be understood, followed, and maintained.

Set the Scope Before Writing Steps

State what starts the procedure and which cases it covers. For the support team, the trigger could be a request to invite a new user to an existing customer workspace. The scope might cover ordinary member access while directing administrator transfers and disputed ownership to another process.

Define completion as well. Sending an invitation may complete support’s task, while the recipient’s acceptance remains a separate state. Without that distinction, one employee may close the request immediately and another may keep it open indefinitely.

Identify the roles responsible for performing the task, approving exceptions, and maintaining the document. Use role names that remain meaningful when individuals change jobs, supported by an accessible way to find the current person filling each role.

Put Prerequisites Before the Work

List the access and information needed to begin. In this example, support needs the workspace identifier, the intended recipient, the requested role, evidence of the required authorisation, and access to the approved administration tool.

A missing prerequisite should have a defined consequence. If authorisation is absent, the request returns for clarification. Staff should not have to choose between guessing that the request is legitimate and leaving it unanswered.

Keep sensitive information out of unnecessary copies. A procedure can require recording that authorisation was checked and where the evidence is held without duplicating the entire conversation across several systems.

Write Steps With Visible Outcomes

Avoid instructions such as “check the request carefully” when the decision criteria can be stated. A practical illustrative sequence is:

1. Locate the workspace using its recorded identifier.
2. Confirm the requester is authorised under the organisation’s access policy.
3. Confirm the recipient and requested role match the authorised request.
4. Check whether the recipient already has access or a pending invitation.
5. Issue the invitation through the approved tool if the request is within scope.
6. Record the action, relevant reference, and any exception in the support record.
7. Notify the requester of the outcome and any remaining action.

The actual organisation must supply its authority rules and role definitions. This example shows how to connect actions with decisions without inventing universal access policy.

Some interfaces need detailed work instructions or screenshots. Keep those details where they help the person complete the task, and give them an owner so a changed button or screen does not make the procedure misleading.

Describe Exceptions at the Point They Occur

A normal-path procedure is incomplete if it leaves staff to improvise after a system error. Suppose the invitation request times out. The tool may have created the invitation without returning confirmation.

The next instruction should establish the current state before repeating the action. The employee might check the pending-invitation record, then escalate if the result remains uncertain. Automatically retrying every failure could send duplicate invitations or obscure what happened.

Other exceptions need their own routes:

Situation	Decision the procedure should specify
Requester cannot be verified	Who can resolve the authority question?
Recipient already has access	Should the request close or move to a role-change process?
Requested role is outside scope	Which role can review or approve it?
Administration tool is unavailable	Where is the work recorded while it waits?
Outcome cannot be confirmed	What evidence is checked before another attempt?

An SOP cannot enumerate every possible event. It can identify when the normal instructions no longer apply and who owns the next decision.

Keep Records Proportionate to the Task

The procedure describes intended work; a completed record describes what actually happened. For the invitation, that might include the workspace reference, requested role, authorisation reference, action time, outcome, and responsible staff member.

Record uncertainty honestly. “Invitation issued” and “request submitted; outcome awaiting confirmation” describe different states. The distinction helps the next person continue without repeating an action under a false assumption.

Where software provides a correlation identifier, it can help connect the support record with diagnostic events. It does not replace the business record or establish that the action was authorised.

Review the SOP With People Who Perform the Work

Ask a suitably trained colleague to walk through a representative case using the draft. Observe where they need clarification, lack access, or encounter a decision the document never explains.

The HSE’s guidance on procedures emphasises their usability and the importance of involving users in development. Procedures sit alongside competence, equipment, and other controls; a document alone cannot make an unworkable process dependable.

Use the walkthrough to improve both the instructions and the process. If every invitation needs the same undocumented exception, the normal path probably needs revision. Adding another warning paragraph will not resolve missing authority or unavailable tools.

Publish and Maintain the Current Version

Give the SOP an owner, version, effective date, and revision history. Follow the organisation’s approval arrangements, then make the current version easy to find. Historical versions should be distinguishable from instructions intended for today’s work.

Coordinate changes with access, training, and supporting forms. Staff cannot follow a new procedure on Monday if the required tool is unavailable until Wednesday.

Review after meaningful changes as well as at the organisation’s chosen intervals. A new workspace role, a revised approval policy, or an enhancement to the software can make existing instructions inaccurate.

A useful SOP leaves the support team with more than consistent wording. Staff know which requests they can handle, what evidence they need, and how to proceed when the outcome is uncertain. The document remains dependable because it changes when the work changes.

A procedure is useful when someone can follow it, recognise an exception, and explain what happened without relying on undocumented knowledge.