Do you give support answers via Knowledge Base links?

Established projects typically include several layers of documentation, collectively known as a Knowledge Base (KB):

• FAQs (Frequently Asked Questions) - Quick questions and their answers
• Documentation (Docs) - In-depth guidance and references
• Q&A Articles - More detailed question/answer pairs for more specific use cases
• Roadmap - Outlines upcoming goals, features, and milestones to show the project’s direction and priorities

For example, one of the most useful feature on Microsoft website is their knowledge base.

When a problem arises, documentation should be your first port of call as it allows you to help yourself.

Why you need a Knowledge Base

If you’re constantly answering the same customer questions about your product, you’re wasting valuable time without a Knowledge Base/FAQ's. A well-organized KB empowers customers to find answers themselves, meaning they wouldn’t have to contact you in the first place.

Sure, some customers will always reach out directly. But with a KB in place, you can drastically reduce repetitive emails and focus on solving the truly unique problems.

How to respond to support emails

The basic rule is: don't send back the answer in your email - instead send back the link. More specifically:

1. If you can answer a support email then reply to the support email with the Knowledge Base link
   • To: the client
   • Cc: the developer and your manager
2. If you can't answer the question then reply to the support email:
   • To: the client and the developer
   • Cc: your manager
   • Ask the customer if they can get diagnostics to all green ticks.
   • Ask the developer to “Please action?"

✅ Figure: Good example - Responding to a known issue when the KB is already updated

✅ Figure: Good example - Responding to a known issue when you need to update to the KB

✅ Figure: Good example - Responding when you cannot reproduce the issue

✅ Figure: Good example - Informing user of a fix

See how by just giving them the URL, these emails encourages them to use your documentation in the future. You need to make sure the support staff are aware they should send these types of emails to customers.

What to include in your Knowledge Base

Things are running well when you have support staff adding new KB for:

• Known issues
• Hot tips
• Performance tips KBs also play a very important role in getting a product released. You will never get every feature done or bug fixed - we all know it

Focus on getting a version out. It is usually more important to have a version available than having no version at all. When you are looking down the Project Plan, decide on what the must-haves are. The other features and known bugs will have to remain outstanding. All the longer-term bugs should go into the KB. We also put in the feature requests that we plan on doing.

This way our customers know of our exciting features coming in future versions of our software.

Responding to feature suggestions

✅ Figure: Good example - Responding to a feature request

✅ Figure: Good example - Responding to a feature request which is part of the roadmap

Where to host your Knowledge Base

You don't need to be Microsoft to build a KB. A Knowledge Base does not need to be complicated but it needs to be easily accessible.

❌ Don't use a simple knowledge base e.g. pdi-ssw.zendesk.com/hc/en-us.

✅ Make your knowledge easy to find by using a well-designed docs system like TinaDocs

✅ Figure: Good example - TinaCMS Docs page

Tips for maintaining a useful Knowledge Base

• Keep articles concise, accurate, and up to date
• Use searchable titles and keywords
• Link related KBs to improve discoverability
• Periodically review and retire outdated content