# Building an IT knowledgebase that does not die after forty articles > Why knowledgebase projects stall at the same point every time, and the structural change that stops it happening. **URL:** https://cubemsp.co.uk/guides/building-a-knowledge-base-that-survives **Published:** 2026-08-04 | **Updated:** 2026-08-06 | **Reading time:** 8 min Every managed service provider has an abandoned knowledgebase. Usually two. They reach roughly the same size - somewhere around forty articles - and then stop, and the reason is always the same. It is not laziness, and it is not a tooling problem. It is that writing documentation is structurally separate from doing the work, it happens after the pressure is off, and the pressure is never off. ## Why knowledgebase projects stall Consider what writing an article actually requires. Somebody must remember a problem they solved, recall the detail accurately, find time when nothing is urgent, decide where it belongs, and write it in a form somebody else can follow. Each step is a point at which the task loses to something more immediate. The result is predictable: an initial burst of enthusiasm producing the articles for problems everybody already knows how to solve, followed by silence on everything encountered since. ## The only moment documentation is cheap There is exactly one point at which writing an article costs almost nothing: the moment the problem is resolved. At that instant the symptom, the diagnosis, the false starts and the fix are all in one person’s head and, if the incident was recorded properly, already written down in the ticket. An hour later it is expensive. A week later it is a research task. This is why "we will document it later" never survives contact with a service desk. > If capturing knowledge is a separate task from resolving the incident, it will lose. Every time, in every organisation, regardless of how much everybody agrees it matters. ## The structural fix The change that works is making the article a by-product of resolution rather than a subsequent task. In practice that means the resolution notes on the incident are the raw material, and turning them into an article is an editing job rather than a writing job. This is what makes AI useful here. The model is not being asked to know anything. It is being handed a specific incident with its symptom, diagnosis and fix, and asked to restructure that into a reusable article. That is a summarisation task, which is what language models are actually reliable at. The technician then spends a minute correcting it rather than twenty minutes writing it. That difference is the entire reason the library keeps growing. ## Why a human must still approve every article Generated documentation is confidently written, which makes it more dangerous when wrong, not less. A subtly incorrect article does not sit inert - it gets found, followed and trusted, potentially for years. Approval also serves a second purpose. The act of reading and correcting is when institutional judgement gets added: the caveat about the client whose configuration is different, the warning about the step that must not be run during business hours. That is the knowledge that matters most and no model can infer it. ## Findability matters more than volume A library of five hundred articles nobody can search is worse than fifty that surface reliably, because it creates the belief that the answer is documented while providing no route to it. Keyword search is the usual failure. The technician searching "Outlook keeps asking for password" does not find the article titled "Modern authentication token expiry on hybrid mailboxes", because the two share almost no words. Semantic search matches meaning rather than terms, which is why it changes the outcome rather than merely improving it. The stronger pattern is not to require searching at all: surface the closest previous incidents at the point a new one is logged, before anybody has decided to go looking. ## Keeping it accurate over time - Give every article an owner and a review date. Documentation untouched for two years should be flagged as suspect rather than quietly trusted. - Record which incidents an article came from, so its evidence base can be checked. - Scope client-specific articles to the client. One client’s quirk in the general library will eventually be applied to somebody else. - Delete confidently. An article describing a system you decommissioned last year is worse than no article. - Track which articles are actually opened. The ones nobody reads are telling you either that they are not needed or that they cannot be found. ## Key takeaways - Knowledgebases stall because writing is separate from the work, not because people are lazy. - Resolution is the only moment when capturing knowledge is cheap. - Use AI to restructure a specific incident into an article, never to supply knowledge it does not have. - A human approves every article - correction is where institutional judgement gets added. - Findability beats volume, and surfacing beats searching. ## Frequently asked questions **How many articles should we aim for?** None, as a target. Aim for coverage of the problems that recur, which you can measure from your own incident data. A count is a vanity metric and encourages articles nobody needs. **Should client-specific documentation live in the same place?** Same library, scoped to the client. Separate systems mean people search one and not the other, which is how the wrong procedure gets applied to the wrong client. **Is it safe to let AI write documentation?** It is safe to let it restructure a specific resolved incident into an article, with a human approving the result. It is not safe to ask it how to fix something and publish the answer, and the difference between those two is not subtle. **What about existing documentation in a wiki?** Import it and index it. The problem with most wikis is findability rather than content, and existing material is often perfectly good once it can actually be surfaced. ## Relevant solution pages - **Knowledge Base Software** - A knowledgebase that builds itself from resolved incidents, with semantic search over your own history and a human approving every article. https://cubemsp.co.uk/software/knowledge-base-software - **Service Desk Software** - A real queue instead of a shared mailbox - incidents logged against the client, site and service they affect, with priority, ownership and time. https://cubemsp.co.uk/software/service-desk-software - **IT Service Management Software** - Incidents, requests, problems and knowledge handled consistently, with the service catalogue and the client record in the same system. https://cubemsp.co.uk/software/it-service-management-software ## Related guides - **Client service reviews that are worth the meeting** - What to put in a quarterly service review, what to leave out, and how to stop it taking a day to prepare. https://cubemsp.co.uk/guides/client-service-reviews-that-work - **Signs your MSP has outgrown spreadsheets and a shared mailbox** - How to tell the difference between a provider that is busy and one whose systems have quietly stopped keeping up - and what to do first. https://cubemsp.co.uk/guides/signs-you-have-outgrown-spreadsheets - **How to choose MSP software without regretting it in eighteen months** - A practical process for evaluating PSA and MSP management platforms, including the questions that actually predict how the implementation will go. https://cubemsp.co.uk/guides/how-to-choose-msp-software ## Contact - **Product:** CubeMSP - **Trading name of:** Cube Systems Limited (company number 17220899, ICO registration number ZC216972) - **Email:** hello@cubemsp.co.uk - **Sales:** sales@cubemsp.co.uk - **Support:** support@cubemsp.co.uk - **Telephone:** 01234 672 617 (+441234672617) - **Address:** Unit 11, Olney Business Park, Osier Way, Olney, Buckinghamshire, MK46 5FP - **Opening hours:** Monday to Friday, 9am to 5.30pm - **Part of:** Crushed Ice Group (https://crushedicegroup.co.uk)