How to Write a Standard Operating Procedure: Template and Examples for Small Businesses

Overview

An SOP is a documented method for completing a process. It should help a qualified person understand what needs to happen, who owns each part, what “done” looks like, and what to do when the normal path does not apply. The aim is not to document every minor action or create paperwork for its own sake. The aim is to reduce avoidable decisions, preserve useful knowledge, and make work easier to hand over, review, and improve.

The most useful SOPs are specific enough to follow but flexible enough to remain accurate when ordinary circumstances vary. A short procedure for submitting an invoice may fit on one page. A customer onboarding process may need roles, system instructions, approval points, checklists, and links to supporting templates.

Use the following standard operating procedure template as a starting point:

1. Title and document owner: Name the process and identify the person responsible for keeping it accurate.
2. Purpose: Explain why the process exists and what result it should produce.
3. Scope: State where the procedure begins and ends, including what it does not cover.
4. Trigger and frequency: Describe what starts the process and whether it is daily, weekly, event-based, or occasional.
5. Roles and responsibilities: Identify the person doing the work, approvers, reviewers, and anyone who must be informed.
6. Inputs and tools: List the information, files, accounts, software, templates, or permissions required.
7. Step-by-step instructions: Write actions in the order they should be completed, using plain language and clear decision points.
8. Quality checks: Define how the completed work is checked before it is submitted, published, sent, or closed.
9. Exceptions and escalation: Explain what to do when information is missing, a deadline is at risk, or an unusual case appears.
10. Records and retention: State what should be saved, where it belongs, and who needs access.
11. Revision history: Record the version, date, change made, and person who approved the update.

For processes with many dependencies, connect the SOP to a project planning template or a task management tool. The SOP explains how work is performed; the task system can track when it is due, who owns it, and whether it is complete.

Checklist by scenario

Employee or contractor onboarding

An onboarding SOP should begin before the person’s first working day and finish when they can complete their initial responsibilities with appropriate support. Include:

• Who confirms the start date, role, access needs, and first-week schedule.
• Which accounts, devices, shared folders, and communication channels must be prepared.
• Which policies, security instructions, and role-specific materials must be reviewed.
• Who gives the initial task briefing and where questions should be recorded.
• What first-week deliverables or checks confirm that onboarding is complete.

Avoid listing tools without explaining their purpose. “Create an account” is less useful than “Create the account, confirm the correct permission level, and test access using the new user’s login.”

Invoicing and payment follow-up

An invoicing SOP should make the handoff from completed work to payment collection visible. Document:

• What evidence confirms that billable work is complete or approved.
• Which customer, project, purchase order, tax, currency, or payment details are required.
• How the invoice is prepared, reviewed, numbered, and delivered.
• Where a copy and supporting records are stored.
• When payment status is checked and how overdue accounts are escalated.

Use an invoice template for freelancers or your existing accounting format as a controlled input. The SOP should identify the approved template and explain which fields require review; it should not rely on memory.

Customer support

A support SOP needs both a normal response path and a clear route for exceptions. Include:

• Where requests arrive and how they receive a priority or category.
• What information the support person must confirm before responding.
• Approved troubleshooting steps, response language, and useful reference links.
• Which issues require escalation to a manager, technical owner, or account contact.
• How the conversation, resolution, and follow-up are recorded.

Define service expectations carefully without promising a response time the business cannot consistently meet. If a request is urgent, sensitive, or outside the documented process, the SOP should say who makes the next decision.

Recurring operations

For weekly reporting, stock checks, content reviews, account reconciliation, or similar routines, write the SOP around a repeatable schedule. Identify the trigger, expected duration, source data, output, reviewer, and completion record. A task manager can create the recurring task while the SOP remains linked in the task description. For work that depends on protected focus time, a time blocking template can reserve the working period without replacing the procedure itself.

What to double-check

Before publishing an SOP, ask someone who did not write it to follow the instructions. Observe where they hesitate, interpret a step differently, or search for missing information. Their questions are useful evidence about clarity.

• Ownership: Is one role accountable for the result, even when several people contribute?
• Entry conditions: Does the reader know when to start and what must already be available?
• Decision points: Are “if,” “then,” and approval conditions written explicitly?
• Quality: Can a reviewer tell whether the outcome is complete and correct?
• Permissions: Does the procedure direct people to the right access level without exposing confidential information?
• Records: Is it clear where evidence, versions, or customer communications belong?
• Tool alignment: Do the names, screens, fields, and links still match the software currently in use?
• Training value: Could a new team member use the SOP alongside reasonable context and supervision?

Keep sensitive passwords, private customer data, and security secrets out of the SOP. Link to the approved access or security process instead. Where legal, tax, employment, privacy, or industry requirements affect the process, have the appropriate internal owner or qualified adviser review the relevant section rather than treating a general SOP as professional advice.

Common mistakes

Writing a description instead of instructions. A paragraph about how important customer service is does not tell someone what to do. Replace broad statements with observable actions and outcomes.

Documenting the ideal case only. Add practical exceptions: missing information, duplicate requests, failed payments, absent approvers, system downtime, and work that arrives outside normal hours.

Making one person the entire process. Use role names where possible, define handoffs, and state who covers the task when the usual owner is unavailable.

Overloading the document. Move background explanations, lengthy screenshots, and rarely used reference material into linked resources. The main procedure should remain easy to scan.

Failing to connect the SOP to execution. A procedure hidden in a folder is easy to forget. Link it from recurring tasks, project checklists, onboarding plans, or the team’s knowledge base. For meeting-driven processes, convert decisions into assigned actions using an AI meeting notes to action items workflow, then attach the relevant SOP to each recurring action.

Never testing the document. Treat the first version as a working draft. Run it, collect questions, and revise the steps before calling it complete.

When to revisit

Review every SOP on a regular schedule that suits the risk and frequency of the process. A high-impact or frequently changing workflow may need a shorter review cycle; a stable, low-risk routine may be checked less often. A scheduled annual review is a useful baseline, but do not wait for the calendar when the process changes.

Update the document when the business adopts new software, changes an approval role, introduces a new product or service, changes its billing workflow, discovers a recurring error, or receives a question that the current instructions cannot answer. Revisit procedures before seasonal planning cycles when volume, staffing, or deadlines are likely to change.

Use this final update checklist:

1. Run the current procedure from start to finish.
2. Compare each tool name, link, permission, and form field with the live workflow.
3. Confirm that owners, approvers, escalation routes, and backup contacts are still correct.
4. Remove obsolete steps and add exceptions discovered since the last review.
5. Test the revised version with a person who was not involved in writing it.
6. Record the revision date, summary of changes, and approving owner.
7. Replace linked copies so the team is using one current version.

An effective SOP is not a document that never changes. It is a maintained agreement about how work should happen today. Start with one recurring process, use the template above, connect it to the team’s task management workflow, and schedule the next review before you finish.