UIHike

How to write a standard operating procedure (SOP) in 30 minutes

Most SOPs die because writing them takes longer than doing the work. The fix is to write the SOP while you do the work. A practical, end-to-end walkthrough with a template and an export plan.

Standard operating procedures fail in the same way every time. Someone runs the procedure, knows it cold, and is asked to document it. They block out a half-day, sit down at a blank page, and try to remember the order of every click they did this morning. By hour two they're embellishing. By hour three they're bored. The doc that ships is part real and part wishful thinking.

Six months later, somebody else runs the procedure off that SOP. The wishful parts break. They patch the doc with a Slack message. The patch never makes it back into the SOP. The SOP is now technically wrong and nobody knows where the correct version lives.

The thirty-minute SOP starts from a different premise. The best moment to document the procedure is while you're doing it. Not after. Not in a calendar block next week. Now, one capture, one pass.

The shape of an SOP that actually gets followed

Before the timer starts, agree on what an SOP needs to contain. The pile of fields most templates ship with — owner, author, version, revision history, related procedures, compliance references, glossary — is fine for the binder compliance officers like, but the working SOP, the one someone reads at 2pm on a Tuesday because they need to do the thing, has five sections.

  1. Purpose — one sentence. Why does this procedure exist, and what outcome does running it produce?
  2. When to run this — the trigger. What event, date, request, or condition starts the procedure?
  3. Prerequisites — accounts, tools, permissions, and inputs needed before step 1.
  4. The steps — numbered, each one a single action, each one with a screenshot and a URL.
  5. Done state — how you know the procedure completed. The visible signal that the work is finished.

That's it. Owner, version, and history are metadata for the storage system, not the SOP itself.

Why writing-after-the-fact is the slow path

Three reasons SOPs written from memory take five hours instead of one.

You forget the boring middle. Step 1 is clear, step 12 is clear, but the seven small clicks between them are muscle memory. You remember the shape of the procedure, not its surface. The doc gets vague exactly where the new person needs the most help.

You skip the URLs. When you do the work, your browser knows the URL. When you write the doc, you have to dig it out of bookmarks or guess. You write “open the admin panel” instead of the literal URL because you don't want to stop typing.

You don't take screenshots, or you take too many. The half-day method usually produces zero screenshots (because you forgot) or thirty (because you took one of every page in case it was useful). Either way the doc is hard to read.

Thirty minutes, end to end

The timer starts when you decide to document. Here's how the budget breaks down.

Minute 0–5: write the frame, not the body

Open a blank doc. Write the five sections above as headers, and fill in the first three (Purpose, When to run this, Prerequisites) before you do any clicking. These are the parts you don't need the procedure open to write, because they're the meta-context.

Example:

Purpose: Onboard a new contractor to the shared Azure tenant with the minimum permissions to do billable work.

When to run this: A contract is signed in HR's system, and the contractor needs access on or before their start date.

Prerequisites: You are a Global Admin in Entra ID. The contractor has provided a personal email address. The HR ticket has the contract end date.

Minute 5–25: do the work, recording

Start a recording. Do the procedure. Don't narrate into a microphone, don't pause to write anything in the doc, don't stop to take a screenshot. Just do the work the way you'd do it on any other Tuesday.

The thing being recorded — and this is the entire pitch — is not just your screen. It's the URL at every step, the element you clicked, the visible label on that element, and the value you typed (with passwords masked automatically). Each step is a row in a structured table: screenshot + URL + element + label + value. The narrative writes itself from those rows.

When you finish the procedure — the final “Save” click, the confirmation page — stop recording. You now have a draft of the steps section. It is wrong in two or three places, every time. That's fine, you have time left in the budget.

Minute 25–30: edit the draft

Walk through the recorded steps. For each one:

  • Fix the auto-generated step title if it's wrong or useless. “Click button” becomes“Click ‘Add user’ in the Users table.”
  • Add a one-line description for steps where the screenshot alone isn't self-explanatory. Most steps don't need it. Skip those.
  • Drag a redaction box over anything sensitive — the contractor's personal email, account IDs in URLs, anything you'd rather not bake into the SOP. The original screenshot is preserved, so if you change your mind tomorrow you can just remove the redaction.
  • Delete the steps that are noise. If you opened a second tab to check something and then came back, that detour shouldn't be in the SOP.

Write the “Done state” section. One sentence.“The contractor receives a Microsoft account invitation email, accepts it, and appears in the Users table with a ‘Contractor’ tag.”

Publish. The SOP is finished.

Where to put the SOP

An SOP that lives in one place is a hostage. Compliance wants a PDF. The wiki wants a page. The new hire wants a link they can open on a phone. The auditor wants something they can attach to a form.

Here's where multi-format export earns its keep. The same recording exports to:

  • HTML — a single standalone file, drop it on a static host, share by URL.
  • Markdown — paste into Notion, Confluence, GitHub, or a Substack post. Images go inline as base64 or as separate files, your call.
  • PDF — for compliance, audit, training packets, or any binder anyone still keeps.
  • PowerPoint — when an SOP becomes part of a training session and someone wants slides.
  • Azure Static Website — for SOPs that live behind your tenant's VPN.
  • Public published link — a hosted URL like go.uihike.com/published/{UUID} with step-level comments and reactions, no login wall.

You write the SOP once. The recipients each get the shape they want. The next time the procedure changes, you re-record once and the export targets re-render from the new source.

The five-section template

Copy this verbatim for your next SOP.

Purpose
[One sentence: why this procedure exists, what outcome it produces.]

When to run this
[The trigger event, request, or schedule.]

Prerequisites
[Accounts, tools, permissions, inputs needed before step 1.]

Steps
[Numbered steps, one action each, with a screenshot and URL per step. Use the recording.]

Done state
[One sentence: how you know the procedure completed.]

Common objections, answered briefly

“My procedure isn't in a browser.” UIHike captures the browser, but it also captures region grabs, hotkey-triggered fullscreen, and document steps (PDF, Excel, Markdown). If your SOP touches a desktop app and a browser, both work in the same recording.

“My procedure has private data on every screen.” Redactions are layers, not bake-ins. Drag boxes over the private fields; the original PNG is preserved; the exported version masks them. If a different recipient needs different redactions, you re-export, you don't re-record.

“My SOP changes constantly.” That's the case the thirty-minute method is best for. The cost of re-recording is low. The cost of hand-editing a stale SOP — finding the right page in Confluence, fixing the screenshot, retyping the URLs — is the reason it never gets done.

“I need version control.” Every publish is a new revision in the backend history table. There's no user-facing timeline browser yet — the audit trail exists but the UI for browsing it doesn't — so if you need a Google-Docs-style version history, that's a gap to know about.

The first SOP to write this way

Pick the procedure on your team that gets asked about the most. The thing where someone always Slacks “hey, how do I...” and you always answer with the same five steps. Document that one first. Run the timer. See if you finish in thirty minutes.

Try UIHike on the procedure your team has been meaning to document for six months. The version that exists in your head is close enough to the real procedure that the recording will catch the corrections you'd have missed at the blank page.

— The UIHike team