How Many Article Templates Should We Have?

We always caution KCS design efforts to not “over engineer” the process or the content standard.  This is particularly true when it comes to article templates. People often ask, “how many templates should we have?” The answer is ONE… keep it simple! Because many of the KM tools offer us the capability to create different types of templates for different types of issues doesn’t mean we should. We often see organizations creating different templates for different types of issues: how to, informational, diagnostic, break/fix. In my experience, multiple templates for different types of issues create more confusion than value. 

We have not found an environment yet where the basic template outlined in the KCS v6 Practices Guide doesn’t work.  This is true across technical support, customer support, professional services, HR, legal….  Some organizations change the names of the fields to fit their environment. Some organizations add an optional, “additional information field” to the basic template. Some organizations create a section in the article that is only visible to a certain audience (like internal notes). But the basic structure works for all types of issues: how to, technical, diagnostic, procedural or policy and in all types of organizations. 

There are numerous advantages to a single template for all content. One is consistency and familiarity of the structure for the audience being served.  Another is that search engines do better indexing content with a consistent structure.  And perhaps most importantly, if after a few searches it appears there is not an article that addresses the issue we are working on, we should capture our search words and phrases as a Work in Progress (WIP) article in the workflow (searching is creating).  We won’t truly know the type of issue we are working on until we resolve the issue, and if we have multiple templates for different types of issues, which one do we use to create the WIP?

 As we suggest repeatedly in the KCS v6 Practices Guide and the KCS v6 Adoption Guide: keep it simple, start with a single, standard template for all types of content, and evolve it based on experience. Designing an elaborate content standard with multiple article templates in the absence of experience is like going on a buying spree without knowing what size clothes we wear. It’s fun to buy something shiny and new, but it defeats the purpose when we end up with a bunch of clothes that don’t fit!  

6 thoughts on “How Many Article Templates Should We Have?

  1. As Einstein was probably misquoted, “Keep things as simple as possible…but no simpler.” Most of our clients use two or three templates, and I’d like to explain why.

    KCS is built on requests and responses. In our experience, requests and responses fall into one of three general buckets: problem / solution, how to, and just general questions. The single template described in the Practices Guide is designed for problem / solution (aka “Break Fix”), but not the others. If I want to know how to connect a multifunction device as both a printer and a scanner, or if I want to know how many hours of vacation an employee can “borrow” in advance of having earned it, the structure is awkward at best. In those cases, I don’t have symptoms or a problem, I have an objective or a question. I don’t need a resolution, I need a procedure or an answer. And there is no cause: it’s just ’cause I want to know! Our clients and we have been trying for the last many years to come up with a single set of template headings that will work for these three scenarios, in vain. (I trust we can all agree that “Symptoms / Objective / Question” is a lousy header.)

    The nature of the request tends to come very early in the interaction. It’s the essence of the customer context. So picking a template relatively early in the process is not a problem.

    So, the vast majority of our clients either have three (Solution, How To, Q&A) or two (Solution, Q&A) templates. A how to is a specific form of a question and answer, so you can combine those two without much awkwardness with the headers.

    Lastly, a note on templates in modern tools, as the word can mean two very different things. In some, the templates are simply formatting–headers that are part of a larger “body” block of text that can be edited like any other text. But in many others templates are separate blocks of text…often separate database columns. In these systems, if you don’t have a Cause, you don’t have to write anything down there…BUT you’ll still have a Cause header. If your question is “Does the WhizzCo 500 support multifunction printers?” then a blank Cause looks kind of silly. Add in JIRA numbers, and it’s looking even stranger.

    1. David, thank you for providing some examples of why people might think they need multiple templates. I realize that many KCS implementations have multiple templates. But, are they really necessary? Do they really add value?

      It would be interesting to poll the Consortium members on this topic. How many members have more than one template? Do the templates just define the field labels, or is the structure different? Do they find it valuable? How often do people use the wrong template when capturing/creating articles? What do they do when the wrong template is used?

      A few points of clarification on what I think about when talking about templates: in my mind the three key elements of a template are the structure (or chunks of content), labels (or headers) for the chunks, and metadata. I should have made the distinction between structure (how we chunk the content) and the labels we put on the chunks in the structure. Most of your comments seem to be about the labels and vocabulary rather than about the structure?

      I agree the vocabulary we use for the labels can be problematic when dealing with different domains of knowledge (technical, professional services, HR, legal….). The labels used in the Practices Guide are meant to provide examples of commonly used labels – symptom/objective/question. To use them all would be silly. Organizations should decide on labels for the chunks or fields in the structure that make sense to the audience being served. The most generic, and universally applicable, labels I have come across are title, issue, environment, and resolution. Requestors have issues and they are looking for resolutions to those issues. I think these labels can be used for all types of requests: simple or complex procedures, how to, simple questions, troubleshooting (break fix), configuration, installation, policy and compliance and across all domains: financial, legal, HR, distribution, customer service, tech support, etc.

      I think the more important topic here is the structure of the article. I propose the basic, minimal structure (or chunks) for an article are: title, issue, environment, resolution with optional fields for cause and internal notes. It would be great if our modern tools could have the intelligence to display the optional chunks only if they have content, eliminating the issue of empty fields when articles are being viewed. This basic structure (title, issue, environment, resolution) can serve all types of knowledge domains.

      If we are creating templates to enable different labels on the chunks of content in the article in order to better relate to a specific audience or domain of knowledge and the structure is consistent across the templates, I think that is fine. But if the templates do not contain the basic structure (title, issue, environment, resolution) that adds a level of complexity for the search engine and our ability to tune it to maximize the relevance of the search results.

      While our search engines have improved over the past few years, my understanding is they still do better with structured content. A consistent structure enables us to tune the search engine. For example, having higher weighting on environment statements than the issue description can improve relevance of search results (a person with an HR issue in a given country wants to see the resolution that is relevant to them based on their location (country or location is an environment statement). Or when we have an issue and we don’t know the resolution, having the search engine only use the title, issue and environment fields (excluding the resolution chunk and the optional chunks) can improve the relevance of search results. Responders may want to do an advanced search to include the resolution field if they are looking for an article they know exists in the KB because they often remember more about the resolution than how the customer described the issue.

      More to come on the importance of environment statements and findability!

      1. To close the loop in public, I think we agree that there’s a common deep structure, but different sections may be called different things in different contexts, and different sections may or may not be relevant given the context.

        My first response was based on a misunderstanding of what you meant by Template.

  2. Excellent blog and discussion! I am currently researching out-of-the-box ServiceNow knowledge article templates for our organization, which does include a KCS Article template. Our current instance was pre-KCS Verified, so we customized our knowledge article template to have an Issue, Environment, Cause, Resolution fields, metadata, and Keywords.

    I look forward to hearing more about Environment statements because it seems to be a nebulous field that we are not leveraging due to it being a text-only field. We also put more weighting on the Issue and Keywords to ensure findability / relevance in search results.

  3. Thank you, Dave! This nails it for our situation. And as for “environment” in the KCS, I don’t see where that helps anything? What is an “environment”?

    And the “cause”… well, you’ve said it better than I!

    1. The Environment section, which many of our clients call the Applies To section, tells you the products, modules, configurations, and other environmental conditions that specify exactly in what situation this article applies. A heuristic someone (Greg?) taught me a very long time ago is if you apply the resolution, and a fact goes away, it’s probably a symptom; everything else is an environment.

      Pull downs / categories / taxonomy nodes / etc. can also capture Environment information, but they can’t do it alone for two reasons. First, most search engines only look at the text in the article. Second, it’s impossible to anticipate in advance the complete set of environmental conditions that might describe what an article applies to–for example, a client that makes large outdoor electronic installations included “Near the ocean” as an environment statement, because salt air caused a specific problem. No taxonomist, no matter how astute, would have included that. Also, the text often gets to a deeper level than would be desirable or practical for a taxonomy–for example, a specific version or build number.

Leave a Reply

Your email address will not be published. Required fields are marked *