Nobody has ever measured what a company forgets

You've seen the stat. It's in every "why you need a knowledge base" deck: employees lose some huge chunk of their week just searching for information. Blog posts, sales decks, LinkedIn slides. It's also mostly made up.

The most-cited version is "2.5 hours a day," attributed to IDC. It traces back to a 2001 estimate that IDC itself described as a general estimate, made when most companies barely had an intranet. The other source everyone cites next to it is a 1998 study that doesn't contain the claim people attribute to it. IDC's own later numbers contradict the famous one. Nobody re-ran the research. The number just kept getting re-cited, because it's big enough to open a pitch with.

So a made-up number has survived twenty-five years on convenience alone. And the reason nobody replaced it with a real one is more interesting than the number: you can't measure what a company forgets, because the part that gets lost was never written down. You can't run analytics on a conversation that didn't happen.

The wiki detour

When a team first decides to fix this, the plan is almost always the same. Set up a wiki. Get everyone using Notion properly. Or, for the more technical crowd, dump everything into Obsidian. Sounds like a weekend thing.

It isn't, and the reasons are well documented. Nik Begley, who runs a docs-tooling company and so has a stake in the argument, described the Confluence version:

The moment your documentation starts to be out of date, it starts to lose its value. Once developers stop being able to trust that the docs reflect the true state of the world, they'll stop relying on it, and therefore, stop improving it.

Docs sit outside the workflow where decisions actually get made, so they drift, and once nobody trusts them nobody bothers fixing them either.

Obsidian breaks differently. It has no built-in per-note or per-folder permissions, so vault access is all-or-nothing. A founder called Aurel Babiš hit that running his company off one and put it bluntly: "Everyone with vault access sees everything. API keys, strategy docs, client info, all wide open." He ended up writing his own access-control plugin rather than finding one off the shelf.

Notion is winning by any measure, past 100 million users on its own count, and it has the same shape of problem. A review of it as a knowledge base by the team at eesel.ai names the condition: "If your team doesn't have a Notion champion who takes ownership of setup and governance, your workspace will become a mess of inconsistent pages and abandoned databases." Notion's own answer is a page-owner feature where you verify a page as current until a date you pick, which makes the upkeep easier to stay on top of. Somebody still has to stay on top of it.

Three tools, three architectures, one shape: they work while somebody governs them and come apart when nobody does.

The part the category already solved

Here's where most articles like this one would pivot to a solution. The honest version has to make a detour first, because a whole funded category already exists and it already fixed the wiki problems above.

Glean, at a $7.2B valuation, does permission-aware search across 100+ connectors. Onyx does it open-source and self-hostable with 25+ connectors and citations. Falconer keeps internal docs self-updating from GitHub, Slack, Linear and Notion. Dust is agent-first and MCP-native. Y Combinator named the category in its 2026 request for startups, and the consensus definition of a company brain already specifies that it stays current automatically, unlike a static wiki.

So automatic ingestion is not an unmet need. Permission-awareness is not an unmet need. Anyone writing that wikis rot and therefore someone should build automatic ingestion is about a decade late, and is also describing several companies with more funding than most readers of this will ever raise. If you have the wiki problem, buy one of those. It's a solved problem with multiple credible vendors, including a free open-source one.

The part that stays out of reach

What the category can't do, by construction, is get what was never written down.

Wikis and company brains alike organise what a person already chose to write. Everything in this piece is reactive: it indexes, connects and retrieves what exists. Ask any of it something that only lives in a colleague's head and the honest answer is nothing, because nothing was ever filed.

That's the same gap the fake statistic was gesturing at, and it explains why the statistic could never be replaced with a real one. The exceptions, the criteria, the reason this client gets different treatment, which vendor to call when the usual one is out of stock: none of it is in a document, so none of it is in an index, so none of it can be counted or retrieved. Better retrieval doesn't reach it. More connectors don't reach it. It isn't a search problem at all, which is inconvenient, because search is what the category is good at.

Why it stays unsolved

Not oversight. Reaching that half means going and asking a person, and that is a much worse thing to build than an index.

It has to decide a gap exists at all, which means knowing what it doesn't know. Then decide who would plausibly know, which means a model of who does what, kept current as people change roles. Then interrupt that person, on a channel they actually read, with a question specific enough to be answerable in one reply. Then be right often enough that they answer the second time, because the first unnecessary ping costs more trust than one answer is worth. Every step there can fail in a way a search box can't, and the failures are social rather than technical, so you can't fix them with a better retrieval score.

An index has none of that exposure. It also demos beautifully: type a question, watch the right document appear. A system that decides to phone somebody demos as an awkward pause.

So the incentives point away from it, which is a decent explanation for why a well-funded category converged on the solvable half. Whether the unwritten half is worth chasing at all is an open question. It might be that most of what companies "lose" is low-value noise and the exceptions that matter are already written down somewhere. Nobody knows, because that's precisely the number nobody has ever measured.

Disclosure

I work on internal knowledge tooling, so I've spent more time than most thinking about the unwritten half, and that's a reason to discount my sense of how much it matters. The same goes for the docs-tooling founder quoted earlier.

What holds up without either of us: the famous statistic is fabricated, the wiki failure modes are documented and commercially solved, and the reactive-by-construction limit is a real property of how the category works rather than anyone's marketing angle. Anyone selling you a solution to the rest is guessing, and now you know the famous statistic is too.

Sources

• └The debunk of the searching-for-information statistic: Martin White, "'Time spent searching' — a chronology of the myth and some recent research".
• └Nik Begley on documentation going stale: "Confluence is where documentation goes to die". He runs a docs-tooling company, as noted above.
• └The Obsidian permissions account: a founder writing up the problem in the Clief Notes community. One team's experience, not a survey.
• └The Notion champion quote: eesel.ai's review of Notion as a knowledge base. The 100 million figure is Notion's own.
• └The OpenClaw knowledge-base skill and its stated scope: its documentation.
• └Glean's valuation: its own Series F announcement. Onyx, Falconer and Dust are described from their own material.
• └The category name: Y Combinator's request for startups.