A client called me two weeks ago with news that sounded almost routine: Marta — not her real name — had handed in her notice. She had run returns and supplier claims for six years, and she was leaving in three weeks. Nobody panicked right away. Then someone tried to find where "the process" actually lived, so they could hand it to whoever came next, and it turned out there was no "where." There were three email threads, half of a spiral notebook, and a sticky note with a supplier contact's direct line that nobody else had ever called.
Nobody had done anything wrong. The returns process had worked, every week, for six years. It worked because Marta carried it in her head, and only Marta.
This is what people mean by tribal knowledge, and it is far more common than most business owners want to admit.
The system was never written down, because it never had to be
In a small business running on notebooks, email, and WhatsApp threads, there is no moment where someone decides "let's keep this undocumented." It just happens, quietly, over years. Someone picks up a task because they're available or good at it. They solve a few edge cases nobody else saw. They make small decisions — which supplier gets called first, which customer always needs a reminder, which exception gets waved through — and those decisions never get written anywhere, because writing them down was never part of anyone's job.
Six years later, that person isn't just doing a task. They are the only documentation the task has.
It's not laziness. It's structure
I want to be clear about this, because it's tempting to read a story like Marta's and think the company was careless. It wasn't. There's rarely a budget line for "write down how we do things," and there's rarely a slow week where someone says "let's stop and document this." The work that pays the bills always wins against the work that only pays off if someone quits. So the knowledge keeps living in one head, because that's the path of least resistance every single week, until the week it isn't.
The real cost shows up at the worst possible time
The expensive part of losing tribal knowledge is almost never the knowledge itself. It's when you lose it.
Nobody loses a key employee during a quiet month. It surfaces during a return that needs processing today, a supplier dispute with a deadline, or a customer escalation that can't wait for someone to "figure it out." The business doesn't get to reconstruct the process calmly. It has to reverse-engineer it live, under pressure, usually while also training whoever is supposed to take over.
I've watched this play out as weeks of guessing: digging through old email threads for context, calling suppliers to ask "wait, how does this usually work on your end," redoing work because the first guess at "the process" turned out to be wrong. None of that shows up as a line item anywhere. It shows up as slow weeks, annoyed customers, and a replacement employee who looks slower than they actually are, because they're rebuilding a process from fragments instead of learning one that was ever written down.
What actually fixes this isn't a big system
Here's the part that surprises people: the fix for tribal knowledge almost never requires "an ERP" or a big platform rollout. What it requires is much smaller and much more specific — records of what actually happened (which supplier, which decision, which exception, and why), a way to search that history in seconds instead of guessing, and a defined process that lives outside any one person's memory.
That's it. Not a system that does everything. A system that holds what one person currently holds alone.
I built something like this for a client running a gallery — tracking inventory, sales, and artist consignment details that used to live across a few people's memory and a stack of paper records. The goal wasn't to digitize everything the business does. It was to make sure that if any one person on that team left tomorrow, the next person could open the system and actually see what happened with a given piece: who consigned it, what was agreed, what sold, what's owed. The knowledge stopped belonging to a person and started belonging to the business.
This is the same idea behind a back-office system done well: it doesn't try to replace how your team thinks. It starts with the one process where the knowledge is riskiest — the one person, the one notebook, the one thread nobody else can read — and it gives that process a record, a search, and a defined way of doing things that survives a resignation letter.
Capture it before someone gives notice, not after
The honest advice here isn't "build a system for everything your business does." It's narrower than that: find the process in your business that currently lives in one person's head, and give it a home before that person's two weeks' notice forces the issue.
You probably already know which process that is. It's the one where, if you're honest, only one name comes to mind when someone asks "who handles this." That's the one worth starting with — not because every process needs this, but because that one is one resignation letter away from becoming a crisis instead of a transition.
Marta's last day came and went. The company survived it, but it cost them three weeks of her notice period spent frantically documenting things that should have had a record years earlier, and a rocky first month for whoever came next. It didn't have to be that expensive. It rarely does.