Best practices on creation of knowledge bases

[Daan Delva]

While going through the best practices documents for knowledge management, I couldn't find any recommendations on the best approach for handling knowledge bases. At the moment, we only have a knowledge base for the Service Desk (end users). However, more and more technical teams are asking if they can have their own knowledge bases. What is the recommended approach in this situation? Should each team have its own separate knowledge base, or is it better to have a single 'technical' knowledge base that covers everything?

Thanks in advance for sharing your feedback.

[GlideFather]

Hi @Daan Delva

the best practice is to match what suits the users the best... for some companies it will be a single KB for others it will be 14... I don't think there's any universal rule, of course the lower number the easier to maintain, but that goes along with the managers and owners of KB. Also translations... 

I would recommend to have as few KBs as possible, then the categories and subcategories are recommended not to be too many (but what is too many ,right?) and not going too depp, maximum 2 subcategory levels, not more.

But this is very individual for each organisation 😛 sorry for being so abstract...

[vaishali231]

Hey @Daan Delva 

In general, the recommended approach is to design knowledge bases around audience and purpose, not around individual teams.

For most organizations, it works best to keep the Service Desk or end user knowledge base separate, since that content is written in simple language and focused on self service, FAQs, and request guidance.

For technical teams, the usual best practice is to start with a single shared technical knowledge base rather than creating one per team. Within that technical knowledge base, you can use categories, metadata, and ownership to separate content by application, platform, or service. Access controls and roles can be used to make sure only the right teams can view or maintain their content.

This approach has a few key benefits.
It reduces duplication of articles across teams.
It makes cross team troubleshooting easier.
It simplifies governance, reporting, and content lifecycle management.
It keeps search results more consistent and useful.

Creating separate technical knowledge bases should generally be reserved for specific cases, such as regulatory or compliance requirements, strict data separation needs, or very large environments where teams operate independently with different governance models.

*************************************************************************************************************
If this response helps, please mark it as Accept as Solution and Helpful.
Doing so helps others in the community and encourages me to keep contributing.

Regards
Vaishali Singh

[Rum]

We have three knowledge bases setup; ServiceNow has been implemented about 3 years now.  I create and manage a lot of processes (including IT and non-IT combined), so I put processes/ KB articles that have both IT and non-IT combined in the Self-Service knowledge base. This allows everyone in the organization to access them. There are teams preferred to use SharePoint, so we add link directly to ServiceNow to ensure users can access to the latest revisions.

* IT Knowledge Base - for IT users, access through ServiceNow

* Self-Service Knowledge Base - IT and Service Desk can create, update KB articles in this knowledge base, access by everyone in the organization. Users access KB articles reside in this knowledge base through IT Hub Self-Service Portal.

* Information Security Knowledge Base - only Information Security personnel can create/ update/ access to the KB articles.