How to quality assure your knowledge base on an ongoing basis
Quality assurance of knowledge is a shared task. Review matters — but review is not enough. Quality is secured in everyday work, when employees use knowledge, spot gaps and give feedback.
Building a good knowledge base is one thing. Keeping it good is something else entirely.
Many organisations spend a lot of time getting the content right from the start. They gather answers, write guides, structure articles and get employees to use the system. But after launch, something often happens. Everyday operations take over.
Products change. Processes get updated. New exceptions appear. Prices, rules, workflows and responsibilities shift. Employees spot small errors, but don't always report them. Product owners change something without informing support. Support notices recurring questions, but the knowledge owner or product owner never sees the pattern.
Quality slowly declines. Not because the knowledge base was poor from the start, but because quality assurance cannot rest on one person alone.
Quality assurance of knowledge is a shared task. It requires everyone in the organisation to know their role: support staff, knowledge editors, knowledge owners, product owners, subject-matter experts and managers.
Review matters. But review is not enough. If quality is only secured through scheduled reviews, you discover errors too late. The most important quality assurance happens in everyday work, when employees use knowledge, spot gaps, give feedback and get corrections into a clear workflow.
And when something changes, the knowledge base should be updated first. Not as the last step after an email, a meeting or a Teams message.
If new knowledge is first sent out by email and only later added to the knowledge base, several versions of the truth immediately appear. Some employees read the email. Others save it. Some overlook it. And the knowledge base, which should be the shared source, is already lagging behind.
Quality is not a state. It is a shared process.
What does quality assurance of knowledge actually involve?
Quality assurance of knowledge is about ensuring that the content in the knowledge base is correct, up to date, consistent and easy to use. But it's also about something more organisational: that everyone knows how they contribute to quality.
A knowledge base doesn't become reliable because one person reads through all the articles occasionally. It becomes reliable because the organisation has a shared workflow for spotting, reporting, assessing, approving and correcting knowledge.
Quality assurance is therefore about several things at once.
| Area | What it means in practice |
|---|---|
| Correctness | The content must be factually correct |
| Currency | The content must follow changes in products, processes and rules |
| Consistency | Answers, wording and workflows must align across the organisation |
| Usability | Employees must be able to find and use the answer in everyday work |
| Ownership | It must be clear who owns a given knowledge area |
| Feedback | Employees must easily be able to report errors, gaps and ambiguities |
| Approval | Changes must be quality assured by the right expert or owner |
This matters because knowledge is used in daily operations. Support staff use it in customer conversations. New employees use it during onboarding. AI solutions can use it as the basis for answers. Customers and citizens can be indirectly affected by it through the answers they receive.
So quality is not just an editorial matter. It is an operational responsibility.
If employees don't know how to react when they find an error, the error often just sits there. If the product owner doesn't know that product changes also require a knowledge update, the content quickly becomes outdated. If the knowledge owner doesn't hear about recurring support questions, they lack the basis for improving the content.
Quality assurance therefore starts with understanding roles. Who uses knowledge? Who owns knowledge? Who spots errors? Who approves changes? Who ensures that updated knowledge is actually published in the knowledge base?
Only once those roles are clear can review, approval and data work effectively.
Build a review cycle that is actually followed
A review cycle matters. But it must not stand alone.
Review should not be the primary way you discover errors. If an article is only corrected when it reaches its next scheduled review, incorrect knowledge may have been in use for weeks or months.
Review should therefore be seen as a supplementary safety net. Day-to-day quality assurance happens when employees use knowledge, spot gaps and give feedback. Review ensures that no content goes unattended for too long.
A review cycle should therefore be built on top of a clear division of roles.
| Role | Contribution to quality assurance |
|---|---|
| Support agent | Uses knowledge in practice and reports errors, gaps or unclear answers |
| Knowledge editor | Structures, edits and coordinates changes |
| Knowledge owner | Responsible for an area being correct and up to date |
| Product owner | Ensures product changes are translated into updated knowledge |
| Subject-matter expert | Approves factual correctness and exceptions |
| Team leader | Ensures employees use the knowledge base and give feedback |
| Quality manager | Follows up on patterns, errors and areas for improvement |
The point is not that everyone should be able to edit everything. The point is that everyone should know their contribution.
The support agent doesn't necessarily need to correct the article themselves. But they need to know how to flag that something is wrong or missing.
The product owner doesn't necessarily need to write the support text. But they need to understand that a product change isn't finished until the relevant knowledge has been updated in the knowledge base.
The knowledge owner doesn't necessarily need to spot every error themselves. But they need to take responsibility for their area being correct once feedback or changes arrive.
That's how quality assurance becomes part of the organisation.
Review still needs a rhythm. But the rhythm should be practical and risk-based.
| Type of content | Review rhythm |
|---|---|
| Critical content on pricing, terms, compliance or rules | Fixed review, e.g. quarterly |
| Product and process content | On changes, plus supplementary periodic review |
| Standard answers and customer-facing wording | Periodic review and ongoing feedback |
| General guides | Annually or as needed |
| Low-risk content | Light periodic review |
The most important thing is not that everything is reviewed equally often. The most important thing is that review doesn't become a substitute for ongoing feedback.
Review keeps the knowledge base clean over time. Feedback keeps it close to reality.
Approval of knowledge — who signs off on what?
Approval of knowledge isn't only about who clicks “approve”. It's about ensuring that changes land in the right place, in the right order.
When something changes in the organisation, the knowledge base should be the first place the change becomes available as approved knowledge. Not the email. Not the Teams thread. Not a slide from a meeting.
Email and meetings can certainly be used to inform people about the change. But the authoritative version should live in the knowledge base. Otherwise the email quickly becomes the real source, and the knowledge base becomes an archive that gets updated afterwards.
This is where many organisations lose control. A price changes. The product owner sends an email. A team leader mentions it in a meeting. An employee saves the email. Another writes it into their own notes. A third still uses the old article in the knowledge base. Suddenly several truths exist.
A good approval process should therefore ensure two things:
- That changes are approved by the right expert.
- That the approved version is published in the knowledge base as the first shared source.
A practical process could look like this:
| Step | What happens? | Responsibility |
|---|---|---|
| 1. A change arises | A product, process, price, term or workflow changes | Product owner, process owner or subject-matter expert |
| 2. Knowledge is updated | The change is turned into an article, standard answer or guide | Knowledge editor and relevant owner |
| 3. Expert approval | The content is checked by the right expert or knowledge owner | Knowledge owner, product owner or specialist |
| 4. Publication in the knowledge base | The approved version is made available | Knowledge editor |
| 5. Communication | The organisation is informed and directed to the knowledge base | Manager, knowledge editor or product owner |
| 6. Feedback and follow-up | Employees can report ambiguities or errors | All users of knowledge |
The order is crucial. First, knowledge is updated and approved in the knowledge base. Then the change is communicated with a link to the updated source.
This teaches the organisation that the knowledge base is the place to find the current knowledge. Not the email. Not the chat. Not the colleague who happened to be in the meeting.
The level of approval should, however, depend on risk.
| Content type | Approval level |
|---|---|
| Critical or compliance-related content | Expert approval before publication |
| Pricing, terms and legal wording | Approval from the relevant owner or specialist |
| Product changes | Product owner approves the facts, knowledge editor adapts the wording |
| Internal workflows | Process owner or team leader approves |
| Minor language corrections | Can often be handled editorially |
| Feedback-based clarifications | Depends on risk and topic |
It needs to be controlled. But it must not become heavy-handed. If every change requires three meetings and four approvals, employees will start sharing shortcuts around the knowledge base again. A good process is therefore strict enough to ensure quality, but simple enough to be followed.
Governing knowledge content — use data to find the problems
Quality assurance becomes stronger when it draws on both feedback and data.
Support staff often spot problems first. They notice when an article doesn't help. They see when customers ask the same question again and again. They spot when an answer is unclear, outdated or missing an exception.
That's not noise. That's quality data.
Typical signals from employees might be:
- “I couldn't find the answer.”
- “The article doesn't match the situation the customer describes.”
- “There's an exception missing.”
- “Customers misunderstand this wording.”
- “We get a lot of questions on this topic.”
- “This article says something different from the message we got from product.”
- “I still ask a colleague to clarify this.”
If that feedback isn't captured, the organisation loses its most important source of improvement. But feedback should be supplemented with system data.
| Data signal | What it might mean |
|---|---|
| Many searches with no results | Content is missing, or articles use the wrong terms |
| Low-usage articles | The content is hard to find, irrelevant or duplicated |
| Many clicks with no resolution | The article doesn't answer the question well enough |
| Recurring questions to support | The knowledge base doesn't cover customers' actual needs |
| Negative feedback on articles | The content is unclear, incorrect or insufficient |
| Multiple articles on the same topic | There's a risk of overlap and conflicting answers |
| High usage of critical articles | The content deserves extra attention and a clear owner |
Data makes quality assurance more targeted. Instead of reviewing everything equally, you can focus on the areas where the risk or need is greatest.
But data shouldn't only sit with the knowledge manager. It must be shared with the relevant roles.
Product owners need to see where product knowledge generates questions. Knowledge owners need to see where their area has low quality. Support managers need to see where employees lack answers. The knowledge editor needs to use data to prioritise improvements.
When data becomes shared, quality assurance becomes shared too.
Making it part of everyday work — not a project
1. Everyone knows their role
Quality assurance only works if it becomes part of everyday work. Not a project. Not an annual clean-up. Not something that depends on one committed employee.
If quality assurance is to hold, it needs to be organisationally anchored. That requires five things in particular.
2. The knowledge base is updated first
Support needs to know how to give feedback. Product owners need to know when to report changes. Knowledge owners need to know which areas they own. The knowledge editor needs to know who to involve. Managers need to ensure the work is prioritised.
If roles are unclear, quality declines.
3. Feedback is easy to give
When something changes, the approved knowledge must be updated in the knowledge base first. Then the change can be communicated.
That can happen by email, in Teams, at meetings or through other channels. But the communication should point back to the knowledge base as the shared source.
This avoids important knowledge living in messages that some have read, others have missed, and no one can find again later.
4. There's clear ownership
Feedback needs to be quick and given in context. The employee shouldn't have to leave the knowledge base, write an email and hope someone follows up. It should be easy to flag an article, suggest a correction or point out missing knowledge.
5. Review supplements day-to-day feedback
Feedback needs to land with someone. If no one owns an area, improvements become random. Every category, article type or knowledge area should therefore have a clear owner.
Review ensures content is reviewed systematically. But day-to-day feedback ensures problems are spotted as they arise. Both are necessary. But ongoing feedback is what keeps the knowledge base close to reality.
How Responza Author supports ongoing quality assurance
Responza Author supports the work of keeping knowledge correct, up to date and usable over time. It makes it easier to turn quality assurance into a shared workflow instead of a manual clean-up that happens too late.
With Author, the organisation can work more systematically with:
- feedback from employees
- ownership of knowledge areas
- tasks for knowledge owners, product owners and subject-matter experts
- approval of knowledge
- management of changes
- an overview of content requiring action
- data insight into searches, usage and missing answers
- supplementary review and maintenance
This means quality assurance doesn't only sit with the knowledge editor. It's distributed across the roles that actually know the knowledge and use it in everyday work.
Support can give feedback when something isn't working. Product owners can ensure changes get turned into updated knowledge. Knowledge owners can take responsibility for their areas. The knowledge editor can coordinate, structure and publish. And management can gain an overview of whether the process works.
When feedback, ownership, approval and data are brought together in one clear process, quality assurance becomes far more robust. That's how the knowledge base stays a reliable source. Not just on the day it launches, but every day after that.
Quality assurance is a process, not a task you tick off
A knowledge base is only valuable if employees can trust it. That's why quality assurance of knowledge shouldn't be treated as a one-off task or something one person can solve alone. It's a shared process that must be built into everyday work.
Key takeaways
- 1Quality assurance requires everyone to know their role — support, knowledge owners, product owners, subject-matter experts and managers.
- 2The most important quality assurance happens continuously, when employees use knowledge and give feedback.
- 3When something changes, the knowledge base must be updated first, and communication should point back to the shared source.
- 4Review still matters, but it's a supplementary checkpoint, not the whole solution.
Frequently asked questions
What is quality assurance of knowledge?
+
Quality assurance of knowledge is about ensuring that content in a knowledge base is correct, up to date, consistent and easy to use. It's also about everyone in the organisation knowing how they contribute to quality. Support, knowledge owners, product owners and subject-matter experts each play their part.
How often should you review the content of a knowledge base?
+
Review should depend on the content's risk and rate of change. Critical content on pricing, terms, compliance or processes should be reviewed more often than general guides. But review should supplement ongoing feedback from the organisation, not replace it.
How do you build a good approval process for new content?
+
A good approval process should ensure that new or changed knowledge is first updated and approved in the knowledge base. The change can then be communicated with reference to the shared source. The knowledge editor can ensure structure and language, while knowledge owners, product owners or experts approve the facts and correctness.
How do you identify which content has poor quality?
+
You identify poor quality by combining employee feedback with data from the knowledge base. Searches without results, articles with negative feedback, low usage or many recurring support questions can point to problems. Support staff are often the first to discover when knowledge isn't working in practice.
What is the difference between reviewing knowledge and updating knowledge?
+
Review is a planned assessment of whether content is still correct, relevant and usable. Updating is the actual change to the content. In a good quality assurance process, updates happen not only after review but also continuously, whenever employees, knowledge owners or product owners spot changes or errors.
Linnea Laumand
Knowledge Management & AI-konsulent
Linnea skriver om vidensstruktur, indholdskvalitet, governance og AI-klar viden. Hun har mere end 10 års erfaring med knowledge management i praksis – blandt andet som knowledge manager i Erhvervsstyrelsen.
View author profile →Want to see how Responza supports ongoing quality assurance of knowledge?
Book a demo and see how Responza turns feedback, ownership, approval and governance of knowledge content into a natural part of your workflow.