Read summarized version with
If you’ve never written an SOP before, it can feel weirdly intimidating. Blank document. A process you do half on autopilot. And this nagging suspicion that you’re about to do it “wrong.”
I’m Yuval. I run Glitter AI, and I’ve watched hundreds of small business owners, office managers, and first-time ops folks stare down their first SOP. Same pattern every time. They overthink. They try to make it perfect. And then nothing ships.
Here’s my honest pitch for your first SOP: it doesn’t need to be good. It just needs to exist. A scrappy one-pager someone else can actually follow will beat a gorgeous 30-page manual that lives in your head forever.
This is the beginner’s guide I wish someone had handed me. Ten short steps, a handful of mistakes to sidestep, no jargon.
Teach your co-workers or customers how to get stuff done – in seconds.
Step 1: Pick the Right First SOP (This Matters More Than You Think)
The biggest mistake beginners make? They pick the wrong process.
People reach for the most important thing - closing the books, onboarding a customer, the big monthly report - and immediately drown. Those processes are long, full of edge cases, and usually involve three different people. Worst possible place to start.
Here’s the rule. Your first SOP should be:
- High frequency - happens at least weekly, ideally daily
- Mildly frustrating - gets messed up or asked about a lot
- Doable in 30 minutes or less - short enough to capture in one sitting
You’re looking for the boring task that someone keeps interrupting your day to ask about. Not the most strategic. Not the longest. The most annoying.
Examples of great first SOPs:
- How to onboard a new employee on day one
- How to process a refund in Shopify
- How to send the weekly customer email
- How to enter a vendor invoice in QuickBooks
- How to schedule a social media post
Not sure? Ask your team: “What’s the thing you Slack me about over and over?” That’s your answer. For more on this, see my SOP meaning in business explainer.
Step 2: Find the SME (and Yes, It Might Be You)
Every SOP has a Subject Matter Expert - the person who actually knows how the thing gets done. Not the person who should know. The person who does.
Sometimes that’s you. If you’re a founder writing your first SOP, you’re probably documenting something you do every day. Fine - but the curse of expertise is real. You’ll skip steps that feel “obvious” because you’ve done them 500 times. Step 8 fixes that.
If the SME is someone else, your job changes. You’re not writing the SOP for them. You’re capturing their process and shaping it into a document. They are the source of truth. Don’t argue with how they do it (not yet). Just record it.
Step 3: Decide Where the SOP Will Live
Before you write a single word, decide where this thing is going to live. SOPs without a home die.
Quick tool fit for first-timers:
- Notion - great if you already use it for everything else; terrible as a “single source of truth” if half your company has never logged in
- Confluence - strong for engineering and IT teams; overkill for a five-person ops team
- SharePoint / Google Drive - fine if you just need a folder of docs people can find; weak on structure and search
- Glitter - purpose-built for SOPs with screenshots, search, and version history; the path of least resistance if you don’t already have a wiki
The honest answer: wherever your team already looks for things. If your team lives in Slack and Google Drive, don’t force them to learn Confluence to read one SOP. Pick the option with the least friction.
Teach your co-workers or customers how to get stuff done – in seconds.
Step 4: Capture the Process (Three Options, Ranked)
This is where most first-timers stall. You open a blank doc, and your brain goes empty. So skip the blank doc.
You’ve got three real options for capturing a process. Worst to best:
Option A: Write from memory (terrible)
Open a doc, try to remember every step. You’ll forget half. The half you forget will be exactly the steps the next person needs. Don’t do this.
Option B: Interview the SME (decent)
Sit with the SME (or yourself, with a notepad) and walk through the process out loud. Write down each step as it happens. This works, but it’s slow - and it’s still an abstraction. You’re translating what they say into what they actually do, and those two aren’t the same thing.
Option C: Record the process being done (best)
Hit record. Have the SME do the task once, normally. Don’t narrate, don’t explain - just do it. The recording captures every click, every form field, every “wait, I need to grab that other tab.” Then you turn the recording into a draft.
That’s exactly what Glitter does. Record once, get a step-by-step draft with screenshots already in place. From there, you edit. You’re not staring at a blank page - you’re polishing a real artifact. For most of my first-time SOP writers, this turns a four-hour project into a 30-minute one.
For the full breakdown of how to write the SOP itself once it’s captured, my how to write an SOP post goes step by step.
Step 5: Structure the Doc - The 7 Essentials
Every useful SOP, regardless of the process, has the same seven sections. Memorize these and you’ll never stare at a blank page again.
- Purpose - One sentence. Why does this SOP exist? What’s it for?
- Scope - When does this apply? When does it not apply?
- Owner - Whose job is it to keep this doc current? (Name a person, not a team.)
- Prerequisites - What does the reader need before starting? Access, tools, info, permissions.
- Steps - The actual procedure. Numbered. With screenshots.
- Exceptions - What happens when things go sideways? Who do they ask?
- Change log - When was this last updated, and what changed?
That’s it. That’s the whole structure. No fancy templates, no compliance jargon, no 14-page boilerplate. If you want a downloadable starting point, grab my SOP template guide.
Step 6: Write the Steps (Good vs. Bad Examples)
This is where good SOPs and bad SOPs diverge. Steps should be specific, action-first, and short enough that a sleep-deprived person can follow them at 8 a.m. on a Monday.
Compare these:
Bad:
The user should log into the system and navigate to the appropriate area to update the relevant information.
Good:
- Open Shopify Admin at admin.shopify.com.
- Click Customers in the left sidebar.
- Search for the customer’s email address.
- Click their name to open the profile.
See the difference?
- The good version starts with a verb (Open, Click, Search).
- It names the exact tool (“Shopify Admin”, not “the system”).
- It uses bold for buttons so the eye lands on them.
- Each step is one action. Not three things glued together with “and then.”
A few rules to internalize:
- Active voice, always. “Click Save” not “The Save button should be clicked.”
- One action per step. If you’re using “and” twice, split it.
- Name things by their actual name. “The blue button” ages badly. “Click Approve” doesn’t.
- Short. If a step runs more than two sentences, it’s probably two steps.
For more on formatting, see my SOP format best practices post.
Step 7: Add Visuals
Words aren’t enough. They never are.
The single highest ROI thing you can add to an SOP is a screenshot. The next person reading isn’t reading carefully - they’re scanning, finding the screenshot that matches what’s on their screen, then following the arrow.
Some quick rules:
- Screenshot the thing the reader needs to click. Not the whole window. Just the relevant area.
- Annotate. A red box around the button. An arrow. A 1-2-3 callout.
- Crop tight. Reading a 4K screenshot of someone’s whole monitor is a chore.
- Update them when the UI changes. Stale screenshots are worse than no screenshots - they make readers second-guess themselves.
If you used the “record it” approach in step 4, your screenshots are already there. Bonus.
Teach your co-workers or customers how to get stuff done – in seconds.
Step 8: Test It With Someone Who’s Never Done It Before
This is the step everyone skips. Don’t.
Find someone who has never done the process. A new hire is perfect. A coworker from another team works too. A friend or family member if you can swing it. Hand them the SOP and ask them to follow it without asking you any questions.
Watch what happens.
The places they get stuck? Those are the steps you skipped because they felt “obvious.” The curse of expertise gets exposed in about 30 seconds. Add what’s missing. Clarify what’s confusing. Re-test.
The standard I aim for: a competent stranger should be able to do this task end-to-end without messaging anyone. If they can, you have an SOP. If they can’t, you have a draft.
Step 9: Publish It and Tell People It Exists
A finished SOP nobody knows about is the same as no SOP. I see this constantly - gorgeous documents buried three folders deep, completely forgotten.
When you publish:
- Drop a link in the team channel (“Hey, here’s the new SOP for X - bookmark it”)
- Pin it somewhere people will actually see it
- Reference it the next time someone asks how to do the thing (“Here’s the doc - let me know what’s missing”)
That last one is huge. Every time someone asks you how to do the thing, send the SOP instead of answering. They use it. They tell you what’s wrong. The doc gets better. You stop being the bottleneck. That’s the whole point.
For the broader argument on why this matters, see my standard operating procedures guide.
Step 10: Set the Next Review Date
Last step. Takes 10 seconds.
At the bottom of the SOP, write: “Next review: [date 6 months from today].”
Software changes. Processes change. People change. SOPs that aren’t reviewed regularly turn into landmines - they look authoritative, they lie to the reader, and trust in the whole library quietly erodes.
Six months is a sensible default. For things that move fast (software UIs, marketing channels), make it three. For things that barely change (compliance, finance month-end), a year is fine. Just put a date on it. And drop it on the owner’s calendar.
Common Beginner Mistakes (And How to Fix Them)
Five mistakes I see over and over from first-time SOP writers:
1. Too long. A 14-page first SOP is a first SOP nobody will read. If your draft is over two pages, walk through every step and ask: “Is this actually a step, or did I explain something I didn’t need to?”
Fix: Cut anything that isn’t a direct action or a visual.
2. Too vague. “Update the customer record” isn’t a step. It’s a category.
Fix: Replace any verb that doesn’t tell the reader exactly what to click with one that does.
3. No owner. “The team” isn’t an owner. “Operations” isn’t an owner. A name is an owner.
Fix: Put a single person’s name in the owner field. If they leave, update it.
4. Passive voice. “The invoice should be reviewed and then approved” lets everyone off the hook. Nobody knows whose job it is.
Fix: Rewrite with active verbs and a clear subject. “Open the invoice. Click Approve.”
5. Never updated. The slow killer. The SOP was right when you wrote it. Then the software updated, the workflow shifted, and now it’s wrong in three places.
Fix: Step 10. Review date. Calendar reminder. No exceptions.
The Glitter Angle: Skip the Blank-Page Terror
If I had to pick the single biggest reason first SOPs don’t get written, it’s the blank page.
The whole “open a doc and start typing” model is hostile to beginners. You have to remember every step, write in a clean voice, take screenshots, paste them in, fight the formatting, and somehow stay motivated through all of it. Most people quit around screenshot number three.
Glitter flips this. Hit record. Do the process the way you actually do it. Five minutes later, you have a draft - every step captured, every screenshot annotated, structure already there. You’re not writing an SOP. You’re editing one.
If you’ve been putting off your first SOP because the blank page feels like too much, this is the unlock. Try it on the most annoying repeated task on your plate and see what comes out. More on this in my AI SOP generator overview.
Don’t Overthink It
I’ll leave you with the most important thing in this whole post.
Your first SOP doesn’t need to be perfect. It needs to exist.
Imperfect SOPs that ship help your team. Perfect SOPs that live in your head help nobody. The team that writes a scrappy one-pager and updates it in six months is wildly ahead of the team that’s been “working on it” for a year.
Pick one process. Today. Capture it (record it if you can). Use the seven essentials. Test it on a stranger. Publish it. Set a review date. Done.
Welcome to the club.
Frequently Asked Questions
What is the easiest first SOP to create?
The easiest first SOP is a high-frequency, low-complexity task that takes 30 minutes or less and gets done at least weekly. Think refund processing, weekly email send, or new hire day-one onboarding - boring tasks that get asked about often. Avoid your most important or longest process for your first attempt.
How long should my first SOP be?
Most useful first SOPs are one to two pages. If you are over two pages, you are probably explaining things the reader does not need or combining multiple processes into one doc. Short, scannable, action-first SOPs get used. Long ones do not.
What are the 7 essential sections of an SOP?
Every good SOP has: purpose, scope, owner, prerequisites, steps, exceptions, and a change log. Purpose says why it exists, scope says when it applies, owner names a person, prerequisites lists what you need, steps is the procedure, exceptions handles edge cases, and the change log tracks updates.
How do I start writing an SOP if I have never done it before?
Skip the blank document. Either record yourself (or your SME) doing the process once, or talk through it out loud while taking notes. Capture first, structure second. Once you have raw material, drop it into the seven-section template and edit. Most beginners stall because they try to write from memory at a blank page.
Should I write SOPs in active or passive voice?
Always active voice. Write "Click Save" instead of "The Save button should be clicked." Passive voice hides who is responsible and makes steps harder to follow. Start every step with a verb and name the exact tool or button.
How many screenshots should an SOP have?
As many as needed for any UI-driven step. The rule of thumb: if a step involves clicking something specific in a piece of software, it should have a screenshot. Crop tight to the relevant area and annotate with arrows or boxes. Stale screenshots are worse than none, so update them when the UI changes.
Where should my SOPs live?
Wherever your team already looks for things. Notion is fine if everyone uses it. Confluence works for engineering teams. Google Drive or SharePoint works for simple folder-based access. Purpose-built SOP tools like Glitter are best when you want screenshots, search, and version history without the setup overhead.
Who should own an SOP?
A single named person, not a team or department. The owner is responsible for keeping the doc accurate and reviewing it on schedule. If the owner leaves, reassign immediately. Documents owned by "the team" are owned by nobody and quietly go stale.
How often should I update my SOPs?
Set a review date when you publish. Six months is a good default. For fast-moving things like marketing tools or software UIs, do three months. For stable processes like finance month-end, annual is fine. Put the next review date on the owner's calendar so it does not get forgotten.
Do I need fancy software to create my first SOP?
No. You can write a perfectly good first SOP in Google Docs or Notion. The benefit of purpose-built tools like Glitter is that they remove the blank-page problem - you record the process once and get a draft with screenshots in five minutes. For your very first SOP, the tool matters less than just shipping something.
