In the last few years, there’s been a move to using the knowledge base (KB) to satisfy all your customers’ information needs. And it’s not a bad thing, necessarily, but it’s also not the right thing.
The thinking is as follows:
Our customers contact us for many reasons, most of which are solved by having the tech support people look the issue up in the KB and then helping the customer to do the needful. If we expose the KB to the customers, they can look that up and do the needful on their own. This is a win because no one likes calling support. Paying support people also costs a lot of money, even if we shift our support group to LCOL areas. Therefore, the customers win, we win, and life is all better.
This isn’t bad reasoning, but it’s simplistic and avoids some nuance I think this problem deserves.
Knowledge base content
A good KB is full of content that helps customers solve problems. It includes edge cases that rarely happen and how to solve those. It also includes articles, FAQs, troubleshooting steps, and best practices. A good KB gets updated as customers have issues and the support team solves those issues.
A support team typically writes and supports the KB. Which can be fine, except generally the support team has little formal training in writing, much less in writing technical content to be consumed by customers. Using templates, they typically do the best they can to describe the issue and how to solve it. And that’s often good enough content for that problem space.
KB content is solve-a-problem content–content needed because something has gone wrong and needs to be fixed. The database has stopped talking to several integrations and the customer requires troubleshooting steps. The customer wants to do this one thing that’s possible in the product, but only 3 people in the world hope to do that.
Generally, the KB helps people who know the product to figure out a problem or how to do something unusual. This audience is often more forgiving of the quality of the content, so long as they can figure it out enough to solve their problem. If they can’t do that, then they reach out to support.
A knowledge base is reactive content in a knowledge base content strategy.
Help system content
A good help system is full of content that helps customers use the product. It includes How do I content that explains the use cases the product was built to solve. A good help system also includes videos, procedures, definitions, and best practices. A help system is created before the product releases. We may update as we learn more about what the customer needs to do.
Well-designed help systems provide context-sensitive content, offering customers specific information related to the task they’re currently performing in the product. This important quality technical content includes step-by-step instructions, tooltips, and interactive tutorials. The primary goal of a help system is to provide immediate, on-the-spot help, minimizing disruption to their workflow.
Professional technical writers typically write the help systems. These people learn the product, analyze the tasks the audience has, and architect the content to meet the point of information need of that audience. It rarely includes solving edge cases because no one knows about the edge cases yet.
Help system content is how does this thing work content. The customer expects this content in place so they can be told how to print a file or run a report or do any of the other expected and normal tasks the product does.
A help system is proactive content in a knowledge base content strategy.
But…but…we want to reduce silos
A solution I’ve been seeing in the last few years is to dump all the content into 1 knowledge base system, like Zendesk, and let the customer figure it out. And while that does reduce the silos a customer has to know about and then search, you’re pushing the information problem onto your customers to solve.
That’s lazy. And a poor knowledge base content strategy.
How many times have you searched a KB, looking for the equivalent of how do I print this report and you got 40+ results to your search? And you had to sort through those results to find the steps to do the thing? Were you happy the vendor gave you 1 silo? Or were you frustrated and didn’t care about silos?
You were frustrated. Because it’s frustrating. Obviously, whoever designed this knowledge base content strategy wasn’t concerned about your time.
I’m not saying you can’t host the help system in Zendesk, for example. I’m saying architecting the content, so the customer can quickly find the kind of content they’re looking for, is the better solution. Be intentional about what goes where and how it appears to the customer. Design a system instead of throwing it all at your customer for them to sort out. Create a knowledge base content strategy to help the customer.
Help the customer be helped.
Leave a Reply