SOP Template for SaaS Teams, With a Video Step Built In

Most SOP templates are built for a factory or a lab. Purpose, scope, roles, steps, sign-off. That is fine. But if you run a SaaS team, your SOPs are about screens: how to set up a customer's workspace, how to triage a bug report, how to hand a closed deal to onboarding. A written step like "go to Settings, then Integrations, then pick the right option" is where people get lost.

So this post gives you two things. First, what every good SOP template includes, based on templates I opened. Second, a template for SaaS work that has a place for a video, and a few rules for filling it in so people actually use it.

What every SOP template includes

The templates I read use slightly different names, but they agree on the core. Atlassian's Confluence template lists purpose, scope, roles and responsibilities, required tools, procedure steps, approvals or quality checks, related documents and revision history. HelpDocs has ten parts, adding prerequisites and exceptions and escalation. ONES boils it down to five: purpose and scope, roles, steps, resources, and revision history.

Both Atlassian and HelpDocs sell software for storing documents, and ONES sells project software, so each has a reason to push you toward its tool. The sections themselves are not controversial. Here is the short version:

Two details from these sources are worth copying. Atlassian says to assign responsibilities by role rather than by name, so the SOP stays right when people change jobs. And ONES says to include a short reason with a step, because people skip steps they do not understand when they are in a hurry.

Where the usual template falls short for SaaS

Written steps work well when the action is simple. They work badly when the work is a path through software with many settings. The writer knows the path so well that they leave out the parts that feel obvious. The reader is new, and those parts are exactly what they need.

Northwestern University's guide to writing SOPs suggests adding a graphic or flow chart where it helps. For a software task, the clearest graphic is the screen itself, with someone clicking through it.

The template

Copy this into a doc, a wiki page or a ticket. The one change from the usual template is the "Watch" block.

SOP: [Plain name, e.g. "Set up a new customer workspace"]
ID and version: [SOP-012, v1.0]
Owner (role): [e.g. Head of Customer Success]
Last reviewed: [date]     Next review: [date]

PURPOSE
[One sentence. What this achieves, and what "done" looks like.]

SCOPE
Applies to: [who, which plan or customer type]
Does not apply to: [what belongs in a different SOP]

ROLES
Performer: [role]
Checks the work: [role]
Escalate to: [role]

BEFORE YOU START
- Access you need: [tools, permissions]
- Have on hand: [information, links]

WATCH IT FIRST
[Link to the video of this procedure, one procedure per video]

STEPS
1. [Start with a verb. One action.] Result: [what you should see.] Why: [a few words.]
2. [Next action.] Result: [...] Why: [...]
3. If [condition], do [A]. Otherwise do [B].

CHECK
- [How to tell it was done right]

IF SOMETHING GOES WRONG
[Who to tell, and what to do first.]

RELATED
[Other SOPs, policies, the written checklist]

CHANGES
v1.0, [date], [who], first version

The written steps stay short because the video carries the detail. The "Result" line is what makes a step checkable: it tells the reader what the screen should look like after.

A made-up example, so you can see it filled in

This is an illustration, not a real customer or a real company process.

SOP: Hand a closed deal to onboarding
PURPOSE: Onboarding has everything it needs to start the kickoff on day one.
SCOPE: Applies to every new paid customer. Does not apply to renewals.
ROLES: Performer: account executive. Checks the work: onboarding lead.
WATCH IT FIRST: [link to a 4-minute video]
STEPS
1. Open the deal in the CRM. Result: stage reads "Closed won". Why: onboarding's queue only picks up closed deals.
2. Paste the call notes into the handoff form. Result: the form shows "Saved". Why: the customer should not have to repeat what they told sales.
3. Tag the onboarding lead and add the kickoff date. Result: the lead gets a notification.

Three steps and one short video replace a page of instructions. The new account executive does not guess where the form is.

Which SaaS processes to write first

Do not start with a list of fifty. Start with the one people ask about most. Good first candidates for a SaaS team:

• Handing a deal from sales to onboarding
• Setting up a new customer's workspace or account
• Triaging and routing a bug report
• Running a release checklist
• Answering the same support question that arrives every week
• Preparing for a customer kickoff or renewal call

To begin, Northwestern suggests writing the steps as if you were explaining the task to a friend, then asking a colleague whether it is clear.

Written, video, or both?

Here the evidence is mixed, so I will not oversell video.

A 1991 study in the International Journal of Man-Machine Studies had people learn software tasks from a demonstration or from written procedures. The abstract says demonstrations gave faster and more accurate learning in the training session, but in later sessions the people who had watched demonstrations took longer than those who used written instructions. A later experiment had 111 fifth and sixth graders learn Word formatting, and found that the groups with video, either alone or mixed with paper, outperformed the paper-only group. These are small studies, one is old and one used children, so they do not settle anything for a SaaS team in 2026.

What I take from them is practical. Video is good for learning how a job looks. Written steps are good for doing it again quickly. So keep both: the video to learn the procedure, the short checklist to run it. That is why the template above has both.

Rules for the video part

• One procedure per video. Each video should answer one question, so people can find it and you can re-record it when it changes. DemoSix publishes demos up to about six minutes, and a longer recording becomes ordered six-minute parts. If a process runs past six minutes, it is probably two SOPs.
• Record it the way it is really done. Have the person who does the job do it, with their real screen. HelpDocs suggests having someone follow the SOP exactly as written and note where they get stuck. Do the same with the video: send it to a newer teammate before you call it done.
• Link it from the steps. The written SOP is the index. The video is the detail behind it.

Keep it from going stale

Atlassian puts it bluntly: an outdated SOP can be just as harmful as no SOP at all. HelpDocs says an SOP with no owner quietly rots, so give each one an owner and a review date. For how often, Northwestern says at least once a year and ONES says every six months. Pick the rhythm that matches how fast your product changes. If you ship weekly, lean toward the shorter one.

This is where one procedure per video pays off. When one step changes, you record that one procedure again, not the whole library.

Where to keep them

You can keep this in any wiki. If you want the video part to be easy, DemoSix is built for it: the person who knows the job records it with DemoSix Recorder on Mac or Windows, or uploads a video they already have, and it goes into a private library sorted into Channels by team or process. Only the people you invite can watch, and they watch in a browser. You can keep your written checklist where it is today and link each step to its video.

On Standard and Teams, Who watched shows, for each demo in a private library, who watched it, who stopped part way, and who has not started. That answers a question a written SOP alone cannot: did the new hire actually go through it? Basic is free, with one seat and a 100-minute video library, and the pricing page has the current plans.

The takeaway

A good SOP template is short, and it has the same sections every time: purpose, scope, roles, steps, checks, escalation, owner. For SaaS work, add one more: a video of the procedure, one per SOP. Write the first one for the question your team gets asked most this week, send it to the newest person on the team, and fix whatever trips them up.