Skip to content
notionsolutions

A practical library for building,
organizing and working in Notion.

Template guides

Notion SOP Template: Build an SOP Library With Runs and Review Dates

A Notion SOP setup that holds up is an SOP library database with an owner, an SOP ID and a review date on every procedure, plus a run template in Tasks for each job you repeat. Here's how to build both, who should edit, and what 33 marketplace SOP listings' ratings say.

Published
Brushed steel plate with grooves standing behind three frosted glass copies, two filled with white beads and one stopped at a blue bead, beside the headline Build a Notion SOP Library
One procedure, many runs: each copy follows the same grooves, and the blue bead marks the run still in progress.

A Notion SOP setup that holds up is an SOP library database with one page per procedure, plus a run template in Tasks for each job you repeat. Each SOP carries an owner, a review date and an SOP ID; each run is a fresh checklist linked back to it. To start, I'd duplicate Notion's own "Standard operating procedure" (4.86, 64 reviews) or the "SOP" template (4.88, 58), the two most-reviewed SOP templates, then add what no listing description in the table below mentions: a review date and separate runs.

For a freelancer with two or three repeated jobs, choose Notion's free SOP page and keep each checklist in a task template. For an agency or a small team with five or more repeated jobs, choose the full setup: an SOPs database with a review flag, a Procedure relation on Tasks and one run template per job. Below are the ratings, what belongs on an SOP page, how to build the library and the runs, who should be able to edit, and the mistakes that make SOPs go stale.

Notion SOP templates, by the numbers

These are marketplace user ratings, not tests, so they tell you how many people liked a template more than how it's built. The composite covers 33 listings: 24 from Notion's SOP template category and 9 from its "Top 10" SOP collection, with the listed price, star rating and review count for each. Seventeen of the 33 show a rating. Six listings about SOPs and processes have ten or more reviews:

SOP listings with 10 or more marketplace reviews, sorted by review count
TemplateMade byRatingReviewsWhat the listing says
Standard operating procedureNotion4.8664"A standard operating procedure (SOP) outlines how things at your company are done."
SOPNot shown4.8858Makes it easy to "write and use step-by-step instructions for any job"
Sales Processes SOPTemplate Studio4.8116An SOP "from prospecting through closing, including detailed follow-up procedures"
A3 ReportNot shown4.9111An A3 problem-solving report that "helps you analyze issues, identify root causes"
SOP | Standard Operating Procedures SystemNot shown4.9111A system to "document processes, assign responsibilities, and standardize operations"
Project Management SOPTemplate Studio4.9010An SOP "from planning through execution to closure"

Leave out the A3 report and the five SOP templates proper sit between 4.81 and 4.91, with a median of 4.88 on 159 reviews. With it, the six hold 170 reviews at a median of 4.89. Across all 17 rated listings the median is 4.90, ratings run from 4.33 to 5.00, and 1,861 reviews give a review-weighted mean of 4.84. Most of those reviews sit on two listings that aren't SOP templates: "Task Tracker." (4.83, 1,457 reviews, 78% of all reviews in the set) describes itself as "a Task manager", and Company Wiki Starter (4.88, 182) is a team knowledge hub. The 20 listings whose name or description mentions an SOP, a procedure, a process, a protocol, a how-to or an operations manual account for 11 of the ratings and 191 reviews.

The details under the stars say more. All five 5.0 ratings rest on one to three reviews each. Three listings are paid: two operations manuals at $97 and a niche SOP pack at $45. Two of those show no rating and the third has 2 reviews, and the manuals' listings lead with content: "60+ SOPs" in one, "60+ pre-written SOPs" in the other. SOP Writer is one of two listings in the set that are Notion AI skills rather than templates; its listing says it "turns a described process into an SOP anyone can follow". SOP from a process description is a separate, ordinary template that promises to "Turn a described process into a clear, repeatable SOP."

Among the reviewed SOP templates the stars sit within about a tenth of a point, so they can't tell you which structure fits your team. One unrated listing, SOP & Process Operations Hub, describes a library with "owner, status, review cycle, and impact", which is closer to what an SOP system needs than any of the six descriptions above. Choose by structure.

A quick check for any SOP template

  1. Does each SOP have an Owner?
  2. Is there a review or verification date?
  3. Is there a change log, or only version history?
  4. Does the checklist live on the SOP page or in a separate run?
  5. Can you find an SOP by its ID or tag straight away?

A template that fails the first two questions looks tidy on day one and drifts later, because nobody is named to notice that a step changed.

The procedure and the run are different pages

An SOP page that doubles as a checklist is doing two jobs. The procedure is the reference: why the process exists, when to use it, who does what, which tools it touches and the steps. It changes rarely, and only its owner should change it. The run is one execution of that procedure, such as onboarding one client or sending one monthly report. It gets assigned, dated and ticked off, then archived with the project.

Keep both on one page and someone ticks the boxes on the master, the next person finds half of them checked, and the SOP stops being trusted. A Reddit thread asking for a Notion SOP system points to the same fix: build the SOP as a template whose tasks start as empty pages, which suits jobs that repeat on every project. That's the setup here. Procedures live in an SOPs database, runs live in Tasks, and a relation connects them.

What goes on an SOP page

Give every SOP the same header properties, so the library can sort, filter and flag them:

The body follows one fixed order:

  1. Purpose: what the process achieves and why it exists.
  2. When to use: the trigger, such as "the client signs the proposal".
  3. Roles: who does each part and who approves.
  4. Before you start: access to request and tools to open.
  5. Steps: numbered, one action per step, with a screen recording linked where a click path is hard to describe in words.
  6. Done when: the visible result that ends the run.
  7. Change log: date, what changed and who changed it.

That order follows Notion's guide to SOP templates for startups, which calls the formula of its own template "purpose, context, definitions/terminologies, related tools, roles/responsibilities, and procedure" and says the best SOPs include both written instructions and video, with a Loom embed as one option. Its test for a finished SOP is a good one: you hand it to an employee and it gives them the context "without additional coaching". The same guide's advice on timing is to "Implement SOPs as early as possible". Notion's collection page for SOP templates adds the counterweight: avoid jargon, and don't let detail "overwhelm the user". One action per step keeps both in check.

If you're picking the first SOP to write, I'd start with client onboarding. It repeats with every new client, it involves the client directly, and a skipped step there is visible to the person paying you.

Build the SOP library in one database

Create a full-page database called SOPs and add the properties above, with Name as the title. I'd make it full-page rather than inline, because the database lock that keeps views and properties stable applies to full-page databases.

Give every SOP an ID

Click the + at the far right of the database and select ID. Notion's unique ID property generates a prefix from the teamspace and database names, and you can change it in the text box; SOP is the obvious choice. Numbers start at 1, deleted SOPs keep their numbers, and an ID never changes, so SOP-07 still means client onboarding after you retire SOP-06. A page can then open from a short URL such as notion.so/SOP-12, but only when the ID has a prefix, so select Edit property and check that the Prefix field isn't empty.

Four views that answer four questions

Flag SOPs that are due for review

Add a formula property called Review due:

if(or(empty(prop("Last reviewed")), empty(prop("Review every"))), true, dateAdd(prop("Last reviewed"), prop("Review every"), "months") < now())

It returns true when either property is empty, because an SOP with no review on record shouldn't pass as current. Otherwise dateAdd adds the Review every months to Last reviewed, and the formula checks whether that date is earlier than now(). A worked example: Last reviewed May 15, 2026 and Review every 6 give a due date of November 15, 2026, so on November 25, 2026, Review due is true and the SOP shows up in Due for review. To keep Review every from starting blank, set it to 6 in the database template you use for new SOPs; the empty check then catches pages created without that template.

Due for review table grouped under Account lead: SOP-07 Client onboarding, last reviewed May 15, 2026, and SOP-12 Monthly client report with no review date, both with Review due checked
Due for review catches SOPs past their review date and any SOP that was never reviewed.

Verification, if your workspace has it

If your workspace can verify pages, I'd use verification on top of Review due, because an expired verification notifies the owner in their Notion inbox and by email, while a formula only changes a value someone has to look at. Notion's wiki and verification help covers wikis, single pages and databases. A wiki starts from a standalone page you have Full access to, through ••• → More → Turn into wiki, and its pages can stay verified for a set period or indefinitely, with a blue check mark in @-mentions and search results. In a wiki you verify the pages you own, and a database can't be turned into a wiki, so this route means starting the library from a page. Building a full wiki, with its own home page and views, is a bigger project than the SOP library itself.

Individual pages outside a wiki can be verified on Business and Enterprise plans, and Notion's pricing page lists "Verify any page" under Business. For a whole database, the help describes a Verification property: select ••• at the top of the database → Properties → New property → Verification. That automatically adds an Owner property too, so I'd let it supply Owner instead of creating a second one by hand. For an overview, open Settings → Verified pages, where, as Notion's page verification guide puts it, you can search for a specific page and filter by owner or teamspace.

A reminder that reaches the owner

Without verification, nothing tells an owner that Review due turned true, so the view needs a weekly look. On a paid plan, a database automation can send the nudge: click ⚡ at the top of the SOPs database → New automation, choose the Every {frequency} trigger set to every week, and add the Send notification to action, which reaches up to 20 people in your workspace or the people in a People property. Name the SOP owners and add a message such as "Open Due for review". A recurring trigger can't be paired with another trigger, so the message goes out every week whether anything is due or not. It also can't stamp a new review date, because "The Every {frequency} trigger works with all automation actions except for Edit property." On the Free plan the help limits you to Slack notification automations. The manual route works on any plan: put Due for review on the weekly review dashboard you open every week anyway.

Run each SOP from a task template

In your Tasks database, add a new property, search for Relation and pick the SOPs database. Call it Procedure, and turn on the Show on SOPs toggle so each SOP page lists its runs too.

Then build one database template per repeated job. In Tasks, click the dropdown arrow next to New and select + New template. Name it after the job, such as "Client onboarding run", since whatever you title it becomes the template's name. Set Procedure to the SOP page. Notion's help warns against filling a relation in a template "unless you want every page you create with that template to relate to the same existing page(s)", and our guide to why every new task links to the same client treats that as a bug to find. The warning in that guide is the feature here: every onboarding run should point to the onboarding SOP.

The template body holds only the action checklist as to-do blocks, plus an @-mention of the SOP page so the reasons behind each step are one click away. Keep the explanations on the SOP. Notion's database template help puts the useful part plainly: "Whatever you choose will show up identically on each page created with the template." Every run starts with a clean, unticked checklist.

For jobs on a calendar, such as a monthly client report, make the run template repeat. Open the dropdown next to New, select ••• next to the template and open the dropdown next to Repeat, the same repeating database template setup you'd use for any scheduled task. It repeats daily, weekly, monthly or yearly, with an interval, a start date and a time. One catch from the automations help: "A recurring template automation will not trigger a database automation." If an automation should assign or announce each new run, a repeating template won't set it off.

On each SOP page, add a linked view of Tasks filtered to that SOP in Procedure, so the owner sees every run and its status. On SOPs, a rollup called Runs can count the related tasks with Count all, which counts "the total number of values in the selected property for all related pages". The relation holds the link and the rollup only reads it, the split our relation vs rollup guide is built around.

A New run button on the SOP page saves a trip to Tasks. Type / on the page, select Button, and use the Add page to action with Tasks and the run template, as in our Notion button guide. Set Procedure in the run template, not in the button, because Notion's button help says "The values from the template overwrite the values from the button." Unlike a repeating template, a button that creates a page does trigger database automations. Check permissions before you rely on it: a person needs Full access or Can edit to use a button on a page, and must be an editor of the target database. If your team has Can comment on SOPs, as I suggest below, they can't press it there, so put New run on a page they can edit or have them start runs from the New dropdown in Tasks.

Worked example: SOP-07 Client onboarding

Here's how the pieces fit for an agency, as a worked example rather than a real client. SOP-07 "Client onboarding" has the account lead as Owner, Status Active, Area Clients, Last reviewed May 15, 2026 and Review every 6. Its Steps section lists nine actions:

  1. Send the welcome email with the kickoff date.
  2. Create the client record and project.
  3. Share the client portal page.
  4. Send the intake form.
  5. Request access to the client's tools.
  6. Book the kickoff call.
  7. Add recurring deliverables to Tasks.
  8. Set up the shared folder for assets.
  9. Confirm the first deliverable date in writing.

The "Client onboarding run" template in Tasks carries the same nine lines as to-dos, an @-mention of SOP-07 and Procedure set to SOP-07. Three clients later, the linked view on SOP-07 shows three runs, two Done and one In progress, and the Runs rollup reads 3. On November 25, 2026, SOP-07 also appears in Due for review, ten days past its six-month review date. When the owner rewrites step 4, the review isn't finished until the run template matches, because the template is its own copy of the steps and templates only exist in the database where you created them. Edit it from Tasks: open the dropdown next to New, click ••• next to the template and select Edit.

SOP-07 Client onboarding page with Owner Account lead, Last reviewed May 15, 2026, Review every 6 and Runs 3, linked by a run template to three Tasks rows, two Done and one In progress
Each run starts from the Client onboarding run template, and its Procedure relation points back to SOP-07.

Who can change an SOP

An SOP needs protection from accidental edits and a record of what changed. Notion has a tool for each, and each comes with a catch:

Protecting an SOP: what each Notion tool does and where it stops
NeedUseCatch
The team proposes changesCan comment access plus ••• → Suggest editsWorks on text, to-do, heading and list blocks, not on inline databases, database properties or pages open in peek view; a locked page blocks it
Nobody edits by accident••• → Lock pageRead-only for everyone, including you; anyone with full or edit access can turn it off, and Unlock for me lifts it for you alone
Views and properties stay putLock database on a full-page databasePeople can still edit the data, just not views or properties
You can see what changedA Change log section on each SOPVersion history goes back 7 days on Free, 30 on Plus, 90 on Business and without limit on Enterprise, and needs at least Can edit

I'd give the team Can comment on SOPs and keep Can edit for owners. Teammates open ••• → Suggest edits, the owner gets an inbox notification and accepts with ✔️ or rejects with ❌, so improvements arrive without anyone overwriting the master. Notion's suggested edits help sets the floor at "Can comment access and above". A LearnChangeDo guide on Medium uses inline comments for the same loop, which leaves the owner a list of fixes for the next review.

I'd lock only finished SOPs that rarely change, such as a legal or compliance procedure, because a page lock makes the page read-only for everyone and also blocks suggestions. Our comparison of lock page vs lock database covers which lock protects what. The change log earns its place because version history has a window: Notion records a version every 10 minutes while someone edits, yet a Free workspace can only go back seven days. Restoring an earlier version of the SOPs database brings back its pages and properties but not the text inside them, which is one more reason each SOP keeps its own history in writing.

SOP mistakes and how to fix them

Common Notion SOP problems, their causes and fixes
SymptomCauseFix
Ticked boxes on the master SOPThe checklist lives on the procedure pageMove the checklist into a run template in Tasks
Several copies of the same SOPPages were duplicated into projectsKeep one page in the library and @-mention it everywhere else
Runs follow old stepsThe SOP changed, the run template didn'tMake "update the run template" part of every review
Suggest edits isn't availableThe page is locked, or the person has Can read onlyUnlock the page or give Can comment
An older version is goneIt's outside your plan's version history windowKeep the change log and a separate backup
The SOPs database won't turn into a wikiOnly pages can be turned into wikisStart a wiki from a standalone page, or keep the database with Review due or the Verification property

For the backup half of that fifth fix, the routine in backing up a Notion client project applies to an SOP library as well: an export you keep, plus a clear idea of what it can and can't restore.

Duplicate a template or build the library?

Duplicate Notion's own Standard operating procedure page if you need one SOP written today; it's free and the most-reviewed SOP template in the set. Build the library once you have five or more repeated jobs, because the IDs, the review flag and the run templates mean more setup up front and pay back only when several procedures need keeping current. The paid manuals' listings lead with written SOPs for a restaurant or a small business rather than owners or review dates, so I'd buy one only for the words. The same template-or-build choice runs through the rest of a client workspace, and our shortlist of Notion templates for freelancers sorts the options by workflow.

Where I'd start

Write the SOP for the job you repeat most this month, give it an owner and a review date, and make one run template for it. For a freelancer, that may be the whole system: one SOP page from Notion's template, one run template, and Due for review checked during the weekly review. For an agency, add the SOPs database with IDs, the Procedure relation and a run template per job, then give the team Can comment so fixes come in as suggestions. Notion keeps the copies, the IDs and the dates. Deciding that a step is wrong, and rewriting it, stays with the owner.

Questions that come up next

Can Notion AI write an SOP?

It can draft one. The marketplace lists SOP Writer, a Notion AI skill for turning a described process into an SOP. The draft still needs its owner to check each step against how the job is done before its Status moves to Active.

Can clients see our SOPs?

I'd give clients a separate page rather than access to the library. Client-facing steps, such as how to send assets or request changes, belong on a page inside the client portal, while internal SOPs stay with the team. Our guide to client portal permissions shows where to draw that line.

Are there agency SOP templates in Notion?

Yes. Web Agency SOP Builder & Process Library is one, with no rating on its listing, which covers "client onboarding, design handoffs, development, testing, and launch". For most agencies I'd write four SOPs first, client onboarding, monthly reporting, publishing and offboarding, each with its own run template in Tasks.

Keep the procedure current