How short should a process document actually be?

Most small business processes can be documented cleanly in 1-2 pages. Complex workflows with multiple handoffs might reach 3 pages. Beyond that, the right move is usually breaking the document into linked sub-documents, each covering one phase. 20-page SOPs are almost always a sign of under-thinking the structure, not a sign of genuine complexity.

What's the cheapest way to write processes in practitioner language?

Record a 20-minute conversation with the practitioner explaining the work. Transcribe it (AI can do this instantly). Structure the transcript into headed sections. The result is already in practitioner language because the practitioner spoke it. Owner-written documents inevitably drift toward owner language; practitioner-sourced documents stay in practitioner language.

How do I know if a process is getting adopted?

Three signals. First, team members reference it in conversation. Second, new hires find their own answers in the first week without asking the owner. Third, when you audit the document, it's been edited recently to reflect changes in the work — adopted documents get updated, because people are using them and noticing gaps.

What's the single biggest red flag that a process document won't get used?

It was written by someone who doesn't actually do the work, without consulting the person who does. Owner-written SOPs with no practitioner input are the single most common pattern for unadopted documentation. The practitioner reads it, recognises it doesn't match what actually happens, and mentally discards it. Collaborative co-authoring solves this almost completely.

How to Create Better Business Systems (And Processes That Get Used)

Every small business has a file full of documented processes that nobody uses.

The owner wrote them. Or paid a consultant. Or assigned the operations lead to do them. They live in a shared drive somewhere. They're thorough. They're well-formatted. They're comprehensive. And they're also completely ignored, because the team runs on memory and informal conversation the same way they did before the documents existed.

This is the single most common failure pattern in small business systemisation. Documents are the easy part. Adoption is the hard part. A 40-page SOP that nobody opens is categorically worse than a one-page document the team actually references, but most owners invest in the first kind and wonder why nothing changed.

This article walks through five specific principles that separate processes that get used from processes that sit in drawers. Each one is a design decision, not a motivation exercise.

Why most documented processes fail to get adopted

Three structural patterns.

They're too long. A 20-page SOP takes 30 minutes to read and feels like homework. Team members open it once, close it, and don't come back. Short documents — one to three pages — get read, get referenced, get used. Length is inversely correlated with adoption.

They're written in owner language. The document uses terminology and framing that makes sense to the person who wrote it but doesn't match how the practitioners talk about the work. Team members read the doc and mentally translate it into their own language, which is exhausting, so they stop reading.

They solve the wrong problem. Many documented processes answer "how should this work ideally?" when the team's actual question is "how do I handle this specific situation?" Idealised process documents don't help in the moment of need. Practical, situation-specific guidance does.

Fix all three by designing the document for the reader, not for the writer.

The 5 principles that make processes get used

1. Keep it short enough to read in 5 minutes. A process document over 3 pages starts to fail on length alone. If the process genuinely requires more detail, break it into several shorter linked documents, each readable in 5 minutes. The team opens short documents, scans them, and uses them. Long documents get bookmarked and abandoned.

2. Write in the language the team already uses. Before writing the document, watch or listen to the practitioner doing the work. Use their vocabulary. If they call it "client intake," don't write "customer onboarding process v2" — write "client intake." Practitioner language is adoption language; owner language is abandonment language.

3. Structure around moments of need, not idealised flow. Team members reach for documents when they're stuck on a specific task or facing a specific decision. Structure the document so the answer to their current question is findable in 15 seconds. A well-named heading, a clear "when this happens, do this" section, a quick reference table — whatever makes the specific moment solvable fast.

4. Link to the document from where the work actually happens. If the document lives in a shared drive the team only visits occasionally, it's invisible. Link it from the project management tool, the email template, the calendar invite — wherever the team is when they need the process. Proximity to the moment of need drives adoption more than any amount of training does.

5. Build the document collaboratively with the practitioner. A document written TO the practitioner gets used less than a document written WITH the practitioner. The co-authoring produces better content (the practitioner knows things the owner doesn't) and stronger adoption (co-authored documents have the practitioner's skin in the game). Solo-authored SOPs are adoption disasters; collaborative ones usually land.

Five principles. Each one a specific design choice. Together they separate processes that genuinely change behaviour from processes that sit in drawers regardless of how thoughtfully they were written.

The adoption diagnostic

Walk one of your existing documented processes through five quick questions:

Can a team member read it in under 5 minutes?
Does it use the language the team actually uses on the floor?
Can they find the answer to a specific situational question in 15 seconds?
Is it linked from where the team works, not buried in a folder?
Was it co-authored with the practitioner who runs the work?

If the answer to any is no, that's where the adoption gap is. Most documented processes in small business fail 3-4 of these questions. The fix is usually straightforward once the diagnosis is clear — rewrite shorter, in practitioner language, structured around moments of need, linked from the work context, with the practitioner as co-author.

Most owners, when they run this diagnostic, realise that "the team isn't using the processes" is actually "the processes weren't designed for use." Fixing the design fixes the adoption.

What adopted processes actually look like

The pattern in businesses where processes genuinely drive behaviour:

Documents are short, named in the team's vocabulary, organised by situation rather than by idealised flow. They live where the work happens — linked from project tools, referenced in meetings, quoted in team discussions. Team members open them without prompting because opening them is faster than trying to remember what to do. New hires navigate the library in the first week because the library is findable and readable.

Businesses where this holds produce noticeably better operational consistency than businesses where it doesn't. The processes aren't fancier; they're more usable. And the difference compounds. Six months of adopted processes produces more operational improvement than six years of unadopted ones.

The quiet shift

The shift that matters isn't from undocumented to documented. It's from documented-but-unused to documented-and-adopted. Most small businesses stall at the first shift thinking they've done the work. The second shift is where the actual operational improvement lives.

Owners who recognise this focus their systemisation effort on adoption design, not just documentation volume. Fewer documents, better designed for use, produce more behavioural change than comprehensive documentation that nobody opens. The Systems Champion role, when it exists, is largely about owning the adoption layer — the document design, the language fit, the linking infrastructure, the collaboration with practitioners. The documentation is table stakes; the adoption is the work.

Ready to audit your existing process library for adoption? Run the five-question diagnostic on your three most important documents this week. The results usually surface the specific redesigns that would unlock adoption. Document the revisions and house them in a systemHUB free trial — one of the platform's main features is surfacing edit dates, usage, and ownership, which makes the adoption layer visible as a first-class concern.