Your knowledge base is becoming your competitive advantage

For years, the knowledge base has been the operational equivalent of eating your vegetables.

Everyone agrees it's important, and very few people are super stoked about it.

The knowledge base sits in the basement while more “interesting” or urgent projects steal the spotlight. New products and services launch, sexy AI initiatives get approved, and new customer experience strategies are dramatically unveiled with suspiciously optimistic timelines.

Meanwhile, the knowledge base receives exactly the same attention it's pretty much always received: somebody updates half of an article because a customer found a huge error, another person promises they'll clean up the navigation "when things calm down". Nine million Trello cards get added to a board people only check once a quarter.

Oddly enough, all of this wasn't really a huge problem back in the days of yore, or at least, it wasn't a problem that most organizations could see. Mostly thanks to the fact that support folks are very good at working around imperfect systems: when documentation falls behind, they just go ahead and compensate.

They remember the policy change that never quite made it into the knowledge base, they know Product came up with an exception for enterprise customers in Europe (and didn’t tell anyone). They vaguely recall somebody from Engineering explaining the workaround in Slack a few weeks ago and, after a bit of detective work, they piece together the right answer.

The customer never notices, the interaction goes well, everyone moves on, and from the outside, it looks like the operation is working exactly as it should. Cool, right?

What's actually happening in the background, though, is not ideal. Every successful customer interaction depends just a little bit less on the systems the business has built and a little bit more on the experience, memory, and persistence of the people delivering it.

Over time, companies become really good at solving the same problems again and again without ever making those problems less likely to happen in the future.

It's one of the least obvious forms of operational debt you'll find in customer experience because, unlike a growing backlog or declining CSAT, general and visible success hides it really well. Customers receive good answers, cases get resolved, and the operation keeps moving. Nobody notices (or doesn’t want to notice) that the business has stopped learning.

Then, AI arrives. Or the company doubles in size. Or a new outsourcing partner joins the business. Or the person who somehow knows absolutely everything hands in their notice. All those little workarounds stop looking like cute little strengths and start looking exactly what they actually are: evidence that the organization never had a real way of capturing or sharing what it knew.

That's why we think the humble knowledge base we all know is about to become one of the most important competitive advantages in customer experience; not because documentation suddenly became exciting out of absolutely nowhere, but because knowledge has stopped being documentation. It's becoming infrastructure.

Every scaling problem eventually becomes a knowledge problem

Ask ten support leaders what's the main thing making their operation harder to grow and you'll hear ten different answers.

Someone's struggling to onboard new hires quickly enough. Somebody else is frustrated that AI still escalates too many conversations. Another team can't seem to reduce repeat contacts, while someone across the room is trying to understand why outsourced teams take months before they feel even a little bit independent.

Those can all sound like separate operational challenges. They belong to different teams, involve different budgets, and usually end up on different project plans. However, they're all trying to solve exactly the same problem: knowledge isn't moving through the business efficiently enough.

Take something as simple as an edge case that isn't properly documented: a customer gets in touch with an unusual question, the team member doesn't panic because they've been here before.

They search the knowledge base just for funsies, and the answer isn't there (as they suspected). They then remember seeing a discussion in Slack, message a coworker who's dealt with it previously, and eventually give the customer exactly the answer they needed. It's a genuinely great support interaction while also being a full operational failure.

Not a failure because the customer had a bad experience, but because the business has finished the conversation knowing exactly the same amount as it did beforehand; nothing has changed. The next person who receives that question will repeat the same investigation, speak to the same colleague (who won’t document it, still, even though they’ve had to walk multiple people through it in the past month), search the same Slack thread, and arrive at the same conclusion. The company has solved the customer's problem without solving its own.

Multiply that by hundreds of edge cases over months or years, and the organization becomes super capable of compensating for gaps in its own knowledge while simultaneously becoming worse at closing them. Scaling becomes difficult not because the people aren't good enough, but because every new person has to learn the same unwritten rules the last person memorised.

Companies think they're scaling people

… while they're actually trying to scale decisions. This is the point where conversations about growth often become very misleading. Ask a leadership team how they plan to “scale” customer support and the answers are usually predictable.

"We'll hire."

"We'll bring in an outsourcing partner."

"We'll implement AI."

Three completely different strategies… right? Except they aren't. Take away the technology, the vendors, and the org charts, and all three are trying to accomplish exactly the same thing: trying to help someone make the same decisions your best support folks already make instinctively.

Hiring internally means teaching new team members everything your experienced people have learned over the years. Outsourcing means transferring that same judgement to another team, often halfway around the world.

AI is attempting exactly the same thing, except the student happens to be a machine instead of a person. Different approaches, identical challenge, and that's why organizations are surprised when sensible investments don't produce sensible outcomes.

The outsourced team is smart, but takes much longer to ramp than expected. The AI pilot handles straightforward conversations beautifully before immediately asking for help the moment things become even slightly unusual. New hires complete training on schedule but still spend weeks checking Slack before answering anything remotely complicated.

It's tempting to diagnose all of those problems separately. Maybe the recruitment process needs work? Maybe the outsourcing partner wasn't the right fit? Maybe the AI just isn't mature enough yet?

More often than not, all of these things are pointing to exactly the same operational reality: the business never built a scalable way of teaching itself what it already knew.

Your best people have been hiding this problem for years

Every support organization has at least one person who appears to possess a mildly supernatural amount of knowledge.

They don't just know the product, they know the business. They know everything. Ask them about the most obscure edge case you can think of and they'll answer before you've finished the question.

If there's a disagreement about how something should be handled, somebody inevitably says, "Let's ask Sarah," and within about thirty seconds, everyone carries on with their day. Those people are worth their weight in gold, and they're also one of the biggest reasons organizations underestimate the state of their knowledge systems.

That’s still because the customer receives an excellent answer and everyone leaves feeling rather pleased with themselves. Especially Sarah. Meanwhile, the knowledge base is exactly as incomplete as it was ten minutes earlier.

It's easy to mistake that for expertise, and technically it is, but it’s the wrong kind: it's expertise compensating for infrastructure that should have been fixed a long time ago. Instead of Sarah, we should be able to ask the respective knowledge base doc.

Humans are very good at connecting dots, filling gaps, inferring context, and remembering exceptions almost without thinking about it. In many ways, it's one of the things that makes great support folks so valuable. They don't just retrieve information; they interpret it. They recognise when something doesn't quite add up and instinctively look elsewhere before giving an answer.

The problem is that organizations gradually start depending on that behaviour. Instead of asking why people need to cross-reference three different systems before replying to a customer, we celebrate the fact that they can. Instead of wondering why the same edge case has been solved twenty times without anybody updating the documentation, we congratulate ourselves on having experienced people who always seem to know what to do.

Over time, the workaround becomes the operating model. You can usually tell it's happened when onboarding starts sounding less like training and more like an apprenticeship.

New hires aren't just learning the product, they're learning who to ask. They discover that the knowledge base is a useful starting point, but the real answers tend to live somewhere between Slack, yesterday's team meeting, and whichever senior colleague has been around long enough to remember why things work the way they do. None of that is intentional, of course. It just accumulates over time, one undocumented exception after another.

The irony is that the people carrying all this institutional knowledge are often the least aware that they're doing it; from their perspective, they're just helping a teammate. They solved this problem six months ago, they remember the answer, so they share it. It's efficient. It's collaborative. It feels exactly like the sort of culture you'd want.

Until they go on holiday. Or move into another role. Or leave the business entirely.

That's usually when organizations discover they weren't relying on a knowledge base after all, they were relying on a handful of brilliant people who'd become human middleware between the customer and the information the business never quite got around to documenting.

AI hasn't lowered the bar; it's revealed where you already set it

One of the more amusing side effects of the AI boom is watching companies suddenly become very passionate about documentation.

Almost overnight, the conversation changed. Teams started asking why the chatbot kept escalating perfectly reasonable questions, why answers were inconsistent, or why customers seemed strangely determined to ignore the beautifully engineered self-service experience everyone had been so excited about.

It was tempting to blame the technology, because after all, that's what everyone else seemed to be doing? Maybe the model wasn't sophisticated enough, maybe AI just wasn't ready, maybe customers asked weirder questions than anyone had anticipated? Maybe the support inquiries were just too unique because the docs already handled the “low hanging fruit”?

Sometimes those explanations are fair, but more often, the technology is doing something a lot less dramatic: it’s reflecting the quality of the information it's been given. That sucks because it exposes a standard most organizations didn't realise they had been living with. Human support professionals had spent years happily compensating for inconsistent documentation, and then AI just came along and refused to join in.

A person (granted that they have the time) notices when an article is slightly out of date. They remember hearing about a policy change in last week's stand-up. They ask a colleague if something doesn't look quite right, and they recognise that two pieces of information contradict one another and use human judgement to work out which one is most likely to be correct.

AI doesn't, nor should it. It takes the organization at its word, which means the knowledge base stops being a helpful reference document and becomes exactly what it always should have been: the single source of truth that determines whether automation succeeds or spends another year in "pilot mode."

That's why we don't think AI is exposing knowledge gaps; it's exposing knowledge standards. Those are two different things: a gap suggests something is missing, a standard determines what the business considers "good enough."

For years, "good enough" meant experienced people could usually work around the documentation. AI has politely waltzed in and straight up declined that arrangement. And, in fairness, it's probably doing the rest of us a favour, even if we don’t want to admit it.

Outsourcing doesn't solve knowledge problems, it amplifies them

When an outsourced team struggles, the first instinct is usually to look at the people. Were they trained properly? Do they understand the product? Is the partner hiring the right profiles? Are they asking enough questions? Sometimes those are exactly the right questions, sometimes they're the wrong ones.

We've seen organizations spend weeks (if not more) trying to coach outsourced teams through problems that had very little to do with capability and almost everything to do with documentation. The outsourced team wasn't struggling because they lacked experience, they were struggling because the business had accidentally turned onboarding into archaeology.

That's an important distinction because it changes the doubt points. Instead of asking, "How do we train people better?" you start asking, "Why does learning this require massive amounts of detective work in the first place?"

The best outsourcing relationships don't succeed because the partner somehow magically absorbs institutional knowledge through osmosis. They succeed because the organization has already done the hard work of making that knowledge easy to find, easy to trust, and easy to improve, and that's true whether the person learning it sits three desks away or three continents away.

In many ways, outsourcing is an unexpectedly honest test of your operational maturity. Internal teams have had months or years to memorise exceptions, build relationships, and develop instincts for where the "real" answer lives. A new partner has none of those advantages; they inherit the operation exactly as it exists today, not as everyone assumes it exists.

That's why outsourced teams often reveal problems that were already there, they're just the first people forced to rely on the systems you've built instead of the shortcuts you've accumulated.

Knowledge is one of the few investments that compounds

Most operational improvements solve a specific problem.

• Improve QA and you'll usually see quality improve.
• Invest in workforce planning and forecasting gets better.
• Reduce handle time and customers spend less time waiting for answers.

Those are all worthwhile investments, but they tend to have fairly predictable boundaries. Knowledge works differently: every improvement has a habit of showing up somewhere else.

A clearer onboarding guide helps new hires become productive faster, but it also shortens the ramp for outsourced teams because they're learning from the same source of truth. It gives AI cleaner information to retrieve, reduces unnecessary escalations because fewer questions fall into grey areas, and makes coaching conversations far more productive because everyone is working from the same understanding of what "good" actually looks like.

That's a really good return on one operational improvement, and also one of the reasons mature support organizations often appear deceptively efficient from the outside. They don't necessarily have fewer customer questions, they just spend less time rediscovering answers they already had. There's a subtle but super important difference there.

Efficiency should never be just about resolving conversations quickly, it should be about reducing the amount of organisational effort required to produce a consistently good answer.

Every time someone updates the documentation after solving a genuinely new problem, the next team member starts from a better position than the last one did.

The companies that win won't necessarily have the best AI

Over the next few years, there'll be no shortage of headlines predicting the future of customer support. Autonomous agents, Agentic AI, hyperautomation. Whatever the industry decides to rename chatbots next Tuesday.

Those conversations are worth having, but they also distract us from something much more fundamental: every successful AI implementation, every high-performing outsourced team, and every consistently excellent internal operation relies on exactly the same foundation: a business that knows how to capture, organise, and improve what it learns.

That's why we don't think the knowledge base is becoming obsolete. We think it's, now more than ever, becoming one of the most strategic assets in customer experience. It has become the one thing your people, your partners, and your AI all depend on equally.

If there's one idea we'd leave you with, it's this: most companies think they have a documentation problem, but what they actually have is an organisational memory problem.

The organizations that pull ahead over the next decade won't be the ones that document the most. They'll be the ones that learn the fastest; capturing what every customer conversation teaches them, improving their systems continuously, and making sure the next person, whether they're a new hire, an outsourcing partner, or an AI model, starts from a better place than the last one did.

That's a very different way of thinking about a knowledge base; it's also a much more interesting competitive advantage.