Every business I've worked with has one person who spends half their week answering the same five questions. Usually it's someone in ops or HR, and usually nobody has ever added up what that costs.

The short answer to this title is simple. You build a company knowledge base by collecting the questions your team already asks, writing clear answers to the ten that come up most, giving every article an owner and a review date, putting the whole thing where people already work, and only then choosing software. Most British teams can get a working version live in a fortnight for somewhere between nothing and about £8 per person per month. The rest of this article covers how to do each of those steps properly, what the tools actually cost in pounds, and where UK data protection law comes into it.

I've built internal knowledge bases for teams of six and teams of a few hundred, and I've watched more of them die than survive. So along with the how, I'll be honest about why most of these projects quietly fail, and how to make sure yours doesn't.

The Real Cost of Answering Questions by Hand

Let's start with why this is worth your time at all, because the numbers are genuinely startling.

Research from Atlassian published in early 2025 found that UK workers lose around nine hours every week searching for the information they need to do their jobs. That's more than a full working day. The same study found that 53 percent of employees believe the only way to get information is to ask a colleague or book a meeting, and 55 percent regularly have work blocked while they wait for an answer from another team.

There's an older but widely cited McKinsey figure that puts information searching at 1.8 hours per employee per day. That research is American and global rather than UK specific, so treat the exact number with caution, but the Atlassian UK finding lands in almost exactly the same place, which suggests British offices are no better at this than anyone else.

Do the maths for your own business. Take a 20 person company with an average salary around £35,000. Nine hours a week of searching and asking is roughly a fifth of everyone's time. Even if a knowledge base only claws back a third of that, you're recovering the equivalent of more than one full time salary a year. That's the budget conversation, and it usually ends quickly.

There's a second cost that never shows up in a spreadsheet. When knowledge lives in one person's head, that person becomes a bottleneck and a risk. They can't take a proper holiday. When they resign, the knowledge resigns with them. I've seen a small logistics firm lose its entire customs process overnight because the one woman who understood it left for a competitor and nobody had ever written anything down.

What a Company Knowledge Base Actually Is

A company knowledge base, sometimes called an internal knowledge base or internal wiki, is a private, searchable library of the documentation your business writes for its own staff. Processes, policies, how to guides, troubleshooting steps, onboarding material, the works. Access is restricted to employees, usually with permission groups so the finance team's payroll notes aren't readable by everyone.

It is not a shared drive full of Word documents. A folder structure with 400 files named "Process FINAL v3 (2)" is where knowledge goes to hide, not to be found. The whole point of a proper knowledge base is that someone types a question in plain English, or asks an AI assistant that sits on top of the content, and gets the answer in seconds without interrupting anyone.

It's also not the same thing as a customer facing help centre. The tools overlap and some platforms do both, but the audience, tone, and permissions are completely different. This article is about the internal kind only.

Start With the Questions, Not the Software

Here's the mistake I see constantly. Someone gets excited, signs up for a tool, builds a beautiful empty structure with a category for every department, and then asks everyone to "add their documentation." Six weeks later there are nine half written pages and everyone has gone back to asking questions in the group chat.

The fix is to reverse the order entirely. Before you touch any software, spend one week collecting questions. Every time someone asks you something, note it down. Ask your managers to do the same. Search your Slack, Teams, or email for phrases like "quick question," "how do I," and "where's the." You will very quickly see the same fifteen or twenty questions repeating.

As the HelpDocs guide to internal knowledge bases puts it, the winning move is to pick the ten questions that unblock the most people and write those first, because ten good articles beat forty half written ones. The ten get used and the forty stall. I'd go further and say the test for whether any article deserves to exist is whether someone currently answers that question out loud more than once a month.

For a typical UK small business, the first ten usually look something like this: how to book annual leave, how expenses work and what the limits are, how to set up the VPN, what to do when the card machine or till plays up, who to contact when a client complains, the new starter checklist, how the pension scheme works, where the brand assets live, how to raise a purchase order, and what the sickness reporting procedure is. Yours will differ, but not by as much as you'd think.

Choosing the Software Without Wasting a Month on It

Only now, with your ten questions in hand, do you pick a tool. The good news is that this decision matters far less than people think, and every serious option has a free tier or free trial. The bad news is that most comparison articles are written by the vendors themselves, so read the pricing pages directly before you commit.

A note on currency before the numbers. Several of these platforms bill in US dollars even for UK customers, so where I give a pound figure for a dollar priced tool, it's an approximate conversion and your card statement will move slightly with the exchange rate. Notion is the exception in that it displays localised GBP pricing at checkout. All figures below were checked against current published pricing during research for this article, and all of them exclude VAT, which you'll pay on top as a UK business.

Confluence is Atlassian's wiki and the default choice if your company already runs Jira. It's free for up to 10 users with unlimited pages, which makes it a genuinely usable starting point for a small team, not just a teaser. Beyond that, Standard costs around $5.42 per user per month, which works out at roughly £4 per person, with Premium at about $10.44, roughly £8. It bills in dollars. Its strengths are granular permissions and structure at scale. Its weakness is that it can feel heavy and corporate for a 15 person firm, and the bundled Rovo AI features are metered by a credit allowance that most buyers never read about until they hit it.

Notion is the flexible all in one workspace, and it's what I recommend most often to startups and creative businesses because the wiki, project boards, and documents all live in one place. Pricing shown in GBP runs at about £8.50 per member per month for Plus on annual billing, with the Business plan at roughly £16.50. The catch that trips people up: full Notion AI, including the Ask feature that answers questions from your content, now sits on the Business plan only. Plus gets a limited trial. If AI answering is the main reason you want Notion, budget for Business from day one. Notion's other weakness is that its total flexibility means an undisciplined team can turn it into sprawl within months.

Slite is a dedicated internal knowledge base, and its whole pitch is fighting staleness. Documents carry verification schedules, owners get prompted to confirm accuracy, and unverified pages are visibly flagged so readers know what to trust. Its Ask feature returns cited answers on both paid tiers. The Basic plan is listed at $10 per user per month billed annually, around £8, and Pro at $20, around £16, which adds an agent that checks connected sources and proposes updates for human review. It bills in dollars. The honest downside, as the Helply comparison of knowledge base platforms points out, is that at $20 a member a 20 person company is paying around $400 a month for internal documentation alone, and the AI answering is metered rather than unlimited.

Guru takes a different approach again: short verified cards instead of long articles, surfaced inside Slack and your browser rather than in a separate site. Entry pricing starts around $5 per user per month, but the fuller AI feature set is quote only, which I find mildly infuriating. It's the strongest option if your team lives in Slack all day and you want answers to appear where questions get asked.

And a word on what you probably shouldn't do. If you're a UK business already paying for Microsoft 365, you'll be tempted to say "we'll just use SharePoint." You can, and for larger organisations with proper IT support it's defensible because you're already paying for it and the data stays inside your existing tenancy. But in my experience small teams without a dedicated administrator end up recreating the shared drive problem with a nicer login screen. If nobody in your business enjoys configuring Microsoft products, buy something purpose built.

Best for a quick decision: free and under 10 people, use Confluence's free tier or Notion's free plan. Growing team that wants everything in one tool, Notion Business. Team whose biggest fear is stale documentation, Slite. Slack centric support or sales team, Guru. Already deep in Jira, Confluence Standard.

The Part Where It Answers Questions for You

The title of this article promises a knowledge base that answers employee questions for you, and this is the piece that has genuinely changed since the days of the dusty intranet. Modern platforms put an AI layer on top of your content that reads the articles and answers natural language questions with citations back to the source pages.

In practice that means a new starter types "how many days holiday do I get and how do I book it" into the search bar, or asks a bot in Slack or Teams, and gets a two sentence answer with a link to the leave policy, rather than reading the policy or messaging HR. A useful comparison of AI knowledge base tools by eesel AI frames the buying question well: the point isn't which wiki has the cleverest AI, it's which tool turns the knowledge you already have into trustworthy, cited answers in the place where people actually ask.

Two warnings from someone who has rolled these out. First, the AI is only as good as the articles underneath it. If your leave policy page is out of date, the bot will confidently give wrong answers with a straight face, and staff trust it more than they'd trust a dusty document, which makes errors worse, not better. Accuracy work comes before AI work, always.

Second, check what's metered. Almost every platform now rations AI answering by credits or question allowances per seat per month. Slite caps questions on its cheaper plan, Confluence meters Rovo credits, and Guru defines AI allowances in each customer's contract. Read that small print before you promise the whole company an oracle.

The insistence on citations matters more than it sounds. An answer with a link to the source page can be checked and corrected. An answer without one is just a plausible sentence, and plausible sentences are exactly what gets businesses into trouble.

UK Data Protection: The Bit You Can't Skip

This is where the UK specifics genuinely diverge from the American advice that dominates search results, so pay attention here even if you skim everywhere else.

Your knowledge base will almost certainly contain personal data as defined by UK GDPR and the Data Protection Act 2018, both enforced by the Information Commissioner's Office, the ICO. Staff contact lists, org charts, photos in onboarding guides, HR procedures that reference real cases. The moment personal data goes in, the rules apply. Three practical consequences follow.

Set permissions before you upload anything sensitive. Every decent platform supports permission groups. Use them from day one, because retrofitting access control after someone has already seen a salary band document is a conversation nobody enjoys. Data minimisation is a core UK GDPR principle: don't put personal data in the knowledge base unless there's a genuine reason for it to be there.

Think before you point AI at personal data. The ICO's guidance on AI and data protection sets out how it interprets UK GDPR for organisations deploying AI systems that process personal data, covering fairness, transparency, lawfulness, and accountability. For high risk processing you're expected to complete a Data Protection Impact Assessment, a DPIA, which is a structured written assessment of what could go wrong and how you'll prevent it. For a bog standard internal wiki of process documents, a DPIA is unlikely to be required. If you're connecting an AI assistant to HR records or letting it answer questions about identifiable individuals, do one. The ICO publishes an AI and data protection risk toolkit on its website that walks you through it, and the Information Commissioner has said plainly that the ICO can and will fine organisations that breach data protection rules when deploying AI.

Know where your data lives. Ask any vendor where UK customer data is hosted and what their arrangements are for international transfers. The big platforms have standard answers to this, and any vendor that can't answer quickly is telling you something. Also give staff a simple written rule about what may and may not be pasted into AI tools, which is exactly the kind of internal guidance UK law firms have been recommending since the ICO's 2023 update.

None of this should scare you off. It's an afternoon of sensible setup, not a legal project. But it does mean the free for all approach of "dump everything in and sort permissions later" is not just untidy in Britain, it's a compliance risk.

Writing Articles People Actually Find

The quality bar for internal documentation is much lower than people fear. Nobody needs elegant prose. They need to find the answer in under a minute. A few rules get you most of the way.

Title every article as the question people actually ask. "How do I claim expenses" beats "Expense Reimbursement Policy" every single time, because search works on the words people type, and people type questions. If your team calls the till system "the Epos," use that word in the article even if the vendor calls it something grander.

Put the answer in the first two lines, then the detail below. Most readers want the short version. Write it like you'd answer in person, then add screenshots and edge cases for the minority who need them.

Keep one topic per article. A single monster page called "IT Stuff" is unfindable. Twelve short pages, one per task, each show up in search for the right query.

Write for someone with zero context. The test I use: could a person who started on Monday follow this without asking anyone anything? Get your newest employee to try it. Where they get stuck, the article needs work, and new starters are brilliantly free of the curse of knowledge that afflicts the rest of us.

Ownership and Review Dates, or Why Most Knowledge Bases Die

Here's the uncomfortable truth from watching these projects for years: the launch is easy and almost irrelevant. Knowledge bases don't fail at launch, they fail eleven months later when a third of the content has quietly gone wrong, someone follows an outdated process, gets burned, tells their colleagues, and everyone reverts to asking humans. Trust, once lost, is nearly impossible to rebuild.

The defence is boring and works. Every article gets exactly one named owner, a person not a department, and a review date. Most content is fine on a six month cycle. Anything touching money, law, or safety gets three months. When the date arrives, the owner spends five minutes confirming the article is still right or fixing it. Tools like Slite automate the prompting and flag unverified pages; in Notion or Confluence you can build the same thing with a simple database of articles, owners, and dates. The mechanism matters less than the habit.

Add two feedback loops. First, a "was this helpful" prompt or a way to comment on any page, so readers flag problems the moment they hit them. Second, and this is the one that keeps the knowledge base growing on its own: every time someone asks a human a question that should have been answerable from the knowledge base, the answer gets written up before the thread dies. Reply with the answer and the new link. It feels slightly officious for about three weeks, and then people start checking before they ask, which is the entire game.

One more honest note: incentives beat exhortation. Asking people to "contribute to the wiki" achieves nothing. Making "documented one process" part of what a good month looks like for team leads achieves quite a lot.

Put It Where People Already Work

A knowledge base that requires people to remember to visit it will not be visited. The trick is to make it ambient.

Connect it to your chat tool, so questions asked in Slack or Teams get answered by the bot in the channel where they were asked. Pin the knowledge base link in every channel and email signature where questions tend to arrive. Make it the homepage on shared machines if you have them. And when you answer a question in person, answer with the link, kindly and consistently, so the habit spreads by osmosis rather than mandate.

For onboarding, go one step further and make the knowledge base the onboarding. A new starter's first week checklist should live in it and link out to everything else, which means every new employee learns on day one that this is where answers live. Companies that do this well find onboarding time drops noticeably, because the new hire isn't rationing their questions to avoid annoying busy colleagues; they're self serving from a library that never sighs.

If I were starting from scratch in a UK business of 10 to 50 people this week, here is exactly what I'd do.

Week one: collect questions. Note every repeated question, mine the chat history, ask managers for their top five interruptions. End the week with a ranked list of about twenty. Choose your tool at the end of this week, not the start, and take the free tier where one exists.

Week two: write the top ten articles, question phrased titles, answer first format. Set up permission groups before uploading anything sensitive, and write the one page rule for staff about personal data and AI tools. If you're wiring AI answering to anything involving people data, run through the ICO's DPIA checklist now, while it's cheap.

Week three: soft launch to one team. Watch what they search for and where they fail to find things. Fix titles, split long pages. Assign owners and review dates to everything that exists so far.

Week four: launch to everyone with the redirect habit: answers come with links, and every human answered question becomes an article the same day. Book a 30 minute review in your calendar for three months out to check what's being read, what's being ignored, and what's gone stale.

That's it. No committee, no six month content audit, no consultant. A fortnight to useful, a month to embedded.

An Honest Reality Check

A few limits worth naming so you go in with clear eyes.

A knowledge base answers known, repeatable questions. It will not replace judgement, mentoring, or the conversations where problems actually get solved, and it shouldn't try. If a question requires context about a specific client or a live situation, that's a conversation, not an article.

The AI layer is impressive and fallible. It will occasionally stitch together an answer from two half related pages and present it with total confidence. Citations and a culture of clicking through to the source are your safety net, not optional extras.

And the ongoing cost is real, just small. Budget an hour or two per week across the whole company for maintenance forever. That sounds like a lot until you set it against nine hours per person per week of searching, at which point it's the best trade in the building.

The businesses that get this right aren't the ones with the fanciest software. They're the ones where writing down the answer became a normal part of answering, and where someone cared enough to keep the library honest. Build your company knowledge base around those two habits and the tool choice almost takes care of itself. Start collecting your ten questions today, and by this time next month the questions can start answering themselves.