Read summarized version with
My first SOP took four hours to write. The actual process? Six minutes.
I typed out every click. Took screenshots. Cropped them. Pasted them into a Google Doc, then fought the formatting every time it broke (and it broke a lot). The result was a 14-page document that, as far as I can tell, nobody on my team ever opened.
I’m Yuval, founder and CEO of Glitter AI. I’ve written SOPs for finance teams, support teams, ops teams, and I’ve watched plenty of them quietly die in shared drives. Writing one isn’t actually hard, though. Most people just go about it in the wrong order, in the wrong format, with the wrong tool.
So this is the guide I wish I’d had back then. Eight practical steps, a real example (an AP invoice SOP in Sage 100), and an honest take on whether to type or record.
For the bigger picture, my standard operating procedures guide handles the “what” and “why.” This post is purely the how.
Teach your co-workers or customers how to get stuff done – in seconds.
Step 1: Pick the Right Process to Document First
Don’t start with “let’s document everything.” That’s the surest way to kill an SOP project by week two.
Pick one process. Pick it on purpose. What I tell people: go for the one that’s both high-frequency and high-error.
A few questions to ask yourself:
- Which task gets done at least once a week?
- Which one does someone regularly mess up?
- Which one gets escalated to you the moment the regular person is out sick?
The overlap is your first SOP. High-frequency means the doc actually gets used, so the ROI is real. High-error means it’s solving a problem, not just ticking a compliance box.
When I was running my last company, the answer was AP invoice processing. Daily task, only one person knew the steps, and every time she went on vacation the invoices piled up. Perfect first candidate.
What NOT to start with
- One-off processes (you’ll never get ROI on the documentation effort)
- Processes that change every quarter (you’ll be rewriting it constantly)
- “Strategic” processes nobody actually executes step-by-step
Step 2: Identify the Audience and Skill Level
Almost everyone skips this step. It’s also the reason most SOPs feel either patronizing or impossible to follow.
Before you write a single word, answer three questions:
- Who’s going to read this? A new hire on day one? A backup person who already knows the system? An external auditor?
- What do they already know? Do they know what an invoice is? Can they log into Sage 100? Do they know what GL coding means?
- How much detail do they need? “Open Sage 100” works for an experienced user. A new hire needs “Click the Sage 100 icon on the desktop. Enter your username and password.”
Audience drives the writing style, the depth, the visuals - everything. An SOP aimed at a new hire and one aimed at an experienced backup are completely different documents, even if the underlying process is identical.
These days, I write for a smart person on their first day. Not their first hour (assume they can find the bathroom), but their first day. That’s the sweet spot.
Step 3: Decide on the Format
Three main formats. The right one depends on the shape of the process.
Linear / Step-by-Step
Numbered list, start to finish. Best when the process always runs the same way and has no decision points.
Example: “How to submit a timesheet.” One path, no branches.
Flowchart
A visual with decision points and branches. Best when the next step depends on the situation.
Example: “How to handle a customer refund request.” Under $50? Approve. Over $50? Escalate. Subscription? Different path entirely.
Hierarchical
Nested sections that cover a bigger process with sub-processes inside it. Best for full operational manuals or anything with multiple sub-procedures.
Example: “Month-end close” - sub-processes for AR, AP, payroll, reconciliations.
For your first SOP, default to linear. Roughly 80% of operational processes are linear, and linear is both the fastest to write and the easiest to follow. If you catch yourself writing “if this, then that” three times in a row, that’s your cue to switch to a flowchart.
For more on picking a structure, see my breakdown of SOP format options.
Teach your co-workers or customers how to get stuff done – in seconds.
Step 4: Capture the As-Is Process
This is where most SOP projects fall apart. People skip straight to writing without bothering to capture what actually happens today. What they end up writing is the idealized version of the process - the one nobody actually performs.
Three ways to capture the as-is:
Option 1: Interview the SME
Sit with the person who does the work and ask them to walk you through it. Take notes.
Pros: Fast for simple processes. Cons: People forget steps. They skip the “obvious” parts. They describe what they think they do, which is rarely what they actually do.
Option 2: Observe Over Their Shoulder
Watch them run the process live and take notes as they go.
Pros: You see what really happens, workarounds and all. Cons: Time-consuming. The person feels watched and starts behaving differently.
Option 3: Record the Process
Record their screen as they go through it once, narrating as they click. This is what I do for every SOP now.
Pros: You’ve got the source of truth on tape. Replay any step. Nothing gets forgotten. Cons: Historically meant a giant unedited video nobody watches.
That last “con” is precisely the gap Glitter closes. Record yourself doing the task once, and Glitter turns the recording into a written, screenshot-by-screenshot SOP. The recording is the source - you don’t have to translate it manually.
The honest tradeoff:
- Typing from memory or notes: ~4 hours for a 15-step process, plus the cleanup after someone says “wait, you forgot step 6.”
- Recording with Glitter: ~10 minutes to record, ~5 minutes to edit captions and add context.
Not a marketing claim. That’s literally how I write every SOP now, including the AP invoice one I’m about to walk through.
Step 5: Define Inputs, Outputs, Owner, and SLA
Before you start on the steps, fill out the metadata. New SOP writers always skip this, and it’s the difference between a document and an actual operating procedure.
Every SOP should declare:
- Owner: Who is responsible for keeping it up to date? One person. Not a team. A person.
- Inputs: What does the person need before they start? (Sage 100 access, AP inbox access, this week’s invoice batch.)
- Outputs: What does “done” look like? (All invoices entered, GL-coded, approved for payment.)
- SLA / Frequency: How often does it run, and how long should it take? (Daily, ~30 minutes per batch.)
- Trigger: What kicks it off? (Invoices arriving in the AP inbox.)
If you can’t answer these five, you don’t understand the process well enough to document it. Go back to Step 4.
Step 6: Write the Steps in Plain Language
Now, finally, you write.
Two rules. That’s it.
Rule 1: One action per step
Bad: “Open Sage 100, navigate to AP, and click New Invoice.”
Good:
- Open Sage 100.
- Click Accounts Payable in the left nav.
- Click New Invoice.
Why does it matter? Because someone following an SOP under stress reads one step, does it, then looks back at the document. Cram three actions into one step and they’ll do the first one and miss the rest.
Rule 2: Verbs first, plain words
Start every step with a verb. Click. Enter. Select. Verify. Save. Skip “you should now proceed to…” Just “Click Save.”
Avoid jargon unless your audience uses it daily. “GL code” is fine for AP staff. “Reconcile against the general ledger sub-account” probably isn’t fine for someone on day one.
For the difference between high-level SOPs and granular work instructions, I wrote a separate breakdown on SOP vs work instructions.
Step 7: Add Screenshots and Visuals
Text-only SOPs have, in my experience, a 0% adoption rate. Screenshots aren’t optional.
For every step that involves clicking, you want:
- A screenshot of the screen at that moment
- A red box, arrow, or highlight on the exact thing being clicked
- The screenshot placed right next to or below the text step
This is the piece that turns a 1-hour task into a 4-hour one when you do it manually. Screenshot, crop, annotate, paste, resize. Repeat thirty times. It’s also the piece that recording-based tools fully automate - the screenshots are captured as you record and the highlights land on whatever element you clicked.
For more on visual-first documentation, see my piece on process documentation templates.
Teach your co-workers or customers how to get stuff done – in seconds.
Step 8: Test With Someone Unfamiliar
This is the test almost every SOP fails. Mostly because almost nobody runs it.
Before publishing, hand the SOP to someone who has never done this process before and ask them to do it using only the document. Don’t help. Don’t answer questions. Just watch.
Anywhere they pause, look confused, or ask “wait, what does this mean?” - that’s a gap. Note it. Fix it.
I’ve never had an SOP pass this test on the first try. Not once. There’s always something the original writer assumed was obvious that turns out not to be obvious at all.
It’s also where you discover whether your screenshots still match the current UI, whether the system needs a permission you forgot to mention, and whether step 12 should actually be step 9.
Bonus Step 9: Version and Publish
Once it survives the unfamiliar-person test, you publish.
A few things to lock down:
- Version number: v1.0 on first publish. Bump to v1.1 for small edits, v2.0 for material changes.
- Last updated date: Visible at the top.
- Review cadence: When does the owner re-check it? Every 6 months is a reasonable default.
- Storage location: One canonical place. Not “the drive.” A specific folder, a specific tool, a specific URL.
If your SOPs live in seven different places, your team won’t use any of them. Pick a home and put everything there.
Real Example: Writing an AP Invoice Processing SOP in Sage 100
Let me walk through what this looks like end-to-end. The process: enter and code AP invoices in Sage 100.
Step 1: Pick the process. AP invoice processing. Daily, error-prone, single point of failure. ✅
Step 2: Audience. Backup AP clerk who has used Sage before but not for AP specifically. So I can skip “what is Sage,” but I do need to explain the AP-specific screens.
Step 3: Format. Linear. There’s a small branch for invoices over $5,000 (extra approval), but otherwise it’s one path.
Step 4: Capture. I sat with our AP person, hit record on Glitter, and asked her to run one batch of 5 invoices. Took her 12 minutes. Glitter turned that into a draft SOP with 28 steps and 28 screenshots. If I’d typed it from her dictation, I’d still be cropping screenshots three days later.
Step 5: Metadata.
- Owner: Sarah (AP lead)
- Inputs: Sage 100 access with AP role, AP inbox access, invoice batch
- Outputs: Invoices entered, coded, ready for approval
- SLA: 30 min per batch, run daily
- Trigger: Invoices in AP inbox
Step 6: Steps. I cleaned up the auto-generated draft. Glitter had captured every click; I rewrote a few descriptions in plainer language and added a callout for the over-$5K branch.
Step 7: Screenshots. Already done - captured automatically with the right elements highlighted.
Step 8: Test. I sent it to our office manager (never touched AP before) and asked her to process two invoices using just the SOP. She got stuck on one step where the screenshot was out of date - the UI had changed the previous week. Fixed it in 30 seconds.
Step 9: Publish. v1.0, owner Sarah, review every 6 months, lives in our process docs hub.
Total time, end-to-end: roughly 35 minutes. The same SOP, written the old way, would have eaten my entire afternoon.
Free SOP Template
If you want a starting point, grab our SOP template guide. It has a fillable structure for the metadata block (owner, inputs, outputs, SLA), a steps section, and a revision history table. Drop your process into it and you’ve already got the bones of every step in this guide.
Glitter turns a screen recording into a clean, screenshot-by-screenshot SOP in minutes - not hours.
A Few Things I Wish I’d Known Earlier
A handful of mistakes I made on my first SOPs, so you don’t have to.
Don’t write the SOP while the SME is dictating. Either record them or take rough notes and write later. Writing in real time means you’re listening at half-speed, and the SOP comes out fragmented.
Don’t include “why” in every step. Steps should tell people what to do. Save the “why” for a short context section at the top, or for callouts on the 2-3 steps where the reasoning actually matters. Most steps just need the action.
Don’t try to make one SOP cover three audiences. A new hire SOP, a backup SOP, and an auditor SOP are three different documents. Try to merge them and you get a doc that serves nobody.
Don’t underestimate decay. Software UIs change. Approval thresholds shift. People leave. Set a calendar reminder for the owner to review every SOP on a regular cadence, or your library will be 60% wrong within a year.
Wrapping Up
Writing an SOP isn’t complicated, but it does follow a sequence. Pick the right process. Know your audience. Choose a format. Capture the real process (record it - please record it). Define the metadata. One action per step. Add screenshots. Test it on a stranger. Publish with a version.
The biggest unlock for me wasn’t a writing trick. It was the shift from “type from memory” to “record and refine.” That one change cut my SOP writing time by roughly 95%.
If you want to try it, Glitter does the recording-to-SOP part for free. If you’d rather start from a blank template, the SOP template guide is the fastest path to a clean structure.
Either way: write the first one this week. Pick the highest-frequency, highest-error task on your team. Document it. Test it. Ship it. The second one will take half as long.
Yuval / Founder & CEO, Glitter AI
Frequently Asked Questions
How do I write an SOP step by step?
Follow eight steps: (1) pick a high-frequency, high-error process, (2) identify your audience and their skill level, (3) choose a format (linear, flowchart, or hierarchical), (4) capture the as-is process by interviewing, observing, or recording, (5) define inputs, outputs, owner, and SLA, (6) write each step in plain language with one action per step, (7) add screenshots and visuals, and (8) test with someone unfamiliar before you publish.
How long should an SOP be?
An SOP should be as long as the process requires and no longer. For a typical operational task, 1-3 pages with screenshots is the sweet spot. If your SOP is over 10 pages, it likely covers multiple processes and should be split, or it includes too much background that belongs in a separate context document.
What is the difference between writing an SOP and writing a work instruction?
An SOP describes the overall process at a high level (what gets done, by whom, in what order). A work instruction is a granular, step-by-step procedure for executing one specific task within that SOP. SOPs answer 'what is the process,' work instructions answer 'how do I click through this exact screen.'
How long does it take to write a standard operating procedure?
Writing an SOP from scratch by typing usually takes 2-4 hours for a 15-30 step process, mostly spent capturing screenshots and editing formatting. Using a screen recorder that auto-generates the SOP draft (like Glitter) cuts that to 10-30 minutes including review.
Should I write SOPs in first person or third person?
Use second person imperative voice: 'Click Save,' 'Enter the invoice number.' First person ('I click Save') is awkward, and third person ('The user clicks Save') feels like a manual rather than a guide. Second person imperative is direct, scannable, and easier to follow under stress.
How do I create an SOP if I am not the subject matter expert?
Don't try to write it from the outside. Either record the SME doing the task (best option), interview them while they walk through it, or observe over their shoulder. Then draft from your capture and have the SME review for accuracy before you test with an unfamiliar person.
What format should I use to write an SOP?
Default to a linear step-by-step format for most operational SOPs (about 80% of cases). Use a flowchart format if the process has multiple decision points, and a hierarchical format for complex processes with sub-procedures like a month-end close. Pick the format that matches the actual shape of the process, not the format that looks fanciest.
How often should SOPs be reviewed and updated?
Set a default review cadence of every 6 months for active SOPs and every 12 months for stable ones. Also trigger an immediate review whenever the underlying software changes, the process owner leaves, or you find a step that no longer matches reality. Assign one named owner per SOP - not a team - to keep it current.
Do I need screenshots in my SOP?
Yes - for any SOP involving software, screenshots are essentially required for adoption. Text-only SOPs have very low adoption rates because users have to translate written steps into visual actions in real time. Pair every click step with a screenshot showing exactly where to click.
What is the best tool to write an SOP in 2026?
For typed SOPs, Google Docs and Notion both work well as homes for the final document. For the actual writing process, screen-recording tools that auto-generate step-by-step guides (like Glitter) cut SOP creation time by roughly 90% compared to manual screenshot-and-paste workflows. The best tool depends on whether your bottleneck is writing speed or distribution.
