A standard operating procedure, or SOP, describes how to carry out a recurring activity. For everyday team work, its job is to make the next action, required input and completion check clear enough that a colleague does not have to reconstruct the process from scattered messages.
Start with one real activity and the people who perform it. An attractive template will not repair a process nobody agrees on. This guide focuses on routine administrative work, using a fictional request-intake process to show how an instruction becomes testable.
Choose the process boundary first
Write the event that starts the procedure and the condition that ends it. “Manage client requests” is too broad to be a useful boundary. “Record a new request, check that the brief is complete, and hand it to the assigned reviewer” is easier to describe and test.
List the normal input, the expected output and the person responsible for the handoff. An SOP does not have to cover every neighbouring process. It can link to the approved procedure for the next stage. This prevents a short working document from becoming an entire company handbook.
An SOP, checklist and policy have different jobs
A policy establishes a rule or expectation, a procedure describes the sequence for carrying it out, and a checklist helps someone confirm that necessary items were addressed. These are practical working distinctions for this guide. Your organisation may use different labels.
For example, a rule that only an authorised person can approve a request should not disappear when you simplify the procedure. The SOP explains when that approval is needed and how to ask for it. A final checklist confirms that the approval was actually recorded. If the rule is unclear, obtain an answer from the process owner instead of asking AI to invent one.
Use a structure that supports the next action
For a small routine process, begin with the purpose, scope, owner, inputs, steps, exceptions and completion check. Add a document identifier, version and review information so users can tell which copy applies. EPA guidance describes documenting recurring work and reviewing procedures with people who know the process; its environmental quality-system context should not be mistaken for a requirement on every business.
Write steps with a clear actor and a visible outcome. Compare “handle the request appropriately” with “the intake coordinator records the request identifier and checks that the brief includes the requested output and deadline.” The second sentence gives a tester something to observe. Use your actual field names and systems after verifying them with the people doing the work.
Describe the exception before someone has to improvise
Ask what happens when an input is missing, the assigned person is unavailable or the work falls outside the stated scope. Give the user a permitted next action and a named role to contact. “Stop and ask the process owner” can be a better instruction than a made-up fallback that creates an unauthorised commitment.
Keep the exception tied to its trigger. In the request-intake example, a missing deadline does not mean the coordinator promises a standard turnaround. It means they flag the missing field and ask the requester or reviewer for clarification. An SOP should make uncertainty visible before it becomes a promise to someone else.
Test the document with a realistic case
Give a colleague an ordinary example input and ask them to follow the draft using only the instructions and approved access. Record where they hesitate, which field they cannot find and what they interpret differently from you. Test an incomplete input as well as the straightforward case.
When you revise, fix the instruction or the underlying process rather than blaming the tester. Have the process owner confirm that the revised steps reflect permitted work. Store the current copy where the work happens and decide what event should trigger another review, such as a system change or a repeated exception. The fictional example below is a document exercise; it does not certify a live workflow.
Start with this workflow.
- Observe one bounded task
Gather the real inputs, outputs, responsibilities and rules from the people who carry out the process.
- Write steps and exception routes
Give each action an actor, required information and visible completion check.
- Test, approve and maintain
Walk through a normal and incomplete case, revise the gaps, and have the process owner confirm the current version.
WORKED EXAMPLE
A request-intake instruction someone can test
Fictional administrative example: a small team receives requests through a shared inbox.
STARTING POINTCheck the inbox, deal with new requests and make sure everything is ready.
AFTER CHECKINGThe intake coordinator records the request identifier, requested output and supplied deadline in the team log. If either output or deadline is missing, mark the record Awaiting clarification and request the missing information. Once complete, assign the record to the designated reviewer. Completion means the reviewer and handoff time are recorded; it does not mean the work has been approved.
What changed
The revised instruction distinguishes intake from approval and names what to do with missing information. The process owner must still confirm the actual tools, roles and rules.
Make your own working brief.
Procedure title and identifier: Purpose: Start trigger: End condition: Process owner and authorised reviewer: Required inputs and approved systems: Steps with actor and completion check: Missing-input and exception routes: Records produced: Test cases and unresolved gaps: Version and review trigger:
Further reading.
This source informs the documentation principles. The request-intake procedure is an original fictional administrative example; it is not a compliance certification or operational approval.
