Where Your Documentation Should Live (So People Actually Find It)

Most small businesses don't have a documentation problem in the sense they think. They have documents. The documents are in a shared drive, or three shared drives, plus some in email, plus one important one in someone's personal notes.

A correctly written SOP nobody can find is the same as no SOP — except it also cost you the time to write it.

Link from the trigger, not just the library

This is the highest-value thing in this article, and it beats any amount of folder structure.

Put the link where the work happens.

• In the project template, on the task itself
• In the CRM stage that triggers the process
• Pinned in the channel where that work gets discussed
• In the calendar invite for the recurring meeting
• In the ticket type, the form, the recurring reminder

Someone about to do a task should encounter the documentation without having to remember it exists and go looking. A mediocre document that appears at the moment of need beats an excellent one filed correctly.

The library still matters — it's where things live and get maintained. But discovery should mostly happen at the point of use.

Organise by work, not by org chart

Departmental folders — Sales, Marketing, Finance, Ops — feel natural and age badly. Roles get merged, one person covers three areas, and half the processes touch more than one department.

Organise by the work being done:

/ Getting customers      enquiry handling, discovery, proposals, follow-up
/ Delivering work        onboarding, the delivery process itself, handover
/ Getting paid           invoicing, chasing, reconciliation
/ Running the business   reporting, review cadence, planning
/ People                 hiring, onboarding, the recurring conversations
/ Systems                tool access, backups, security rules

That structure survives reorganisation, because the work is more stable than the arrangement of people around it.

Keep it shallow. Two levels maximum. Anything three folders deep won't be found, and depth is usually a substitute for good titles rather than a solution to anything.

Write titles for what people would search

Past roughly thirty documents, search does more work than hierarchy. Nobody browses.

Titles should match the words someone would actually type:

| Poor title | Better | |---|---| | Client Onboarding Documentation v2 | Onboard a new client | | Q3 Process Update — Finance | Reconcile the month end | | Guidelines | What we can expense without asking |

Use the verb form of the task. And drop version numbers from titles — versioning belongs in the document's history, not its name, or you end up with three files and no idea which is current.

One home per document

The single most damaging pattern: the same process documented in two places.

It happens innocently — someone can't find the original, writes a new one, and now there are two. They drift. Somebody follows the stale one. After that happens once, people stop trusting any of it, which is a much larger problem than the original missing document.

Two rules:

• One canonical location. Everywhere else links to it — never copies it.
• When you find a duplicate, delete one immediately. Don't merge later; later doesn't arrive.

The same logic applies as elsewhere on this site: one asset, one home, cross-linked.

Give every document a header

Four lines at the top, every time:

OWNER:        [named person]
LAST REVIEWED: [date]
APPLIES TO:   [who runs this]
RELATED:      [links]

The owner and review date are doing the real work. A document with no owner is nobody's job to maintain, and a document with no review date gives the reader no way to judge whether to trust it. Both are the mechanics behind keeping documentation from rotting.

Choosing a tool

Less important than people expect. What matters:

• Search that works, including inside document bodies
• Easy editing — if updating requires a request, documentation goes stale
• Linkable — every document has a stable URL you can paste into a task
• Version history so you can see what changed

A shared drive with a disciplined structure beats a sophisticated wiki nobody maintains. And the switching cost is real, so the ideal number of times to migrate is once.

Don't split across tools. Some SOPs in a wiki, some in the project tool, some in a drive is the same problem as duplicates — nobody knows where to look, so they ask you instead.

Measure it by the questions you get

The honest test of a documentation system isn't how complete it looks. It's whether people still ask you things it already answers.

When that happens, the reflex is to conclude nobody reads the documentation. Usually it's one of three things, and all are fixable:

• They didn't know it existed → link it from the trigger point
• They couldn't find it → fix the title
• They found it and it was wrong or stale → fix the review cadence

Treat each repeated question as a defect in the system rather than in the person. That single reframe is what turns a document dump into something that reduces your workload.

The mistakes

1. A library with no links from the work. Correct, filed, unread.
2. Departmental folders. They age out with the first role change.
3. Deep hierarchies. Nobody goes three folders down.
4. Version numbers in titles. Three files, no clear current one.
5. Duplicates left to drift. One stale copy destroys trust in all of it.
6. Split across tools. People give up and ask you.

What to do next

Pick the process you get asked about most and do one thing: put a link to its documentation at the exact point where the work starts — the task template, the CRM stage, the pinned message.

Then count how many times you get asked about it over the next month. That number is the only real measure of whether the system works.