How to Build Business Systems That Actually Get Used

Every business owner I meet has a drawer full of procedures nobody uses.

They paid for them. They made the team sit through training. Version 1 was printed, bound, and placed on every desk. Version 4 went into a shared drive. Version 7 became a Notion workspace. Version 9 was an AI-generated SOP library.

And in every version, within six months, the team is back to tribal knowledge and Slack DMs.

The problem isn't documentation. The problem is that documented procedures don't, on their own, become business systems. A system is something the team uses every day. A procedure is something the owner remembers writing and nobody else opens. This article is about the difference — and how to turn the second into the first.

Why most procedures die

Procedures die for one of five reasons. I've watched this movie enough times to know the plot.

1. They were written for the shelf, not the workflow. The author thought about what the procedure should contain, not how someone would actually use it mid-task.
2. They sit in a place the team never naturally goes. A Google Drive folder named "SOPs_Final_v3" doesn't get visited between client calls.
3. They stayed correct for three weeks. The software changed, the supplier updated, the team evolved, and the procedure froze.
4. Nobody is responsible for them. If everyone owns it, nobody owns it. The document rots quietly.
5. They weren't trusted in the first place. Version 1 had an obvious mistake, so the team learned the docs are unreliable, and a decade of effort can't undo that first impression.

Fix those five, and you have systems. Skip them, and you have a procedure graveyard that keeps consuming weekends.

The difference: dead SOP vs living system

A dead SOP is a document that describes how something should be done. A living system is a document plus the rhythm that keeps it accurate, plus the owner who maintains it, plus the trigger that surfaces it when needed.

Think of it like this. A car manual is not a car. A recipe is not a meal. And a procedure is not a system. The artifact matters. The practice around the artifact matters more.

When you walk into a business with living systems, you can feel it within an hour. The team references the documentation out loud. A new hire is pointed to a specific link, not to a person. When something changes, the documentation changes the same day. When a client flags a problem, the first response is "let me check the system" — not "let me ask the owner."

That culture doesn't come from better templates. It comes from five habits.

The 5 habits of systems that stay alive

If your team lives in Slack, link systems from the channel they'd need. If they live in Jira, embed systems in the ticket templates. If they live in systemHUB, the links surface naturally inside the workflow.

Rule: never force your team to go somewhere new to find a system. Meet them where they already are.

That person is responsible for the quarterly review, for updating it when the upstream process changes, for retiring it when it stops being relevant. If you cannot assign an owner to a system, the system is wrong — either it's too broad, or it doesn't actually belong in your business yet.

Fewer owned systems beats many orphaned ones, every time.

Is it still accurate? Is the owner still the right person? Has anything upstream changed that we haven't reflected?

This isn't a deep audit. It's a heartbeat. Miss the review twice in a row and the document loses credibility. Keep the heartbeat and the library stays healthy for decades.

The system is the training. If it's not good enough to train someone, it's not good enough to have.

Every time a new hire hits a snag in the documentation, the system gets fixed the same day. That's how the library stays sharp over years — the new-hire friction is the improvement signal.

Once a year, archive everything unused in the last 12 months. Your system library should get smaller as often as it grows. Lean libraries get used. Bloated ones get ignored.

Gary McMahon and the consultancy that wouldn't accept drift

 

Gary McMahon runs Ecosystem Solutions — an environmental consultancy delivering ecological assessments and regulator-ready reports. Every project involves fieldwork, data collection, analysis, and compliance reporting. High stakes, high technicality, and zero tolerance for inconsistency.

This is exactly the kind of business where dead SOPs are catastrophic. A procedure that's out of date by six months can produce a report that fails regulator review, which costs the client time and money and costs Gary his reputation.

The team at Ecosystem Solutions built their whole operation around living systems, not dust-gathering procedures. Every stage of a project — client scoping, site work, data analysis, report drafting, final review — has a documented process, a named owner, and a cadence of review. When a regulator changes a requirement, the system reflects the change before the next project runs. When a new consultant joins, they follow the documentation from day one, not shadow someone for six weeks.

The long-form interview is the clearest explanation I've heard of how a technical consultancy makes documented systems genuinely load-bearing. Worth the time if you're in any professional services firm where quality depends on consistency.

How systemHUB fits in

A lot of systems die because the tool is wrong.

Shared drives are a graveyard. You cannot tell which systems are being used, who edited what, or whether anyone has looked at a given document in the last year. So procedures get added and nothing gets retired. Five years in, you have 800 documents and nobody can find the right one.

systemHUB surfaces the four signals that keep a library honest: last updated, owner, usage, and status. Your Systems Champion can see at a glance which systems are stale, which are orphaned, and which are actually being opened. That visibility is what lets you run the quarterly review in minutes rather than days.

Then AI does what humans hate: it drafts the updates. When a supplier process changes, the LLM generates the first revision and the owner reviews. When a new system is needed, the team dictates the flow and AI structures it. The draft-to-finished time drops 70%, and the Systems Champion stops being a full-time bottleneck.

The trap: the big documentation push

Most owners try to fix the dead-SOP problem with a bigger push. A weekend where the team documents everything. A consultant who comes in for six weeks. A new platform with a bulk import feature.

None of it works. The push produces a library the day it ends, and six months later it's dust again, because the habits haven't changed.

Living systems come from steady rhythm, not from sprints. One or two systems improved each week, by the team that uses them, on the platform they live in. Boring. Slow. Compounding. Same discipline as the gym — nobody gets fit from a single hard weekend.

Systemisation is a muscle, not a project.

Where to start this week

If your library is already dead, don't rebuild it from scratch. Pick the three systems in your Critical Client Flow that matter most. Assign an owner to each. Review and fix each one this week. That's it.

In a month, three living systems in a sea of dead ones is still better than zero. In six months, you'll have fifteen. In a year, your Critical Client Flow is fully alive and the rest of the library stops mattering.

Dead systems are not a capacity problem. They're a habit problem. Build the habit and the library takes care of itself.

Ready to see which of your systems are already dead? The Systems Strength Test scores your library across nine dimensions and tells you exactly where the rot is worst. Then give your Systems Champion a home that shows last-edit, ownership, and usage — try systemHUB free.