Download the blank SOP and completed examples
The downloads provide a blank standard operating procedure template and two completed fictional SaaS examples: investigating a reported failed invitation and opening a small invitation-expiry pilot. They are editable plain-text files that can be copied into your documentation tool.
The examples use a fictional app called InviteDesk. They describe a possible operating agreement, not real customer incidents, current ShowMeYourSaaS systems, or commands verified against your software. Replace the assumptions, authorized actions, and system references before using an SOP operationally.
What is a standard operating procedure?
An SOP gives a recurring process a dependable reference. It explains when the procedure applies, what the operator needs, which actions to take, how to recognize the result, and when to stop or escalate. A reader should not have to guess what an instruction such as check everything means.
Atlassian's SOP guidance includes purpose, scope, responsibilities, tools, steps, checks, and revision information. Our original template applies that general structure to small SaaS operations. Keep only the sections that help someone perform and maintain the specific process.
Customer-facing help documentation explains how a customer completes a task. An internal SOP can include staff-only evidence, approval boundaries, and escalation paths. Give each its own audience and access rules; an internal procedure should not become a public troubleshooting page by accident.
Choose a process that actually repeats
Begin with a task that is recurring, easy to misinterpret, or difficult to hand over. An invitation failure investigation is a useful example because it can involve identity checks, message status, account eligibility, and a decision about whether another invitation is appropriate.
Write the trigger and the stopping point. The support example starts after a customer reports that an expected invitation did not arrive. It ends with a recorded explanation, an authorized next action, or a named escalation. It does not promise that every recipient's inbox can be controlled.
Keep one procedure focused on one outcome. A document that covers every support question will become a navigation problem. Link to another procedure when a different task begins, such as investigating a broader provider incident or reviewing a request to change access.
Specify prerequisites and authority before the steps
List the evidence and access the operator needs. In the fictional support example, that means the existing support identity process, the relevant account and invitation identifiers, a permitted view of message events, and the current invitation policy. The operator should not request a customer's password or expose another account's records.
Name which actions the procedure authorizes and which require another owner. Seeing an invitation failure does not automatically authorize changing a role, bypassing suppression, or sending another message. If the required identity or account relationship cannot be established, stop and route the case through the defined process.
A RACI matrix can clarify who performs, accepts, contributes to, and receives updates about the work. The SOP still needs enough detail to execute the handoff: what information is supplied, where it goes, and what the operator does while a decision is pending.
| Needed before starting | If it is missing |
|---|---|
| Verified relationship to the relevant account | Pause and use the existing support verification process |
| A specific invitation or intended-send identifier | Collect permitted details without guessing which record applies |
| Access to the relevant status history | Escalate to an authorized operator |
| A current eligibility and resend rule | Ask the process owner; do not invent an exception |
Write steps with observations and branches
Use an action, an expected observation, and a branch when the result can vary. Inspect the message event is incomplete by itself. Specify which event matters and what follows from acceptance, a temporary failure, a permanent failure, or no matching record.
In the example, the operator checks the intended invitation record and confirms current eligibility. A server-accepted message leads to a different investigation from a permanent bounce. The operator records the evidence and follows the current product policy rather than treating every missing email as a reason to click resend.
Keep actions small enough to verify. If an authorized replacement is permitted, confirm which invitation remains valid, prevent an accidental duplicate, and record the replacement identifier. These are design requirements for the fictional process; your app's actual expiry and replacement behavior must be checked before the SOP is approved.
Use clear names for decision owners and information fields. Screenshots may help, but a brittle sequence of button coordinates becomes obsolete when an interface changes. Describe the task and expected result so a trained operator can notice when the screen no longer matches.
Example 2: open a bounded pilot release
The second completed SOP starts with a reviewed release candidate and an explicitly approved pilot audience. Its prerequisites include acceptance evidence, an independent permission check, a tested disabled path, an observation plan, and an owner who can respond during the pilot.
The operator confirms the current release configuration and records the intended audience before changing exposure. After the authorized change, the operator verifies the actual assignment on a safe account and checks the agreed failure observations. A permission regression or incorrect result triggers the stated pause and escalation.
Turning a feature flag off affects future evaluations. The SOP therefore asks about queued work and actions that already happened. It closes the pilot step only after the observation and handoff record exists, rather than assuming that a successful configuration save proves a successful release.
Dry-run the SOP before relying on it
Ask someone with the intended training and access to follow the draft against synthetic data or a safe test environment. If you are a solo founder, walk through it after stepping away from the original task and record every assumption you have to reconstruct.
Try an incomplete prerequisite and an unexpected result as well as the normal path. The dry run should reveal whether the operator knows when to stop, what evidence to retain, and who owns the next decision. Record assistance and ambiguity instead of silently correcting the procedure in your head.
Keep a short execution record: procedure version, date, operator, relevant record IDs, branch taken, result, and follow-up owner. Avoid retaining unnecessary message contents or credentials. Set access and retention around the actual operating need.
Review the procedure when its dependencies change
Assign an owner and a review trigger. A provider change, permission redesign, new invitation expiry rule, or repeated exception can invalidate a procedure before a calendar review date arrives. Record the reason for each revision and identify which previous instructions changed.
Automate only the stable, authorized parts after understanding the decisions. The workflow automation guide covers duplicate handling, current-state checks, and recovery ownership. A well-written SOP helps specify that automation and the human handoff it still needs.
The blank template includes purpose, trigger, scope, prerequisites, authority, steps, branches, verification, escalation, execution evidence, and revision history. Sources and original examples checked October 27, 2026.