Standard Operating Procedure Template: Write an SOP People Use

A standard operating procedure template stops every process document from inventing a new outline. The template answers the same questions every time: what this process is for, who owns it, when to use it, the steps in order, what to do when the usual path fails, and when someone must read it again. If those lines are missing, the page is a memo. People will not follow a memo at 4 p.m. on a Friday.

ClickUp can hold the finished SOP in a Doc next to the List that runs the work. Docs are on every plan. The feature detail is in ClickUp Docs. This page is the template and the writing rules. The ClickUp hub links tasks, templates, and Docs around it.

What goes in a standard operating procedure template?

Keep the headings stable. Change the answers. An SOP that uses a new structure every time cannot be compared with the last one, and it cannot become a template your team reuses.

Purpose is not the steps. "So a new client gets access on day one" is a purpose. The steps are the clicks and the handoffs. If you cannot say the purpose in two sentences, the process is probably two processes.

"Applies when" is the section people skip and then misuse the page. A refund SOP that does not say the dollar limit, or who is allowed to approve above it, will be used for the wrong refunds. Write the boundary in one line.

Exceptions are not a junk drawer. Name the common failure and the next action. "If the invoice system is down, email the owner and do not mark the task done." That is an exception. A paragraph about how invoices used to work in 2019 is not.

The review date is part of the template, not a nice extra. A page without a date looks current when it is not. Put a real date, and assign a person.

How do you write steps people will follow?

Write steps as verbs. "Send the welcome email from the template" is a step. "Communication is important" is not a step. One action per number. If a step needs a decision, make the decision its own line: "If the client is on a retainer, use Template A. Otherwise use Template B."

Name the owner of the step when it changes hands. A ten-step SOP done by one person can leave the name off each line and put it in the header. A process that moves from sales to delivery needs the role on the step, or the work sits between teams.

Use the words already on the tools. If the status in your tracker is "Client review," the SOP should say "Client review," not "waiting on them." People follow the words they see on the screen.

Keep policy out of the steps. Policy is who is allowed to do something and what the company will not do. An SOP is how the allowed work gets done. Link the policy. Do not paste it into step 4.

Screenshots help when the screen is confusing and the click is easy to miss. They hurt when the product UI changes every quarter and nobody updates the image. Prefer the name of the button. Add a screenshot only for the step people get wrong.

Test the draft on someone who does the job and did not write the page. Ask them to follow it without you in the room. Every question they ask is a missing step or a vague verb. Fix the page. Do not add a training session to explain a bad page.

Length is a quality check. One to two pages covers most small-team processes: publishing a post, onboarding a contractor, closing the books for a month, handing a project to a client. A twenty-page SOP is usually a handbook. Split it into one SOP per trigger.

A project brief is a different document. The brief says what this project will achieve. The SOP says how your team runs a kind of work every time. The brief template is in how to write a project brief. Do not merge them. Link them.

Where should you store SOPs in ClickUp?

Store each SOP as a page in a ClickUp Doc. Docs are available on every plan, and guests can use them. You can create a Doc from the sidebar, from Docs Hub, from a template, or as a view on a Space, Folder, or List.

A wiki is a Doc you mark as the source of truth. ClickUp treats that badge as the signal for which page to trust. ClickUp's pricing comparison lists 1 wiki on Free Forever, 1 on Unlimited, and 1 on Business. Help says Business Plus can create unlimited wikis, and that saving a wiki as a template counts as creating one. For a small team, one wiki Doc with a page per SOP is the clean setup. Nested pages keep "Clients," "Delivery," and "Finance" as sections without spending a second wiki.

You can also put a Doc view on the List that runs the process, so the SOP sits on the same screen as the tasks. Deleting a Doc view deletes the Doc. If you only want to remove the view, move the Doc first.

Two ways to connect the page to the work:

• Link the Doc from the List description or from a pinned task named "How we do this."
• Select text in the Doc and create a task when a line is real work, such as a step that must happen on a date. The Doc stays the procedure. The task is the instance.

Save the Doc as a template after one SOP has survived a real run. ClickUp templates covers Doc templates along with Lists. The next process starts from the outline above, not from a blank page.

Sharing follows Doc permissions. On Free Forever, a guest has full edit on what you share. On paid plans you can restrict guests. Do not put salary numbers, passwords, or client secrets in an SOP you share widely. Link to the system of record instead of pasting the secret into the step.

Notion is the stronger home when the wiki is the center of the company and the tasks are secondary. ClickUp is the stronger home when the procedure should sit next to the tasks that carry it out. The comparison is ClickUp vs Notion. You can write the SOP in either tool. Pick the one your team already opens on a workday.

How do you keep an SOP current?

Put the review on a recurring task assigned to the owner. A six-month or twelve-month cycle fits processes that change slowly. A process you run every week should be reviewed the first time it fails, and on the calendar date anyway. ClickUp recurring tasks is how you stop the review from depending on memory.

The review is a short checklist, not a rewrite by default:

1. Read the trigger. Does this still describe when people open the page?
2. Follow the steps once, or watch someone follow them.
3. Delete steps for tools you no longer use.
4. Confirm the owner is still the owner.
5. Set the next review date and say what changed, in one line at the top or in a short changelog at the bottom.

Version drama is optional. Small teams do not need a formal revision table on every typo. They do need to know whether the page they are reading is the current one. The wiki badge, a single Doc, and a date in the header do that job. Duplicate copies in email and in a second folder are how the old steps survive.

When a process changes, update the SOP before you announce the change. Otherwise the announcement and the page disagree, and people follow whichever they saw last.

An onboarding checklist is a cousin of an SOP, not a substitute. The checklist is the instance: this hire, these tasks. The SOP is how your team runs onboarding every time. A worked checklist is in employee onboarding checklist. Point the SOP at that checklist, and point the checklist at the SOP, so neither one tries to be both.

What does a finished SOP look like?

Here is the template filled for a small, real process. Swap the words. Keep the headings.

Title: Send the weekly client update

Purpose: Clients see what moved, what is blocked, and what you need from them, without a status meeting.

Owner: The account lead for that client.

Applies when: Every Friday for active retainer clients. Skip the week if the client asked for a different cadence in writing.

Before you start: The project List is up to date. You can open the shared view or the Doc you send from.

Steps:

1. Open the client List and filter to tasks updated this week.
2. Write three lines: done, blocked, and needed from the client.
3. Paste those lines into the update Doc. Do not attach internal-only comments.
4. Send the Doc or the shared view before the end of Friday in the client's time zone.
5. Create a task for anything the client must answer, with a due date.

Exceptions: If a task is blocked on the client, say so in the "needed" line. Do not mark that task done to clear the List.

Review date: The first Monday in April and the first Monday in October, owned by the account lead.

The habit of the update itself is in how to share project updates with clients. The SOP is the page that makes that habit the same for every account lead.

Write the next SOP only after this one has been used. A folder of blank templates does not change how work gets done. One page that people open on Friday does.