Search is Broken: Why Tribal Knowledge Still Exists in MSPs

Almost half of the MSP owners we demo to open the conversation the same way. They tell us their current documentation tool's search is unusable, that they can't find anything, and that they gave up on the search bar a long time ago. Then they walk us through whatever workaround they ended up building. For some that's a left-to-right navigation. For others it's a homegrown tagging convention, or a senior tech they ping on Teams whenever something goes sideways.

It's the most common pain point we hear, and the one that's easiest to lose patience with, because the workaround feels normal after enough years. But every one of those workarounds carries a real cost. A tech burns six minutes finding the right doc when it should have taken two. The runbook that would have answered the question never gets surfaced, and the L1 escalates instead. We see QBR prep that should take five minutes eat the better part of an afternoon.

This piece is about why search broke, why bolting AI onto a broken architecture doesn't fix it, and what an MSP documentation platform has to look like for search to actually work.

Why search broke in the first place

Most of the documentation tools MSPs use today were built more than a decade ago, around a deep folder structure where individual documents end up nested four or five levels inside a company-level parent. That made sense at the time. The job of search was simple. Match the words you typed against document titles and a handful of indexed fields, and return what looked closest.

It worked, more or less, when MSPs were smaller, when their techs had been around long enough to know the naming conventions off-hand, and when the document set hadn't gone stale yet.

None of those things are true anymore. MSPs have grown faster than their documentation practices. Turnover is up. And the document set is, in the words of one prospect on a recent demo, 60 to 70 percent stale. Search now does the thing legacy search has always done, which is keyword matches against titles, inside a corpus where the titles are inconsistent, the contents are out of date, and nobody remembers which technician wrote which doc three years ago.

That's the core problem. The architecture assumes the searcher already knows the lexicon the original author used, and the naming convention that came with it. The moment that assumption breaks, whether it's a new hire, a forgotten quirk, or a doc someone wrote at 11 p.m. on a Friday, search breaks with it.

The cost of broken search, in hours

Most of the MSP owners we talk to can't put a number on it, because nothing in their PSA is tracking it. So we ask in demos, and the answers cluster:

• Two to three hours of QBR prep per client, most of it spent finding and reconciling the right docs.
• Junior technicians shoulder-tap senior technicians multiple times a day for context that should be findable.
• First-touch resolution drops because the tech can't find the runbook fast enough, even when the runbook exists.
• New hires take months to ramp because so much knowledge lives in senior techs' heads, not in searchable docs.

There's a softer cost too, and honestly it's the one that compounds. Once a technician searches for something a few times and doesn't find it, they stop trusting the tool. Eventually they stop documenting too. They stop checking. When the next ticket lands, they go straight to the senior tech, or to the client, or they re-solve the problem from scratch. Documentation becomes a place things go to die and tribal knowledge grows.

Why bolting AI on top doesn't fix it

We see most legacy documentation vendors responding to the search problem by adding an AI assistant on top of the existing structure. The promise is simple: ask the AI a question and it will find the answer for you. In practice, the same architectural problems that broke keyword search break the AI too.

This is why prospects keep asking us the same skeptical question in demos: how do I know it's not hallucinating and giving me a bunch of nonsense? The question is reasonable — they've seen the bolt-on AI in their current tool change its answers between two identical prompts.

This is the framework we built Lexful around. We flattened the data so the AI can actually traverse it. Every document's contents get indexed, not just its title. Every answer we return is grounded in a source you can click into, and the AI itself was context-engineered for MSP workflows rather than for a generic enterprise.

What changes when search actually works

The most immediate change is time. The work that used to eat 30 minutes (chasing down the right runbook or finding a credential filed under whatever naming convention the original author chose) now takes three. That's an order of magnitude, and it shows up in MTTR, in QBR prep, and in the number of times an L1 has to ping an L3.

The second change is trust, and to me it's the harder of the two to win back. When search returns the right answer the first time, technicians start going to the documentation first instead of last. They write more docs because they know the docs will get used. They start treating the platform as a real knowledge source instead of a graveyard.

The third change is leverage. A junior technician with working search starts performing closer to a senior technician on day one, because the senior technician's knowledge is finally reachable. New hires onboard in weeks, not months. The senior team stops being a human search bar.