Notion, Loom, and SOPs all fail the same way

A small-business owner posted in r/smallbusiness with a problem that has no clean vendor answer. A key person had quit, and a chunk of how the business actually ran left with them. So the owner did everything the internet says to do. They stood up a Notion workspace. They recorded a stack of Loom walkthroughs. They had the departing employee write SOPs on the way out the door. Six months later the replacement was still asking the same basic questions, and the knowledge was still gone.

Here’s the short version before the long one. All three tools failed for one reason, and it’s the same reason: each treats writing things down as a separate job from doing the work. Knowledge parked next to the work instead of inside it goes stale the moment the work changes, and nobody is standing there to notice.

That’s not a Notion problem or a Loom problem. It’s a shape-of-the-solution problem, and swapping one tool for another keeps the shape.

So what do all three share that a fourth tool would only inherit?

Why all three fail the same way

Start with what these tools have in common. Notion is a place to read. Loom is a place to watch. A written SOP is a place to refer. All three are consumption models: one person produces the content once, and everyone after them is supposed to go consume it on their own time. The doing happens somewhere else entirely, in a different tab, in the actual system where the actual work lives. That gap between the page and the work is exactly where knowledge quietly dies, and it’s the quiet reason so much workflow automation underdelivers long before any tool is to blame.

There’s a deeper reason too, and it predates every one of these apps by about sixty years. Most of what a good employee knows is tacit knowledge, the kind that’s genuinely hard to write down or say out loud. The philosopher Michael Polanyi summed it up in 1966 with a line that belongs on every offboarding checklist: we can know more than we can tell. You can pick a friend’s face out of a crowd without being able to describe it. Your best operations person can feel when an order is about to go sideways without being able to explain how. Ask them to write an SOP and they hand you the explicit slice they can put into words. The rest, the part that made them good, never reaches the page, because they don’t know they know it.

So the departing employee writes the doc in good faith, and it’s still missing the thing you most needed to capture.

Something we learned slowly, watching small teams lose a key person and scramble: the panic offboarding doc is the least reliable document in the company. It’s written under time pressure, by someone with one foot out the door, about work they do on autopilot. Of course it’s thin.

Picture the person who ran your client onboarding for three years. They know which accounts want a phone call instead of an email, which payment terms quietly got renegotiated last spring, which onboarding step you can skip for a referral and which one you never skip. None of that is in their SOP, because to them it isn’t a rule, it’s just what you do.

The SOP says “send the welcome packet.” It doesn’t say “but not to the account that hates packets and wants a call,” because that lived in their judgement, and judgement is the part that won’t go on a page. When they leave, the packet still goes out. The call doesn’t, and a good client quietly wonders why the service got worse.

What each tool actually is

Look at the three the owner tried, one at a time, and the same flaw shows up wearing three outfits.

Notion is a library nobody visits. It’s a beautiful place to put things and a terrible place to find them under pressure. Pages multiply, nesting gets deep, and the search returns four versions of the same process with no signal about which one is current. The new hire opens it twice in week one, hits a stale page, and never trusts it again. A library is organized for the person who shelved the books, not the person sprinting through at 4pm needing one answer.

Loom is a lecture nobody rewatches. A recording feels like a transfer, but it isn’t one. It’s a twelve-minute video of someone narrating their screen, and the one fact you need is buried at minute nine with no way to scan for it. Worse, it captures a single moment in time. The instant the tool changes its layout or a step gets added, the video is wrong, and there’s no editing a recording the way you fix a typo. A recording is a snapshot of how the work looked once, not a thing the work keeps in sync.

A hand-written SOP is a reference nobody opens. It’s the most honest of the three about being separate from the work, which is also why it ages fastest. It sits in a folder, accurate for about a month, drifting from reality with every change that nobody writes down. By the time someone needs it, it’s pointing at a screen that no longer exists.

Three different mediums. One identical failure: each asks a busy person to go somewhere else to learn, then come back and do. That round trip is the tax, and people stop paying it.

Play it forward to a real Monday. The new hire needs to run the thing the old employee used to handle. They open Notion, search, and get five pages with names like “Process v2 (final) (updated).” They pick one, follow it, and step four references a button that isn’t there anymore. So they hunt down the Loom, scrub through eight minutes, and the relevant bit shows a screen from two redesigns ago.

They give up and message the owner, who happens to be the one person left who knows, and who is now doing the new hire’s job by proxy between meetings. Every tool worked exactly as built. The transfer still failed.

What the research says about documentation

This isn’t just a hunch from watching teams flail. Google’s DORA program studies what separates good documentation from bad, using eight metrics that score attributes like clarity, findability, and reliability. The payoff they measured is not small. For teams with above-average documentation, the impact of continuous integration on organizational performance jumps from 34% to 750%. Same technical practice, more than ten times the return, purely on the strength of the docs around it.

And notice which two attributes DORA names: findability and reliability. Those are the exact two things that die first when knowledge sits in a Notion page or a Loom video. You can’t find it fast, and once you do, you can’t trust that it’s current.

Findability alone breaks the whole system. When someone can’t locate the right answer in roughly thirty seconds, they stop looking and ask a human instead. Every one of those interruptions is a vote against the documentation, and it loses a little more authority each time until people quit reaching for it entirely. Then you’re back to tribal knowledge, which is the problem you were trying to solve. The owner who built the Notion workspace didn’t fail at writing. They built a thorough, unfindable, increasingly-wrong library, which DORA’s research says is close to worthless no matter how much work went into it.

Bind the knowledge to the work

Here’s the fix, and it’s about location, not effort.

Stop writing documentation that describes the work. Build the work so the knowledge lives inside each step. The process for closing the month stops being a Notion page and becomes a process you can actually run, where step three carries the exact instruction, the field to fill, and the one warning that the person who left used to give out loud. Nobody has to remember the doc exists, because the doc is the path they’re already walking. They can’t skip it, and they can’t get ahead of it.

What finally clicked for us building Tallyfy: a document gets updated when updating it and using it are the same action. When the guidance lives in step three of a process people run every week, the person who hits a wrong instruction fixes it right there, in the moment, with the evidence in front of them. No quarterly review. No doc-debt sprint that never gets scheduled. Every run is a maintenance pass, performed by whoever has the most context, at the exact second they have it. That’s the same reason SOPs fail in a binder and survive inside a workflow you can track step by step. The knowledge stays alive because staying alive is a side effect of doing the job.

Go back to that onboarding process that walked out the door. As a Notion page it was twelve steps that went stale the first time you swapped a tool, and nobody updated it, because updating a page you aren’t looking at always loses to the work in front of you. As a workflow it’s twelve tracked steps the next person runs with real clients in week one. When step seven points at the wrong tool, they fix step seven on the spot, because the wrong instruction just failed in their hands. Six months on, the process is still correct, not because anyone scheduled a review, but because being correct became a byproduct of running it. The page version would be on its third “I think this changed?” comment by then, trusted by no one.

This is also the only honest answer to the tribal knowledge problem the owner was fighting. You can’t extract everything in someone’s head into a wiki before they leave. But you can capture the part that matters, the sequence and the gotchas, by turning the work they do into a workflow while they’re still here to run it and correct it. The structure outlives the person, even though some of the tacit feel goes with them.

Do Notion and Loom still have a place?

Yes, and it’s worth being clear so nobody throws out a useful tool. Notion is great for the things people read to understand: the why behind a decision, the org chart, the strategy doc, the reference material that sits still and stays true for a year. Loom is great for a one-time explainer or a quick async update. Neither is built to carry procedure, the do-this-then-that work that changes constantly and gets run under pressure. The mistake isn’t using them. It’s asking them to hold the operational knowledge that decides whether the business keeps running when someone quits.

There’s a simple test for which bucket a piece of knowledge belongs in. If someone reads it to decide something, it’s reference, and Notion is a fine home. If someone follows it to do something, it’s procedure, and it belongs inside the workflow, not in a doc beside it. Most teams pile both kinds into the same wiki, then wonder why half of it rots while the other half stays useful. The half that rots is always the procedural half, because procedure decays the instant it’s split from the act it describes. This is the quieter cousin of the one-person-knows problem: the knowledge looked captured, sitting there in Notion, while it was actually still locked in one person’s head.

So here’s the move, and it fits in a week. Don’t try to document everything before the next person quits. Pick the single process whose loss would hurt most, the one you’d panic about if the person who runs it gave notice tomorrow. Turn that one into a workflow this week, with a named owner and the guidance built into each step, and run it with the person who still knows it. Do that, and the knowledge stops being something you hope is written down somewhere. It becomes something the business does, whoever’s holding the keyboard.