Podcast with Kate Mueller: Choosing the Right Knowledge Base Software for Your Organization

In this episode, Kate reflects on her career—both as a user of and support member for knowledge base software—to share the criterion you should consider as you choose the right knowledge base for your organization, including how to get started in your research, how to get company buy-in, and which essential features you should look for in a knowledge base. In the end, Kate shares a few of her favorite knowledge bases—KnowledgeOwl and beyond—to jump-start your research.

We are proud to sponsor The Not-Boring Tech Writer podcast.

No matter your industry—tech, nonprofit, marketing—your organization likely needs a knowledge base software, a dedicated place to capture essential knowledge.

However, choosing the right knowledge base software can be challenging—and takes much more work then a quick Google search. You need to understand the core knowledge problems within your organization; compare software that, on the surface, may look a lot alike; and get buy in from key players who’d actually use the knowledge base.

More about Support Sorceress Kate Mueller

Kate Mueller is Support Sorceress and cheesemonger at KnowledgeOwl: a knowledge base software that makes one thing – awesome knowledge base software. Kate is based in mid-coast Maine. 

Kate has worked with several different knowledge bases throughout her career and, at KnowledgeOwl, works with current and prospective customers across the world to help them discover how knowledge base software can help address their needs.

“I will do my best to be as impartial as possible, despite being an employee of KnowledgeOwl,” says Kate. 

Jacob says, “Y'all do a good job of helping technical writers with your content, whether they’re new to the tech writing game, or they’ve been in it for bit. You guide them when considering what criteria they should be using to choose knowledge base software, what should I be looking for, what kind of questions should I be asking of the products. I’m really excited to tap into your wisdom.”

“I’ve been at KnowledgeOwl for just under a year and a half,” says Kate. “I was actually a KnowledgeOwl customer before I came to work here. I was the head of product previously at a small software company. We were in the market for new KnowledgeBase software and came across KnowledgeOwl (while it was still branded as HelpGizmo). 

“I was really blown away by the product and the support. I became a customer and sort of jokingly told Marybeth I would love to work with them. Then I quit my job to hike the Appalachian trail, and when I got back I had this message from Marybeth letting me know KnowledgeOwl was looking to hire a new support person.”

The rest is history!

Working at KnowledgeOwl

Kate continues, “I began really heavily on the support side of things, while the last few months have been more into product management, a lot of documentation writing, and I’ve taken over our release notes process, along with writing a few blog posts. It’s proof that once you’ve been a tech writer, you never really get away from the writing side of things.

“It’s been really enjoyable for me to wear a lot of different hats.” 

On the topic of her job title, Support Sorceress and Cheese Monger, Kate says, “I make my own cheese, and I eat a lot of cheese. We get to pick our own job titles, so Marybeth is Knowledge Goddess and Chief Executive Owl. I knew I was going to be doing a lot of support but what else do I really do? I talk a lot about cheese, so Marybeth said I could include it in my job title. I now have a lot of conversations with customers about cheese, since other people see the title and ask about cheese.” 

“It’s a nice human touch,” says Jacob. “I’ve worked with the product myself in the past, and the support is incredible. Y’all reply so promptly, you give gentle nudges and help empower me to learn the software, and if I get in a tough bind y’all are patient and guide me step-by-step. I’m a big fan of y’all’s work.”

“Support is a big part of what differentiates us,” says Kate, “and it’s my favourite part of working here. There’s a genuine enthusiasm for just trying to help people solve problems. A lot of companies treat support like this odious task that you try to pawn off on other people, and at KnowledgeOwl it’s the centerpiece of everything we do. The product is fantastic but what really sets us apart is the people behind it.”

“Customer support is a really important criterion when it comes to choosing the right knowledge base software,” says Jacob. 

What is a knowledge base and why is it important?

Kate says, “I tend to think of a knowledge base as any way that you capture information or knowledge about how to do things. Whether that’s internal processes, how people should be using your product, interacting with the services you offer, or sharing information about market research. 

“In the business world, a lot of us have suffered from silos of information. One person who’s a gatekeeper who has to do a whole bunch of things. A knowledge base is about providing information that is accessible to everybody, maybe authored by a really small group of people or a lot of different people. It’s about breaking down silos to encourage knowledge sharing. 

“On the customer side of things it’s about sharing product or process documentation and making your customer’s lives easier as they’re trying to engage with you or use your product or service. Very often anything you write as a tech writer could fill up a knowledge base somewhere, and help make it more accessible to folks since you have an area that becomes a single source of truth. 

“Instead of it being a person, it’s a piece of software that people get in the habit of checking before they ping eight different people in Slack or send an email to twenty different people, and have to wait three days before they can get an answer.”

Jacob says, “I love that definition, and it sounds like the uses for a knowledge base go far beyond technology companies. A lot of times we immediately associate a knowledge base with developer documentation or end user documentation, but it sounds like any organization that wants to capture and organize knowledge can benefit from it.”

Kate says, “At KnowledgeOwl, we definitely do serve technical companies, and a lot of software based companies, but we also have government agencies, private companies in the insurance or mortgage spaces, medical supplies, and some retail providers use us. We work with companies across all different spaces and many different countries, so their needs are very varied. 

"The bottom line is they’re trying to capture a bunch of information and share it in some way.”

How a knowledge base can grow organically

Jacob says, “My organization Strong Towns (a non-profit media organization that advocates for building more financially resilient places) has used KnowledgeOwl, and you get a lot of questions about municipal finance, zoning, building standards. 

“That can be a complex subject, but we find we get a lot of the same questions through email, and it’s my job as community builder to respond to all of those emails. I’m sending out the same response to a couple of dozen folk, so I wanted to document this somewhere that everyone could benefit. They can immediately get the insights they need as opposed to conversing with Jacob Moses – as delightful as I am. 

“Strong Towns is another great example of not being a tech company, but needing a place to document knowledge for our readers where they can easily search.”

Kate says, “That’s actually one of the ways people start to recognize and improve a knowledge base in a shared network place, like Google Drive, or they start to answer the same questions over and over again, particularly if you’ve been doing support or managing community engagement. You feel like there are five emails to send over and over, so the first step is to save those emails somewhere. You create a document somewhere that everyone can access. 

“Now we have products like KnowledgeOwl and a variety of other solutions built around those requirements, but really you can make a knowledge base without having a special piece of software. It’s just a repository of information.”

Starting off your knowledge base research

Jacob says, “If you’re just starting off with that process and not sure what to document, a great place to start is documenting the frequently asked questions you get through customer support. We have a great podcast with Bri Hillmer about creating Just In Time documentation. It’s based on the philosophy of not documenting things we don’t need, but working with customer support to see what frequently asked questions are coming through. Then building that relationship to make sure it’s documented in the knowledge base.” 

1. Identifying your core problem

Kate says, “To begin your research for knowledge base software, begin with how you’d approach any other kind of software. Identify what kind of problem you’re trying to solve with it before you ever look at a tool. For example, are you trying to increase internal knowledge sharing so departments are not tied to one particular gatekeeper of information? Or, are you trying to onboard new employees? Are you trying to provide support documentation to your customers? 

“Why are you trying to solve that problem? Is it because one person in another department is holding this information and everyone’s really tired of dealing with them? Has your onboarding process gone really awkwardly? Have you found you’ve been answering a lot of the same questions repeatedly in support?

2. Your new software can’t do everything 

“Sometimes someone in management decides that you need knowledge base software, but more often than not there’s an underlying pain that’s causing that need. It helps up front to clearly define that problem. When people are looking at software they often get a “one ring to rule them all” mentality, and they start looking for something that solves literally every problem they’ve ever had. 

“That’s why it helps to define your particular problem up front, so you can look for a tool that solves that problem elegantly. You won’t expect the knowledge base to solve your community forum problems, to solve your development process, and a variety of other things that it could never possibly solve.

3. Decide what knowledge you want to capture

“In my experience, building knowledge bases works best when you have an idea of what knowledge you’re trying to capture and why you want to capture it. Very often those needs evolve over time but you’re more likely to find the right tool if you know what you need it to do.”

Jacob says, “I remember trying to find the right knowledge base software for Strong Towns, and it was really intimidating. I had worked one tech writing gig before Strong Towns and we already had knowledge base software, so I started using that. It was intimidating to pick one for my entire organization. I did not do what you recommended and identify our problem. I just made a list of features I liked about past software, and tried to find the finalists.”

Cutting through the marketing

Kate says, “Generally speaking, marketing departments at knowledge base companies try to hit on the big problems that customers might be looking to solve. However, every piece of software implements a solution in a different way. Even if something checks all your boxes, it doesn’t really mean it would feel good for you to use it. 

“Usually, one of the things I encourage folks to do is ask, who do you have that will use the content from an editing and writing perspective? What are their technical skills like, does the company or product give you an option for a free trial? Then you can get a feel for how intuitive it is, how hard or easy it is to use the features you most need. If you just go based on feature lists, most of us do a great job of making it look like we could give you everything you could possibly want. 

“Also, if you’re evaluating knowledge base software, it’s worth looking at their documentation. You might not need a really responsive support team, but how well laid out is their documentation? How much can you teach yourself about the product through the docs, or the product itself? If you did have to ask questions during a trial or demo period, how quickly and thoroughly were those questions answered? If you sent them three paragraphs and they sent you a hyperlink that doesn’t really answer the question, maybe it’s not the right tool.”

Choose a tool that you like

“It’s the same as writing a document. You might write it a different way, certain people will find your instructions easier to follow, and certain people will prefer mine. It doesn’t mean that yours is better than mine, it just means for your personality or your goal one of those resonated better. 

“There is pressure when you’re picking a tool for other people that it needs to be right, but you need to enjoy using it. If you are having other people use it, pull them in and show them your top three choices and get them to try them out. Ask them which one they liked best and why. Some of the ways it might not be the best fit might be things that the vendor’s support team could help with, or it could be part of how the software is designed.”

Jacob says, “Someone could feel intimidated taking this process on by themselves, so it’s better to get other people involved. If you want to work with customer support, figure out what questions they’re getting. You want to make it an equally enjoyable experience for them.”

Consider how your software integrates

Kate says, “When it comes to features, it’s also worth looking at whether you could leverage Single Sign On (SSO) in your organization. That’s a lot easier than creating new user accounts for everybody. Think about other ways you need to integrate your knowledge base into other systems or workflows. 

“If you’re using it for support teams, and they’re using a particular help ticketing software, is there some way that the knowledge base can be integrated? It may seem like a no-brainer once you’ve been through that process, but as a newcomer you might overly focus on whether the tool does what it needs to do. 

“If it’s challenging for you as the primary author, don’t pick it. If it seems fantastic, but it won’t integrate with your other tools, don’t pick it. It’s just going to make your life harder later down the line, and you’ll have to redo the process to find a different tool in a year. 

“It’s stressful enough the first time and really no fun the second time.” 

Choosing a solution that can adapt over time

Jacob asks, “Often these knowledge bases will evolve, and new problems will arise. Can people pick a solution for its adaptability?”

Kate says, “As a technical writer trying to solve a series of problems, you need to make sure you solve those problems. In my experience, knowledge base implementations do evolve. For example, an internal knowledge base may also become an external knowledge base for customer support. 

“In part it’s because if you pick a tool that solves the first problem really well, people naturally move on to the next pain point it could solve. Sure it’s helpful to pick something that’s flexible, but going too far down that road would be totally overwhelming. You end up eliminating a good product because it doesn’t do something you hypothetically might want it to do in five years. 

“What I try to encourage folks to do is think about is it flexible in the ways you need it to be flexible. Right now, everyone has access to everything. But if this really takes off in the organization might you need to segregate certain chunks of information by department, or internally versus externally. Does the tool have the ability to do this? You don’t need to test this, but knowing that you can restrict information or editing rights is enough. 

“Have the conversations early on. Ask whoever tasked you with this, do you have a feel for where this project might end up? Often, folks don’t think of SSO, but the development team frequently comes in and asks for SSO integration later down the line. People have no idea.

“You do the best you can with the information you have. No one’s going to knock you for picking a tool that works great for three years. It’s important to create a culture where that documentation matters. 

"Content creation and usage is much harder than picking the tool itself. 

“I’ve worked on knowledge bases that were basically gigantic Google Docs, that solved the immediate problem and was free. It allowed me to make the case that we needed something more than this, and ask for money to solve the problem in a more elegant way. You need to get the internal momentum and buy-in to get the tool of your dreams.”

Measuring the success of your documentation

Jacob asks, “Is measuring the success of documentation a feature of the software, or is it more of an internal conversation?”

Kate says, “There is a push to quantify usage or usefulness. I don’t know if we can nail this as a feature. Different organizations define it differently. It’s largely analytics based or feedback loop based. If you’ve got videos, are people watching them all the way through or tapping out? If people are reading your documentation, are they spending more than 30 seconds on the page? What are people searching for? You might track some behavior and try to do some analysis of that behavior. 

“If you provide a feedback mechanism for people to rate or comment on your content, it’s flawed because it requires users to take an action. This means the feedback can skew negative. I wish I had the perfect solution to this problem, but this is the way that most companies try to solve this problem. 

“You might say to yourself, we’re trying to reduce the number of support tickets by X%. We think there are a lot of support tickets that could be resolved through self-service. We’ve tracked all our ticket submissions and closures before and after the implementation, which tells us if we’ve actually solved our problem. 

“If it’s a question of internal bureaucracy, it can be useful to measure how long it takes someone in Department A to get an answer from Department B on a particular question or process. You can say that this is the problem, here are some metrics to track before we implement this tool, and then revisit the metric a year after the solution has been implemented.”

“We have a knowledge base for KnowledgeOwl, and at various times implemented changes to our documentation to try to impact the support workload. Nine months ago, there was a conscious decision to document some repeated customizations, in order to scale support better. We don’t have a mountain of those, but a small number. 

“Like Bri’s concept of JIT documentation, once we get so many requests on the same thing I say we need to document this. Then we can send people a link to the document, and start to train them to use the knowledge base. Then we can focus on helping people who run into trouble or want something different. It has changed the tone of the support tickets that we get. A certain number of support tickets have dropped off. 

“It’s not a hard metric, but a more anecdotal evidence that I can share with customers.”

Some software recommendations

“Obviously I would recommend KnowledgeOwl since I work here,” continues Kate. “We’re not super expensive, and have a reasonable pricing plan. We also do 14 day free trials which we are willing to extend, so it’s a good way to try out the software. 

“Other good products include ReadMe for API documentation, which integrates directly with Swagger. You can automatically push stuff in there. They have interesting functionality around dynamic code snippets. Users interacting with the API docs will see their own API key. It’s got some interesting AI built in for API calls that developer has been using, and will recommend docs and solutions that seem relevant to them. 

“Also, Bloomfire is interesting because they’re very focused on a collaborative social media structure. That’s different from a lot of knowledge bases. They really focus on seeing content in the context you’re using it, so they have good integrations. If you use a lot of different apps in your organization, this could work well for you. 

“I highlight Guru for their concept of “verified information”. It’s auto-generated to capture all the things they possibly can, but part of the review process includes folks who are called “verifiers”. There’s a checkbox that you can use to verify content. 

“We don’t overlap as much in these spaces which use collaborative or AI-based content, which is typically a higher price-point. If you’re trying to generate content quickly, you can try some of these tools.”

Final remarks

When it comes to choosing the right knowledge base software, there’s a lot of information to digest. 

We’ll distill it down to these brief bullet points: 

• Define the main problem that you want to solve with your knowledge base software
• Decide the parameters of the knowledge that you want to capture
• Bring together a small team of people and show them your top three software choices
• Choose a product with a responsive support team, or at least comprehensive documentation
• Choose a tool that you like using, and suits the technical skills of your content creators
• Consider how your software integrates with other applications (eg SSO or help ticketing software)
• Pick a metric (like volume of support tickets) to measure before and after your implementation

You can also listen to the original podcast, and the rest of the podcasts on The Not-Boring Tech Writer. 

Here is Kate’s blog on the Appalachian Trail. 

If you're interested in a knowledge base solution, you can take KnowledgeOwl for a free spin.