Knowledge Article Naming Conventions: What are best practices and what is the value?

[Lauren Methena]

Where has applying a naming convention to your knowledge base articles helped - and where has it not made as much of a difference?

What are some of the biggest gains you've seen from having a naming convention?

What are some of the things you consider when applying a naming convention to your knowledge articles?

Back story: We have both a customer-facing knowledge base and an agent-only/backend base. We've seen the benefit of a simple naming convention in the customer-facing KB. However, in the backend KB, users are more likely to find what they're looking for by searching by topic or category to get more targeted results. There are some assumptions I'm making to reach this conclusion (and admittedly they may not all be correct, such as assuming the backend users will be more sophisticated users than our customers). However, I want to make sure we'll see benefits before putting in the work to update current articles with a new convention. It may be too that different needs between the two KBs may determine a different kind of naming convention for the backend KB.

Just thinking through the process and would appreciate your perspectives! 🙂

Thoughts? Articles? Recommendations? Thank you in advance! -Lauren

[Sam Goode]

Generally I'd recommend naming all articles based on the way the customer describes the issue or question they are facing. This description is likely what other will search in via self-service portal, and also how they will describe the issue when logging an incident/case.

These words that make their way into the incident/case short description will be searched first in the contextual search or agent assist, so having everything in the context of the user maximises your support agent's chances of finding relevant content early. 

This should ideally apply to any non customer facing articles as well, assuming you would still need to find and follow them based on a customer issue or question.

https://library.serviceinnovation.org/KCS/KCS_v6/KCS_v6_Practices_Guide/030/030/010/020

[Lauren Methena]

This is good advice and something I generally strive for. I think the challenge we have is that part of the team thinks on more of a marketing/employee/customer level (what will people be looking for here) and part of the team thinks on a project/program level (what do we want people to be calling this thing and referring to it as)? 

Some of this can be addressed in titles, some in meta/search terms. So, in many cases, we're educating users about something that's completely new and foreign all together. People will hopefully catch on fast enough. However, I think that's part of what we're running into. 

We're thinking on two levels - a more global level of categories (this is a job aid, this applies to case work, this applies to knowledge, etc.) and then the title/topic itself.

This is all great food for thought! Thank you!

Lauren

[Tommy SN Sahlin]

Great topic @Lauren Methena!

I'll be following with interest, but also subscribe to @Sam Goodes general point of view, to have the article title (short description) to be based on the end user's way of describing the issue, which I think should also be aligned with the common working routines for how the Service Desk should write incident Short Descriptions (based on KCS philosophy). Also don't forget the value of actively working with developing your Synonym Dictionary and Meta descriptions.

I posted a KM article here on the forum a while back that touches on some of these points as well as many others, hopefully you'll find something useful there, although it is not a SN-specific article, but more agnostic regarding KM:

https://community.servicenow.com/community?id=community_article&sys_id=a149c412db9eb4d0fb115583ca961...

cheers, hope that helps  /Tommy