Process Documentation Writer (SOPs)

When to use

Triggers:

• "Write an SOP for [process]" / "Document this process"
• "Process map" / "Workflow documentation"
• "Handover doc" / "Onboarding document for [role]"
• "I'm training someone on X" / "New hire needs a doc for Y"
• "How do we document [what we do]?"

Don't fire for:

• Meeting notes (use meeting-notes-to-action-items)
• Technical API documentation (use api-documentation-generator)
• Customer-facing help docs (different audience, different voice)
• Strategic planning documents (not a process)

Why most SOPs fail

Common SOP failures in AU SMEs:

1. Too generic — "Answer phone professionally" without saying what "professionally" means
2. Too detailed — 80 pages that nobody reads
3. Written once, never updated — the process changes, the doc doesn't
4. Written by the wrong person — the manager who thinks they know the process, not the operator who runs it daily
5. Nested so deep — live in SharePoint > folder > subfolder > doc nobody can find
6. No success criteria — "complete the task" doesn't say what "complete" means

The fix isn't "write more thoroughly". It's "pick the right level + the right fields + the right maintenance".

The 3 levels of detail

Different processes need different formats. Pick one per document.

Level 1 — Overview (the map)

When: for onboarding someone to the landscape, not a specific task. "Here's how our accounts-payable process works at a high level."

Format: 1–2 pages. Prose + a diagram/flowchart. Names the handoffs, not the clicks.

Length: 300–600 words.

Example use: New hire orientation week, annual process review, handover of a department.

Level 2 — SOP (the procedure)

When: for executing a specific task the same way every time. "Here's exactly how to process an invoice in Xero from receipt to approval."

Format: 1–3 pages. Step-by-step with screenshots or specifics.

Length: 400–1200 words.

Example use: Training a bookkeeper, standardising order-processing across team, compliance audit evidence.

Level 3 — Checklist (the execution)

When: for fast-running repeatable tasks where someone knows the overall process but needs a safety-net list. "Items to check before publishing a blog post."

Format: 1 page max. Bulleted, tickable list.

Length: 50–200 words.

Example use: Daily/weekly ritual checks, quality gates, pre-flight checks.

One process can have all three — the overview for orientation, the SOP for training, the checklist for daily execution.

The 10 fields every SOP needs

For Level 2 (SOP) specifically, include:

1. Process name — clear, searchable
2. Owner — who maintains this doc (not who does the task)
3. Audience — who follows it (role, seniority, assumed prior knowledge)
4. Trigger — when is this SOP used? ("every Tuesday at 9am", "when a new client is onboarded", "when invoice >$5k arrives")
5. Prerequisites — what must be true/ready before starting (access, info, tools)
6. The steps — numbered, concrete, no "etc." or "and so on"
7. Decision points — explicit branches ("if customer is GST-registered, do X; if not, do Y")
8. Tools used — specific software, specific URL, specific account
9. Success criteria — what "done" looks like (a specific output, a state change)
10. Escalation / exception path — what to do if a step fails or an unusual case comes up

Missing any of these = the SOP has a hole a new operator will fall into.

SOP template

# [Process name] — SOP

**Owner**: [Role / name]
**Last reviewed**: [Date]
**Review cadence**: [Monthly / quarterly / annually]
**Audience**: [Role / level of experience assumed]

## When to use this SOP

This SOP applies when: [trigger event]

It does NOT apply when: [exclusions — common edge cases that need different handling]

## Prerequisites

Before starting, you need:
- [Access / permissions]
- [Information / inputs]
- [Tools / software / logins]

## Steps

### 1. [Step title]
[What to do, 1–3 sentences. Reference specific tool / screen / field.]
[Screenshot if helpful]

### 2. [Step title]
...

### 3. If [condition], do this
[Branching logic explicitly called out]

### 4. Otherwise, do this
...

## Success criteria

The process is complete when:
- [Specific output exists — invoice posted, email sent, record updated]
- [Specific state change — "Done" status set, customer notified, colleague signed off]

## Common exceptions

| Situation | What to do |
|---|---|
| [Edge case 1] | [Response] |
| [Edge case 2] | [Response] |

## Escalation

If you get stuck or something unusual happens, escalate to [role / person] via [channel] before [deadline — e.g. "end of day"].

## Related processes

- [Upstream process that feeds into this one]
- [Downstream process that depends on this being complete]

How to write an SOP that actually works

Step 1 — Watch someone do the task

If you're documenting someone else's work, sit with them while they do it. Screen-record if they're on a computer. Note every click, every sub-decision. Your first draft is a transcript of what you saw, not what you thought they'd do.

If you're documenting your own work, do it live — open the tool, walk yourself through it, note what you actually did.

Step 2 — Write the draft

Fill the template. Resist the urge to make it "best practice" — document what actually happens, not what should happen. (You can fix the process after documenting it; you can't improve a process you've never written down.)

Step 3 — Pilot test

Hand the draft to someone who HASN'T done this task. Watch them follow it. Don't help unless they're genuinely stuck. Note:

• Every place they paused to figure something out
• Every place they asked a question
• Every step they interpreted differently from what you meant

Those are the gaps in your SOP.

Step 4 — Revise

Fill the gaps. Add the missing prerequisites. Clarify the ambiguous step. Add the edge case you missed.

Step 5 — Commit to maintenance

Schedule a review cadence (usually quarterly for stable processes, monthly for volatile ones). Owner gets a calendar reminder.

Where to store SOPs

The storage matters as much as the content. Options:

• Notion / Confluence / Coda — rich formatting, good search, version history. Good default for most SMEs.
• Google Docs in a shared folder — fine for small operations; search can get weak at scale
• SharePoint — works if you're committed to M365; permissions fiddle
• A wiki tool (BookStack, Outline) — self-hosted option; more setup

Worst options: attached to emails, on a single person's desktop, in a channel in Slack that scrolls away, in a PDF that was exported once and never updated.

Rule: one place, with search. If people can't find it, they'll invent their own process.

Process mapping (visual flowcharts)

For complex processes with multiple actors and branches, a flowchart beats prose. Use:

• Mermaid (markdown-compatible, lives with the SOP in the same tool)
• Miro / Lucidchart (for collaborative mapping; link to SOP)
• Draw.io / diagrams.net (free, export to PNG for the SOP)

Keep it simple. 10 boxes and 15 arrows is usually the right size. 40 boxes is a sign the process needs simplifying, not a bigger diagram.

Maintenance

An SOP that's 18 months out of date is worse than no SOP — it actively misleads.

Cadence:

• Volatile processes (tech stack changes, frequent policy updates): monthly review
• Stable processes (standard bookkeeping, core HR processes): quarterly
• Infrastructure-level (incident response, BCP): annually + after each incident

Each review asks:

• Has the process changed since last review?
• Are any steps now obsolete?
• Are there new steps to add (tools changed, compliance changed)?
• Did anyone hit a confusion point we should address?

Update the doc. Increment the review date. Move on.

SOPs for small teams (<10 people)

Not every SME needs formal SOPs for every task. You probably need SOPs for:

• Anything your business couldn't run without — if the person doing it got hit by a bus, this needs a doc
• Anything where mistakes are expensive — compliance, payments, customer data
• Anything you want to hand to someone new — onboarding, delegating, contractor work
• Anything that's audited externally — tax, NDIS, Fair Work, industry certifications

You probably don't need SOPs for:

• One-off creative tasks — they're not repeatable
• Things only the founder does until you're ready to hand them off
• Processes that are still rapidly evolving — document them once they stabilise

Output format

Per request:

1. The SOP itself — markdown, per the template, ready to paste into your doc tool
2. A validation checklist — 5 questions to ask someone piloting the SOP
3. A review-schedule entry — calendar reminder text (owner + cadence + first review date)
4. Process-map sketch (if relevant) — described in Mermaid or as a structured list for you to draw

What this skill does NOT do

• Do the process for you. SOPs document process; execution is separate.
• Replace training. A great SOP + a 30-min walkthrough beats either alone.
• Auto-discover your processes. You (or someone who does the work) has to know what happens.
• Handle complex change-management. Rolling out an SOP change across 100 staff is a project, not a doc.

Tier access

Base. Universal SME need. Pro-tier adds a pilot-test review cycle with a THL advisor.

Related skills

• meeting-agenda-builder — many processes start with a meeting that needs a template
• xero-myob-month-end-close — example of a process that benefits from SOP-level detail
• fair-work-compliance — people-process documentation overlaps with compliance
• au-privacy-act-compliance-audit — privacy-sensitive processes need explicit documentation

References

• Atul Gawande — The Checklist Manifesto
• Michael Gerber — The E-Myth Revisited
• Notion — SOP templates