The knowledge already exists. The problem is that it is unfindable.
Early accessKnowledge Base Software
A knowledgebase that builds itself from resolved incidents, with semantic search over your own history and a human approving every article.
- Part of CubeMSP
- Serving businesses across the UK
- 01234 672 617
Every managed service provider has a knowledgebase project that stalled. The reason is always the same: writing articles is a separate task from doing the work, it happens after the pressure is off, and it therefore never happens. CubeMSP inverts that. The moment an incident is resolved is the only moment anybody knows both the symptom and the fix, so that is when a draft article is produced - from the incident itself, by the AI, for a technician to correct and approve in a minute rather than write from scratch in twenty. What comes out is indexed for semantic search, so the next person meets the answer rather than having to go looking for it.
- At resolution
When the article is drafted, not on a Friday
- Human
Approves every article before publication
- By meaning
Search matches the problem, not the wording
What it does
Inside knowledge base software
The parts of CubeMSP that make up knowledgebase. Everything here shares one database, so nothing needs re-keying between them.
Drafted from the incident
When an incident is resolved, the symptom, the diagnosis and the fix are already recorded. An article is drafted from them and put in front of a human to approve, edit or discard.
Semantic search, not keyword matching
Search by describing the problem in your own words. Meaning is matched rather than exact terms, so "Outlook keeps asking for the password" finds the article about a broken modern-authentication token.
Nothing published without approval
The AI drafts; a person decides. An article is not visible to the desk until somebody with the right role has read it and said yes. Wrong documentation is worse than none.
Traceable back to the incidents
Every article records the incidents it came from, so you can see the evidence behind it - and, from an incident, the article it contributed to.
Client-specific where it needs to be
Some knowledge is universal and some applies to exactly one client’s awkward legacy application. Articles can be scoped either way, and client-specific articles surface first for that client.
Review dates on every article
Articles carry a review date and an author. Documentation that has not been touched in two years is flagged as suspect rather than being quietly trusted.
In practice
Problems this actually solves
Anonymised, but not invented. These are the situations businesses describe to us before they change anything.
A knowledgebase project abandoned twice
The situation
Two attempts had been made to document common fixes - once in a wiki, once in a shared document library. Both reached about forty articles and stopped, because writing them was somebody’s Friday afternoon job and Friday afternoons kept being needed for something else.
What changed
Articles are now drafted automatically at resolution and approved in a minute or two. The library grew past two hundred articles in the first quarter without anybody being asked to write documentation.
Knowledge that left with an engineer
The situation
A senior technician of nine years’ standing retired. Within a month the desk had spent days rediscovering three things he would have known instantly, and one client noticed the difference.
What changed
His last eighteen months of resolved incidents had been drafted into articles and indexed. The retrieval surfaces them by meaning, so his experience is still answering questions.
Documentation nobody could find
The situation
The information existed, spread across a wiki, a shared drive and several long email threads. Finding it required knowing what it had been called, which meant asking the person who wrote it.
What changed
Semantic search over one indexed corpus means the technician describes the symptom and gets the answer. Nobody needs to know the filename any more.
How it happens
What implementation actually involves
No mystery, no discovery phase that quietly becomes the project. Five stages, and you will know what each one costs before it starts.
Discovery
A structured session mapping how you run now - the PSA you have outgrown, the spreadsheet of renewals, the shared mailbox that is really your ticket queue, and the review deck somebody rebuilds by hand every six months. We come back with what the platform covers as standard and what needs building.
Configuration
Your service catalogue, ticket taxonomy, boards, roles, approval limits and review templates set up to match how you actually work - not a demo tenant with your logo dropped on it. Your categories, not ours.
Data migration
Clients, contacts, sites, services, renewal dates and enough ticket history to make the knowledgebase and similar-incident retrieval useful on day one. An empty AI is a useless AI, so the history matters more here than in most migrations.
Training & rollout
Role-based training - the service desk learns logging and resolution, account managers learn reviews and renewals, directors learn the reporting. We usually pilot with one technician and one client before opening it up.
Ongoing support
UK support from the people who built the platform and use it themselves, with a named contact, agreed response times, and a roadmap you can influence. Being a small vendor is an advantage here and we intend to keep it.
You might call it something else
Knowledgebase goes by a lot of names - if you searched for any of these, this is the page you wanted.
- IT knowledge base software
- Knowledge management software
- IT documentation software
- Internal wiki for IT teams
- Runbook software
- AI knowledge base
Questions
The things people ask first
No, and it will not be made to. Generation produces a draft; a person with the right role approves it. This is a deliberate design rule rather than a default setting, because confidently wrong documentation costs more than no documentation.
No. Your content is sent to the model provider to answer a specific request and is not used for training. Retrieval is scoped to your tenant by construction - a search cannot reach another provider’s corpus because it is not in the index being searched.
Text is converted into a numerical representation of its meaning, and searching finds the closest matches to your description rather than documents containing the same words. It is why describing a symptom finds an article that never used your phrasing.
Yes. Drafting from incidents is the mechanism that makes the library grow, not the only way in. Hand-written articles, runbooks and client-specific procedures sit in the same library and are indexed identically.
An article can be scoped to a client, and those articles rank first when working on that client’s incidents. General articles remain available to everyone, so one client’s quirk does not pollute the general library.
Related
Other things we can put right
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.
Read moreMSP Ticketing System
Multi-client ticketing built for a provider - client, site and service on every ticket, and a clean line between one customer’s data and another’s.
Read moreIT Service Management Software
Incidents, requests, problems and knowledge handled consistently, with the service catalogue and the client record in the same system.
Read moreMSP Software
One system for clients, services, renewals, incidents, projects and reviews - built in the UK by a managed service provider.
Read more
Part of a bigger system
Knowledgebase is one part of CubeMSP. You can start here and switch the rest on later - it is the same system, not a separate purchase bolted on.
Talk to us
Is knowledgebase your actual problem?
Sometimes it is not. Tell us what is going wrong and we will tell you whether this is the right thing to fix first.