Files, documents and the client's second brain

Adaeze's Drive has 1,140 files in it. There is a folder called "New folder". There is a folder called "New folder (2)". There is a file called Final.docx, a file called Final v2.docx, and a file called Final v2 ACTUAL.docx. She has been finding things by typing a guess into search and scrolling.

This is not disorganisation as a character flaw. It is what happens to every Drive that nobody was ever specifically responsible for. Files accumulate the way post accumulates on a hallway table — each one reasonable on its own, ruinous in aggregate.

A good structure is not the one you understand. It is the one a stranger understands in ten seconds, on the worst day of her practice, looking for one thing.

Design for the emergency, not the ordinary day

Here is the test that should govern every decision in this lesson. Imagine Adaeze is mid-session, a client's insurance company calls demanding a report right now, and you are unreachable. Can she find it in one click from the top level? If the honest answer is "she'd have to ask me", the structure has failed, however elegant it looks to you.

Organise by what the business does, not by what a computer does

The single most common mistake is structuring folders the way software categorises things — by file type, by month, by who uploaded it. That reflects how a computer thinks. Nobody hunting for a specific client's insurance letter thinks in file types; they think in who or what.

Five to seven top-level folders, no more

This is the number that matters most in the whole lesson. More than seven top-level folders and a person scanning the list has to read every label before deciding; five to seven is roughly what a glance can hold. If you find yourself wanting an eighth, it usually means two of your existing folders should merge, or something belongs one level deeper than you are trying to put it.

Notice the numbers in front of each name. That is deliberate, and it is the second habit worth adopting: a leading number forces the folders to sort in the order you decided, not alphabetically — which matters because "Clients" should sit above "Templates" regardless of what the alphabet thinks, since it is where almost every search actually starts.

Depth: three levels, almost always

Beneath each top-level folder, one more layer for the specific thing, and a third only when a specific thing genuinely has parts. A fourth level is where structures go to die — by the time something is four folders deep, nobody remembers the path, including you.

Archive is not the bin — it is memory

When a client stops, or a tax year closes, or a template gets replaced, the instinct is to delete. Do not. Move it to Archive and keep it. A client who returns eighteen months later, an insurance query about a session from last year, a tax audit — each of these is a question only the archive can answer, and each arrives without warning. Deleting is a decision you can never take back; moving to Archive costs nothing and can always be undone.

A perfect folder structure still fails if the files inside it are named Untitled document, Scan_003.pdf and copy of copy of form.docx. Most people find files by searching, not by browsing — so the name is doing more work than the folder it sits in.

The four things a good file name answers

A name should let someone identify a file from the list view alone, without opening it. That means it answers, in order: what is this, who or what is it about, and when. Leave any of the three out and the file becomes identifiable only by opening it — which is the exact failure a good name exists to prevent.

Dates go first, and they go one way

Always YYYY-MM-DD, at the very start of the name. Two things ride on this small habit. First, files then sort into true chronological order automatically, in any file browser, without anyone doing anything — the computer's alphabetical sort and calendar order become the same sort. Second, it removes the ambiguity from lesson 3.1: 03-09-2026 reads as 3 September to one reader and 9 March to another, but 2026-09-03 reads the same way to everyone, everywhere, forever.

If the file is not date-specific — a template, a standing document — drop the date rather than fake one. A false date is worse than none.

Words a search can actually match

Search matches text, not intention. A file called Final.docx cannot be found by searching "insurance" even though that is exactly what it is. Put the client's name, the subject, and any reference number a person might actually type into the name itself. MedSupply — invoice 2291 is found by searching "MedSupply", "invoice", or "2291" — three separate paths to the same file, versus zero for invoice.docx.

What to avoid

• "Final", "final final", "v2", "latest". These are meaningless within a week and actively misleading within a month — there is always eventually a file more final than the one called Final. Lesson 4.3 gives you the actual alternative.
• Special characters — / \ : * ? " < > | — which some systems reject outright and others silently mangle. A dash or an underscore does every job a slash was doing.
• Names longer than about eight or nine words. If it needs more, the extra detail belongs inside the document, not in its name.
• Client names abbreviated inconsistently. "Chinelo O", "C. Okafor" and "Chinelo Okafor" are three different search results for the same person. Pick one form and use it forever — full name, same order, every time.

Adaeze has sent the same intake form to nineteen new clients, and every single one is a document she built from scratch by editing an old one — changing the name, forgetting to change something else, occasionally sending someone else's session notes by mistake because she started from the wrong file. This is not a formatting problem. It is a system with no template in it.

Turn anything sent more than twice into a template

The rule is exactly that simple. The intake form, the fee agreement, the end-of-session note, the standard email attachment — anything Adaeze produces more than twice becomes a template: built once, properly, and reused rather than rebuilt.

Most document tools have a real "Template" file type, and it is worth using rather than faking. A true template opens as a fresh, untitled copy every time — nobody can accidentally edit and save over the master, which is precisely the failure mode you are trying to close. If your tool has no template type, keep the master in Templates/, marked read-only, and always duplicate before editing. Never open the master and start typing.

Version control that needs no extra software

You do not need Git or paid version-history tools for this. You need one naming convention, used without exception, plus the version history every major document tool already keeps automatically and almost nobody opens.

Four words — draft, for review, approved, superseded — replace every ad-hoc "v2", "v3" and "FINAL FINAL" you have ever seen, and unlike those, each one tells you something true about the file's actual status the moment you read the name.

Built-in version history is usually enough

Google Docs, Word Online and most modern tools keep every saved version automatically, viewable from a "version history" or "see edit history" menu, with the ability to name a version and restore an earlier one. Learn where that menu lives in whatever tool your client uses — it is usually enough on its own, and it means you never need a folder full of numbered duplicates for a single working document. Duplicated files with a version convention are for documents that leave the tool entirely, such as anything sent as an attachment; native version history is for anything that stays inside one shared document.

Formatting: match, don't reinvent

When you build or edit a document for a client, the fastest way to look competent — or the fastest way to look careless — is formatting consistency. A professional font throughout, matching what they already use. Headings that are actually styled as headings, not bold text sized up by hand, so the document's own table-of-contents and navigation tools work. One consistent way of laying out a date, a currency figure, a phone number. None of this is decoration. It is the difference between a document that reads as considered and one that reads as thrown together, and clients notice the second far more than they notice the first.

By your second month with Adaeze, you will have answered the same question about her practice four or five times — to yourself, working it out again each time, because nobody wrote it down the first time. How to file an insurance appeal. What the cancellation policy actually is when a client is genuinely unwell versus simply unavailable. Which supplier to use when the usual one is out of stock.

The second time you work something out, write it down. There should never be a third time.

What belongs in the process library, and what doesn't

Not everything needs documenting — a library nobody trusts is worse than no library, because people stop checking it. Write down a process when it meets any of these: it recurs (you will do this again), it has a decision in it (there is a right way and a wrong way, not just one obvious way), or getting it wrong is expensive (money, a client relationship, or a compliance requirement).

Do not document what is genuinely obvious, what changes every single time so a written version would mislead more than it helps, or what exists only in your head and applies to nobody else. A library that tries to capture everything becomes unreadable, and an unreadable library gets ignored exactly like no library at all.

One page, every time, same shape

Consistency matters more than cleverness here. If every process page has the same four sections, a reader learns the shape once and can then scan any page in the library at speed, because they already know where the answer lives on the page.

Four sections, always this order: when this applies, the steps in order, the specific thing that trips people up, and the line that tells you when to stop and escalate rather than proceed alone — which is the same threshold discipline from lesson 2.4, applied to a written process instead of an inbox message.

Write it the moment you learn it, not later

"I'll write it up properly later" is where process libraries go to die. The detail that actually matters — that HealthPlan wants the licence number restated — is exactly the kind of thing that feels obvious the moment you learn it and is completely gone from memory a month later. Capture it in rough form immediately, even a single ugly line, and tidy the page during your weekly review rather than waiting for a moment of inspiration that will not arrive.

The client should be able to answer her own questions from it eventually

A process library is not primarily for you — it is for the business, and a well-built one starts answering Adaeze's own questions before it finishes answering yours. Within a few months she stops asking "how did we handle the last cancellation dispute" and starts checking the library first. That is the signal the system is working, and it is also, not coincidentally, the reason a well-documented practice is genuinely harder to leave than one that runs on memory: it depends less on any one person, you included.

This is an uncomfortable lesson to write, so let's be direct about why it matters. You are going to build a document that would let someone else pick up your work if you disappeared tomorrow — went silent, got a medical emergency, took a job that meant stopping. It feels like writing yourself out of a job. It is the opposite.

Being replaceable on paper is what makes a client trust you with more. Nobody hands over their whole business to someone who might vanish and take the knowledge with them.

What actually goes in it

Not everything you know — a handover file that tries to capture everything becomes a second job to maintain and nobody reads it. It holds exactly what someone would need in the first 48 hours of stepping in cold, in this order:

1. Access. Every account touched, how access is granted (delegate, shared inbox, direct login), and who to contact for each one. Never actual passwords — that undoes everything lesson 2.1 established.
2. What runs on autopilot. Every template, automation and recurring task, and where each one lives. The things that fail silently if nobody knows they exist.
3. The rhythm. What happens daily, weekly, monthly — the end-of-day summary, the day-before brief, the quarterly audit — so a replacement can pick up the pattern of the role, not just its content.
4. Where things stand right now. Anything currently in progress, anything currently owed to a client, anything already escalated and awaiting an answer. This section only, unlike the rest, needs updating regularly — the others change slowly.
5. Who to ask. For anything not written down. One honest line naming the actual gaps is worth more than pretending the document is complete.

What it looks like

Update it in one place, as you go

A handover file written once and never touched again is worse than none, because it actively misleads — someone follows an instruction that stopped being true eight months ago. Keep it as a single living document, and update the right now section weekly, in the same sitting as your Sunday calendar check. The other four sections change rarely; touch them only when something genuinely does.

The trust this actually buys you

Show Adaeze this document exists — not the whole content necessarily, but that it exists and where it lives. This is not a minor point. It is one of the clearest rung-four signals in the entire course: an assistant thinking about business continuity, unprompted, is an assistant a client stops worrying about. It is also, quietly, your own protection. If you are ever unreachable for a genuine emergency, this document is what stops a client's business from stalling — and what stops the relationship from souring the moment you resurface.