As IT progresses more into service management, it’s good to raise a little above the operation piece of IT and get into the organization piece. Historically IT professionals balked at “time wasting” stuff like this but I’m happy to improve knowledgebase article structure.
After all, the more the end users can manage themselves, the less strain that’s on the IT department. Not to mention, the whole dynamic of IT is shifting away from the break-fix methodology to more of a service business anyway.
One resource that I’ve found interesting comes from the Consortium for Service Innovation. They released a Knowledge-Centered Support Practices Guide (KCS) that shows an interesting methodology when it comes to IT support. The crazier thing is this iterative methodology has been going strong since the 90s.
I guess IT department evolution has been a long time coming. It’s kind of funny to think about how some IT pros have been kicking and screaming about change for the last 10 years or so.
Anyway, let’s get into it.
Table of Contents
KCS Recommendation for Knowledgebase Articles
On page 20 of this free guide you can see the recommended layout of articles:
- Issue – the situation in the customer’s words
- What are they trying to do?
- What is not working?
- This can sometimes be called symptom, question, or problem.
- Environment – the platform the customer is using
- What release is the customer on?
- What products do they have?
- How are the products or platforms configured?
- What has updated recently?
- What has changed recently?
- Resolution – the answer to the customer’s problem.
- Can also be the steps required to solve the issue.
- This can sometimes be called the fix or the answer.
- Cause – the source of the issue.
- This is useful for problems or defects with products.
- This field is optional.
- Metadata – attributes or information about the article you’re publishing.
- This can be the article state, the date the article was published, the number behind the article, and other related items.
- Preferably you want to have some type of labeling or categorization setup so you can quickly filter articles.
- Don’t be afraid to use analytic packages to assist here such as Google Analytics.
What Kind of Content Can You Use KCS For?
On page 12 you’ll see KCS is capable in structure or format to cover a wide area of content types
- How to guides
- Q&A
- Interoperability issues
- Configuration issues
- Defects
- Diagnostic procedures
The goal is to create and maintain articles that are findable and usable by your customers.
What About ITIL?
Does this sound reasonable to you?
You may ask “what about ITIL?” Surely the terms and service management concepts will be different?
They briefly tackle ITIL on page 8. Most notably, ITIL is a framework, not a methodology.
Even though ITIL and KCS may use different terms, they do not necessarily conflict with each other. KCS essentially plugs into the ITIL framework.
Final Tips on Proper Knowledgebase Articles
- Have one article per issue to help avoid confusion
- Keep the language plain and geared towards your customers
- Use lists when possible, especially for step by step instructions
- Include screenshots when possible but don’t force it
- Do not directly or passive aggressively target problem customers
- Use headings, bold, and other formatting to make the articles scannable
- Be sure to check readability, flow, and spelling
That’s it. Let me know what you think of the KCS by commenting below. Is there a push for proper documentation at your workplace?
