A Standard Operating Procedure Template for Small Teams
A practical worksheet for documenting how one recurring operational task is performed — output, trigger, numbered actions, decision points, completion checks, and escalation roles. Select the text and copy it into your own document.
What an SOP is — and what it isn't
A standard operating procedure documents how one recurring, low-risk operational task is performed. It records the output the task produces, what triggers it, the ordered steps with their inputs and expected results, how each step is checked, where the approved instructions live, and which role to contact when a step is blocked.
It is not a policy (which states workplace expectations), and it is not a handover (which states who owns the current work). Start with a repeatable office process — preparing a weekly meeting agenda, ordering supplies, publishing a recurring report — and keep sensitive credentials out of the document by linking to approved instructions only.
This is a static public resource, not an app feature. This worksheet has no data-entry or completion-tracking controls. You can select the template text on screen and copy it into your own document. Keep credentials in your approved access process and sensitive records in your authorized systems; link to approved instructions rather than copying data.
- 1.Pick one repeatable, low-risk office process.
- 2.Name the output, trigger, and start-to-end scope.
- 3.Write each step as action, input, result, check.
- 4.Route decision points and blockers to roles.
- 5.Run a pilot walkthrough; record the gaps.
Build your own procedure
Select the fields below and copy them into your own document. There are no input fields and this worksheet has no data-entry controls. If a detail isn't known, leave it as a placeholder rather than guessing.
Procedure title
[Plain-language name of the task this procedure describes]
Use the name your team already uses for the work, not a label invented for the document.
Output
[The concrete thing this procedure produces, e.g., a final agenda shared to the approved channel]
Name the finished result someone can point to and say 'this is done'.
Trigger
[What starts this procedure — a date, a recurring cadence, or a request from a named role]
Describe the event that tells the owner it's time to begin.
Start and end scope
[Where this procedure starts and where it is considered complete]
Bound the work so the owner knows the first step and the last.
Owner
[Role responsible for performing and completing this procedure]
Name the role, not a specific person, so the procedure survives a role change.
Approved references
[Links or descriptions of where the approved templates, systems, or instructions live]
Point to the approved source. Keep credentials in your approved access process; link to instructions only.
Prerequisites
[What must be in place before starting — access, materials, or a prior step already completed]
List what the owner needs before step one makes sense.
Numbered actions
[Each step in order, with the action, the input it uses, and the expected result]
Use the step worksheet below to write these as small, checkable actions.
Decision points
[Where the owner might need to choose, and the role to consult for that decision]
Flag the forks; route the question to the right role rather than guessing.
Completion check
[How the owner confirms the procedure is complete — a measurable, agreed criterion]
A specific test, not a feeling. 'Agenda items each have a purpose and owner' beats 'agenda looks good'.
Exceptions / escalation roles
[What falls outside this procedure, and which role to contact when it happens]
Route escalations by role, not by personal contact, where possible.
Version / review owner
[Role accountable for keeping this procedure current, and the review cadence the owner selected]
The person who updates the procedure when the real process changes. Choose a review schedule suited to the process and confirm any applicable organizational requirements.
Write each step as a small, checkable card
For every action in your numbered list, record the action, the input it uses, the result it produces, how the owner confirms it's done, and which role to contact if the step is blocked.
Action
[The specific action the owner performs]
Input
[The information or material needed for this action]
Expected result
[What this action produces]
Check
[How the owner confirms this step is done before moving on]
If blocked
[Which role to contact if this step cannot be completed]
A worked example: preparing a weekly internal meeting agenda
This is a made-up example to show how the steps fit together. It is not a real customer or employee story. Unknown details stay as placeholders; nothing is invented where unknown, and nothing is sent automatically.
1. Collect agenda items by the agreed cutoff
Input: Requests submitted by team members ahead of the cutoff time
Expected result: A working list of proposed agenda items
Check: Cutoff time has passed and the working list is in the approved draft location
If blocked: Office Manager, if items are still arriving after the cutoff
2. Check each item for context and a named owner
Input: The working list of proposed items
Expected result: Each item either has a purpose and an owner or is flagged for follow-up
Check: No item remains without a context note or an owner
If blocked: Office Manager, if an owner cannot be confirmed
3. Organize the approved agenda into the approved order
Input: Items with confirmed context and owners
Expected result: A draft agenda in the approved template, ordered for the meeting
Check: Draft follows the approved template and order
If blocked: Office Manager, if the order is unclear
4. Confirm the final agenda with the meeting owner's review
Input: The draft agenda
Expected result: A final agenda the meeting owner has reviewed and approved
Check: Meeting owner has confirmed the final draft
If blocked: Office Manager, if the meeting owner is unavailable before the meeting
5. Share the final agenda through the approved company channel
Input: The approved final agenda
Expected result: Agenda available to attendees through the approved channel before the meeting
Check: Agenda is reachable through the approved channel by the agreed time
If blocked: Office Manager, if the approved channel is unavailable
Decision branches
If an agenda item lacks a named owner
Flag the item, contact the requester or the Office Manager to confirm an owner, and only include it in the draft once an owner is confirmed. Do not assign an owner on someone's behalf without confirmation.
If the meeting owner (the reviewer) is unavailable before the meeting
Escalate to the Office Manager. Do not auto-send an unreviewed agenda through the approved channel. The Office Manager decides whether to proceed with a prior approved agenda, delay, or reassign the review.
Completion check
- Each agenda item has a stated purpose and a named owner
- The meeting owner has confirmed the final draft
- The current approved agenda's location is recorded and reachable
Vague vs. specific steps
A useful step names the action, the input it uses, the result it produces, how it's checked, and who to escalate to. Here's the difference in practice.
“Prepare the agenda.”
Vague — no input, no expected result, no check, no escalation route. The owner can't tell when the step is done or who to ask if it's stuck.
“Collect agenda items by the agreed cutoff — input: requests submitted ahead of the cutoff time; expected result: a working list; check: cutoff passed and the list is in the approved draft location; if blocked: contact the Office Manager.”
Specific — the action, the input it uses, the result it produces, how it's checked, and who to escalate to are all named.
Test the procedure before you rely on it
A pilot surfaces the steps that look clear to the author but aren't clear to a colleague following them cold. It's a review aid, not a pass/fail judgement — and no outcome is guaranteed.
- 1
Ask a colleague who doesn't usually run this task to follow the procedure exactly as written.
- 2
Have them note any step where the action, input, expected result, or check wasn't clear enough to complete.
- 3
Record each gap and the role who can resolve it.
- 4
Update the procedure and re-test once the gaps are closed — this is a review aid, not a pass/fail judgement.
Policy, SOP, and handover — how they fit together
Before you share the procedure
Walk the steps in order
Follow the numbered actions start to finish. Each step should have a clear input and a checkable result.
Name the escalation role at each fork
Every decision point and 'if blocked' route should name a role, not a personal contact, where possible.
Keep credentials out of the document
Link to approved instructions; keep passwords and access secrets in your approved access process.
Confirm the completion check is measurable
Make sure the completion criterion is a specific test someone else can confirm, not a feeling.
Assign a version and review owner
Name the role accountable for updating this procedure when the real process changes.
Run a pilot walkthrough
Have a colleague follow the directions and record any step they couldn't complete as written.
Frequently asked questions
Straight answers about what an SOP is, what to keep off the page, and how it differs from a policy and a handover.
The AI HR assistant can help you talk through a procedure in plain English and draft a starting set of steps using your company context, and the document generator can help draft related materials. You still confirm the owner with your team, keep credentials in your approved access process, and review every draft before use. This is a public worksheet; it has no data-entry or completion-tracking controls.
Related resources
Pair this procedure with the role-definition, version-control, and records tools.
HR clarity to your team today.
Get your HR tools and resources backed by industry-standard practices and procedures, supercharged by AI.