What's the single biggest naming mistake small businesses make?

Using language that makes sense to the owner but not to the team. The owner writes 'Client Onboarding Master Process v3' and the team searches for 'new client welcome.' The library appears thorough and feels empty. The fix is to name every system in the language the practitioners actually use when they talk about the work. If you're not sure, ask three practitioners what they'd call the system — their answer is usually closer to the right name than the owner's answer.

Should system names include version numbers?

Usually yes, but subtly. A name like 'Client Intake v2 (post-AI-revision)' signals the team that they're looking at current work, not a 2022 artefact. Names without version signals allow teams to drift into quiet distrust of the library — they're never sure if they're reading the current version. Trust in the library is a huge adoption driver. Version signals cost almost nothing and pay back in trust.

How long should a system name be?

Long enough to be unambiguous, short enough to scan. Usually six to ten words. 'Client Intake' is too short (which intake, for which product, owned by whom). A 20-word fully-versioned SOP title is too long (nobody will read this or type it). 'New Client Intake (Sales-owned, v2)' sits in the right range — short enough to scan, specific enough to distinguish.

Does naming matter if we only have 10 systems?

Less, but still meaningfully. At 10 systems a bad library can still be navigated by memory. At 30 systems it can't, and the team starts either memorising the library's quirks (expensive) or avoiding it entirely (more expensive). The discipline is cheaper to install at 10 systems than at 30, because you're only renaming ten things. Waiting until the library is large makes the retrofit painful. Install the naming convention early — it's the cheapest insurance policy against library decay.

7 Ways Naming Your Systems Gives Them Power

The most under-appreciated decision in systemisation is what you name each system.

Not the flashy branding kind of naming. The practical kind. The exact words you pick for each documented process in your library — the words the team types into the search bar when they need the system, the words that appear in training materials, the words that distinguish the revenue-critical system from the one that doesn't really matter.

Owners spend weeks documenting a system and ten seconds naming it. That ratio is backwards. A mediocre document with a perfect name gets used every day. A brilliant document with a bad name sits in a folder no one opens. Names are the difference between a library of systems and a pile of paperwork.

This article walks through seven specific ways that naming your systems well gives them power — findability, trainability, ownership, prioritisation — and the naming mistakes that silently kill adoption in most small business system libraries.

The 7-stage SYSTEMology process — each stage is itself a naming discipline, from defining your Critical Client Flow through to optimising the final library. — The 7-stage SYSTEMology process. The naming discipline runs through every stage.

Why most small business system libraries have bad names

Three patterns dominate.

Names the owner invented, not the team. The owner writes the system and names it using language that makes sense to them. The team searches using different words and never finds it. The library appears well-stocked and feels empty. This happens in almost every library that's documented without the practitioners in the room.

Names too generic to distinguish. "Customer Onboarding Process" and "Customer Onboarding Flow" and "Client Welcome Procedure" all live in the same library, and nobody's sure which one to open when. Generic names produce duplicate systems, which produce inconsistent execution, which defeats the purpose of systemising in the first place.

Names that describe the output instead of the trigger. A system named "The Invoice" is findable if you know what the output is. A system named "When A Project Delivers, This Runs" is findable by anyone who knows the trigger. Trigger-based names catch the team at the moment they need the system — which is almost always the moment they're about to do the thing, not the moment they're searching for a past output.

Fixing all three is what lets a system library go from "documented but unused" to "the team's default reference."

The 7 ways naming gives systems power

1. Findability. A system named the way the team searches is a system the team uses. Names should match the spoken vocabulary of the people doing the work, not the formal vocabulary of the owner or a consultant. Test the name by asking three team members what they'd type into the search bar when they need that system. If their answers don't include the name, rename it.

2. Training compression. New hires who can navigate the library by intuitive names ramp dramatically faster than ones who have to learn the library's internal logic first. A well-named library is self-training. A badly-named one requires a human guide, which is exactly the dependency systemisation was supposed to remove. (See hiring for a systemised business for why this matters disproportionately during rapid growth.)

3. Ownership clarity. When systems are named consistently, it becomes easier to see gaps in ownership. "Client Intake (Sales-owned)" and "Client Onboarding (Ops-owned)" make the handoff visible in the name itself. Ambiguous names produce ambiguous ownership, which produces work that falls between the seams.

4. Priority signalling. Critical systems should be named in a way that signals importance. A prefix, a label, a folder location — something that tells the team at a glance which systems are foundational versus supportive. The library's visual hierarchy is a naming choice as much as a structural one.

5. Version control. Names that include iteration signals (v2, 2026 update, post-AI-revision) let the team trust that they're reading the current version. Libraries without this drift toward stale documentation the team quietly stops trusting. Trust in the library is largely a naming convention outcome.

6. Relationship mapping. Systems rarely run in isolation. A good naming convention makes relationships visible. "Weekly Team Huddle" and "Weekly Team Huddle: Agenda Template" and "Weekly Team Huddle: Follow-up Actions" read as a cluster because the names do the linking. Bad names fracture what should feel connected.

7. Cultural signalling. The language of your system names signals your operating culture. Warm, clear, human names ("How we welcome a new client") feel different from bureaucratic ones ("Client Onboarding Process v2.1 — Standard Operating Procedure"). Neither is categorically better, but the choice sends a signal to the team about how systematic work is meant to feel. Most small businesses benefit from the human version; the enterprise version produces a library that feels like homework.

Seven ways. Each one affects adoption. Collectively they separate libraries that get used from libraries that gather dust.

Shannon Smit and the naming discipline at SMART Business Solutions

Shannon Smit on Finance Systems & AI at SMART Business Solutions — specialist transfer-pricing work scaled through disciplined systemisation, including the often-overlooked discipline of naming systems well. Read the full case study

Shannon Smit runs SMART Business Solutions — an Australian accounting and advisory firm with a specialised niche in transfer pricing (the tax treatment of cross-border transactions between related companies). The work is high-stakes, compliance-heavy, and often urgent.

Professional services is one of the most revealing places to watch naming discipline play out. In a 20-person accounting firm, the difference between a system the team finds in 10 seconds and one they search for 90 seconds compounds into hours per week per person. Multiply that by dozens of team members over years, and the cost of bad naming is enormous — usually invisible on the P&L because nobody books "time lost to searching" as a line item.

Shannon's team, working with their Systems Champion, has treated naming as a first-class discipline. Every system has a name that matches how the team actually talks about the process. Trigger-based names ("When a new international tax engagement lands, this runs"). Ownership-embedded names. Version signals. Priority flags. The library is legible at a glance, which is why a growing team can navigate it without a human guide.

The result, visibly: new accountants ramp faster, complex engagements run more consistently, and the firm can handle transfer-pricing work at a throughput that competitors struggle to match. A lot of the underlying advantage is operational discipline broadly — but the specific compound gain from naming discipline within that broader operation is hard to overstate.

How to install a naming convention that sticks

1. Write the convention down. One page. Title format, owner label, version signal, trigger prefix, priority marker. The team should be able to name a new system correctly without asking anyone.

2. Rename the existing library against the convention. Most libraries have accumulated naming drift over years. Block two hours with your Systems Champion and rename everything. Painful in the moment; transformative thereafter.

3. Enforce on every new system. New systems that don't follow the convention get renamed before they go live. No exceptions. One drift becomes twenty within a quarter.

4. Quarterly naming audit. Once a quarter, walk the full library and flag any names that have drifted. Rename or retire them. Fifteen minutes quarterly. Prevents the slow decay that kills most libraries over two to three years.

Four moves. None of them require software. All of them require a Systems Champion with the discipline to treat names as a first-class concern rather than a last-minute label.

The discipline

The discipline is specific. When a new system is being documented, the practitioner and the Systems Champion together ask: "what would you type into the search bar to find this in six months?" That answer — or very close to it — is the name.

If there's disagreement in the room, the practitioner wins. They're the one who'll be searching. Owners and Systems Champions routinely name systems in language that makes sense to them and turns out to not match how the team searches. The practitioner's instinct is almost always closer to the right name.

Test the name against the library after naming it. Search for it. Can you find it quickly? Is it distinct from similar systems? Does the name make the trigger and owner obvious? If any answer is weak, rename before publishing.

Ten minutes per system on naming, compounded across a library of 50-100 systems, is the difference between a library that gets used and one that doesn't. It's the smallest, highest-leverage discipline in small business systemisation — and the one most commonly skipped.

How much are bad names costing you? Owner Dependency Score

Un-findable systems force the team to route through the owner. 10 questions, 5 minutes — tells you how much of that friction is currently hiding in your library.

Ready to audit your library's naming? Start with the Owner Dependency Score to see how much your team still has to route through you for basic operational questions — a bad-library-naming signal in disguise. Then clean up the library with a systemHUB free trial.