Your insights: separate Knowledge Bases per country or only one with advanced user criteria

[Karolina]

Hi All,

I was wondering you could share your best practices and insights - ServiceNow kind of recommends having knowledge bases set per audience, e.g., if you have HR content both for Canada and US, you should have two separate knowledge bases. Do you follow this principle? If so, how does it work for you? Or maybe you decided against it for some valid reasons?

We have one joined HR KB for all countries and use the user criteria to govern the visibility, mainly because for some countries there is little local content (or content in general) and that set-up makes maintenance easier in my opinion, but maybe your experience shows it's actually worth to have multiple KBs?

[Eoghan Sinnott]

Hi Karolina, 

For our Self Serve content, which is open to our entire company, we have one knowledge base and then just use location identifiers in the Short Description of the article to differentiate the processes.

So for example if the process is different, we would have one article for "How do I order a new headset - US" and another for "How do I order a new headset - Canada". As we are a global company it would be too much to create new Knowledge Bases for each geographical region.
There is also the possibility of using Knowledge Blocks, and putting Can Read criteria on them based on the location. So you could have one article with multiple knowledge blocks inside of them, and then depending on users location they will only see what is relevant to them. If I could start again from scratch this would probably be the route I would take!

[Josh Gold]

Hi @Karolina I maintain a knowledge base for Unito and we've often discussed the pros and cons of adding multiple KBs for different audiences. I think it has benefits and drawbacks that really depend on how much content you have in there and how you're maintaining it. Is this a KB for internal teams or external end users/customers?

In our case, our KB is for our customers and we've reached a point where manually maintaining it just doesn't make sense because there's too much work. So we're in the process of automating article maintenance so it isn't such a hassle.

But that would be my first consideration: what kind of volume are you working with? If you did create separate KBs, how many articles would you have in each? Are they the same articles with minor differences? If so, don't forget that the volume would then double. So any change you make to one has to be repeated in the other so even more of your time will be spent copy pasting details between articles. 

If you're not ready to automate your KB just yet, a simple workaround is to expand each article to include subheadings for Canada and the US (using your example) to highlight any key differences for your audience. That's how I try to maintain structure/order with as few articles as possible without letting any individual article bloat too much. If that does start to happen, I break up the article into separate pieces as needed. 

For me the goal is to maintain as low a volume of content as possible to save myself time in the long run. I hope that helps!

[Karolina]

Hi Josh,

The thing is we don't have a lot of content for some countries, so for me it has never made much sense to create separate KBs per country only to have like 5 local articles and then global content, because that would just create so much duplication and maintenance that it's just not worth it. I prefer one HR internal and one HR external KB with an extensive use of knowledge blocks, but the topic popped up during one of team discussions and I've started wondering how it's done in other companies.

Would you mind elaborating on how you set up the maintenance automation? We have a custom expiry workflow, but tbh most agents struggle to complete the task of reviewing and extending articles.

[wow-on-now]

Hi @Karolina

A recommended approach would be to have separate knowledge bases based on context and not on audience. So your internal knowledge and external knowledge would reside separately and if you have very specific purpose such as internal HR knowledge etc. then it would be recommended in a separate space. Generally, if you have country specific differences within few articles then just use knowledge blocks while keeping it in the same knowledge base. Same goes for articles. This will help with mental model and organization.