Learn how to write knowledge base articles that actually help customers. Includes templates, formatting tips, and examples for how-to guides, FAQs, and more.
TidySupport Team
Published on April 11, 2026
A knowledge base is only as good as the articles inside it. A poorly written article wastes the customer's time, fails to solve their problem, and generates a support ticket anyway, defeating the entire purpose. A well-written article solves the problem in under two minutes and makes the customer feel capable.
This guide shows you how to write knowledge base articles that actually work, with templates you can use immediately.
A knowledge base article is a self-contained piece of content designed to answer a specific customer question or guide them through a specific task. Unlike blog posts or marketing content, a knowledge base article prioritizes clarity and utility over engagement or persuasion.
There are four common types: how-to guides (step-by-step instructions), troubleshooting articles (diagnosing and fixing problems), FAQs (short answers to common questions), and reference articles (definitions, specifications, and policy explanations).
Every knowledge base article should answer exactly one question or guide the reader through exactly one task. If you find yourself covering two distinct topics, split them into two articles.
Good article scopes:
Bad article scopes:
Start by writing the customer's question as your working title. You can refine it later, but keeping the question front and center ensures you stay focused.
Your title should use the exact words a customer would type into a search bar. Customers do not search for "Email Configuration Parameters." They search for "How to set up email forwarding."
Title formulas that work:
Avoid:
If your product uses specific terminology (like "Workspaces" instead of "Projects"), include both terms: "How to create a Workspace (project)."
The introduction should tell the reader what this article covers and confirm they are in the right place. Keep it to one or two sentences.
Example: "This article explains how to connect your Google Workspace email account to TidySupport so your team can manage support emails from a shared inbox."
Do not include background information, product history, or lengthy context. Customers reading a knowledge base article already know they have a problem. They want the solution.
Most knowledge base readers do not read articles from top to bottom. They scan for the specific piece of information they need. Structure your article to support this behavior.
For how-to articles, use numbered steps. Each step should:
Example:
Step 1. Navigate to Settings
Click your profile icon in the top-right corner, then select Settings from the dropdown menu.
Step 2. Select Email Accounts
In the left sidebar, click Email Accounts. You will see a list of all connected email addresses.
Step 3. Click Add Email Account
Click the Add Email Account button. Choose your email provider from the list (Google Workspace, Outlook, or Custom SMTP).
For troubleshooting articles, use a problem-cause-solution structure:
Symptom: Emails are not appearing in your shared inbox.
Common causes:
- Your email forwarding rule is not active.
- The connected email account's credentials have expired.
- Your email provider is blocking the connection.
Solution: Check each cause in order. [Steps follow.]
For FAQ-style articles, use a question as the heading and a concise answer below. Keep each answer to one or two paragraphs.
Write at a reading level that any customer can understand, regardless of their technical background. This is not about dumbing things down. It is about removing unnecessary complexity.
Rules for plain language in knowledge base articles:
Read your article out loud. If any sentence makes you stumble, rewrite it.
Screenshots, annotated images, and short screen recordings make instructions dramatically clearer. A customer who is unsure whether they are clicking the right button will feel confident when they see a screenshot showing the exact button highlighted.
Best practices for knowledge base visuals:
Tools like CleanShot X (Mac), ShareX (Windows), or Loom (for video) make capturing and annotating screenshots fast.
Even in a how-to article, things can go wrong. Anticipate common mistakes and add a brief troubleshooting section at the end.
Example:
Still not working?
- Make sure you are using the correct email credentials. If you recently changed your password, update it in Settings > Email Accounts.
- Check that your email provider allows third-party app access. Some providers disable this by default.
- If you see an error message, search our help center for the exact error text.
- Contact our support team if none of the above steps resolve the issue.
This section catches customers who followed the steps but hit an edge case, preventing a ticket.
Before publishing, have someone who did not write the article follow the instructions from start to finish. If they get stuck or confused, revise those sections.
After publishing, track:
In TidySupport, knowledge base analytics show you article performance alongside ticket data, making it easy to see the connection between content and deflection.
Title: How to [action] [object]
Introduction: This article explains how to [action] in [product].
Prerequisites: [List anything the reader needs before starting]
Step 1. [Action verb] [task]
[One to two sentences of explanation]
[Screenshot]
Step 2. [Action verb] [task]
[One to two sentences of explanation]
[Screenshot]
Step 3. [Action verb] [task]
[One to two sentences of explanation]
[Screenshot]
Troubleshooting:
- [Common issue 1 and fix]
- [Common issue 2 and fix]
Related articles:
- [Link to related article 1]
- [Link to related article 2]
Title: [Problem description] / What to do when [symptom]
Introduction: If you are experiencing [symptom], this article will help you diagnose and fix the issue.
Symptom: [Describe what the customer sees]
Common causes:
1. [Cause 1]
2. [Cause 2]
3. [Cause 3]
Solution for Cause 1:
[Steps to fix]
Solution for Cause 2:
[Steps to fix]
Solution for Cause 3:
[Steps to fix]
Still need help?
Contact our support team at [support link] with the following information:
- [What to include in the ticket]
Title: Frequently asked questions about [topic]
Q: [Question 1]
A: [One to two paragraph answer]
Q: [Question 2]
A: [One to two paragraph answer]
Q: [Question 3]
A: [One to two paragraph answer]
Related articles:
- [Link to detailed article on subtopic]
Most knowledge base articles should be 300 to 800 words. How-to guides with multiple steps may reach 1,000 to 1,500 words. If an article exceeds 1,500 words, consider splitting it into two separate articles. The goal is completeness without padding.
Support agents are the best authors because they understand customer language and common pain points. Product managers and developers can contribute technical accuracy, but the final article should always be reviewed by someone who talks to customers daily.
Track two metrics: the helpfulness rating (thumbs up or down on the article) and whether ticket volume for that topic decreases after publishing. If customers read the article but still open tickets, the article needs improvement.
Written articles should be your foundation because they are searchable, scannable, and easy to update. Add video as a supplement for complex processes that are hard to explain with text and screenshots alone, like multi-step workflows or drag-and-drop interactions.
Flag these articles for monthly review. Keep the article structure modular so you can update individual steps without rewriting the entire piece. Some teams add a "Last verified" date at the top so readers know how current the information is.
Most knowledge base articles should be 300 to 800 words. How-to guides with multiple steps may reach 1,000 to 1,500 words. If an article exceeds 1,500 words, consider splitting it into two separate articles. The goal is completeness without padding.
Support agents are the best authors because they understand customer language and common pain points. Product managers and developers can contribute technical accuracy, but the final article should always be reviewed by someone who talks to customers daily.
Track two metrics: the helpfulness rating (thumbs up or down on the article) and whether ticket volume for that topic decreases after publishing. If customers read the article but still open tickets, the article needs improvement.