Customer support

How to Build a Knowledge Base for Your Support Team

How to build a knowledge base for support: pick first articles from ticket data, use an article template, structure it, keep it current and link it from chat.

In this article
  1. What a knowledge base is for
  2. Start from ticket data, not from a blank page
  3. Choose the first ten articles
  4. An article template you can copy
  5. Structure: categories by task
  6. Keeping it current
  7. Linking from chat and canned replies
  8. Checking whether it works
  9. Frequently asked questions

Most knowledge bases start the same way: someone decides the company needs a help center, writes forty articles in two weeks, and six months later half of them are out of date and nobody opens them. The ones that work start smaller and start from the questions customers already send you.

This guide covers how to build a knowledge base for a support team: what to write first, a template for each article, how to organize it, how to keep it current and how to put it in front of customers inside chat.

What a knowledge base is for

A knowledge base (or help center) is a set of written answers that customers can find without contacting you. It has a second use that teams often forget: agents link to it. A good article is written once and then sent a hundred times, which is why it sits naturally next to your canned responses.

One thing to be clear about: Hodhod does not host a help center. You publish the articles wherever you prefer (your website, a docs tool, a simple page per topic), and Hodhod is where you link to them from conversations.

Start from ticket data, not from a blank page

Before writing anything, look at what customers actually ask. If your conversations carry labels, take the last month, count conversations per label and sort the list. If they don't, label a sample of 100 to 200 by hand. It takes an afternoon.

Here is an invented example of 200 conversations from one month:

Topic Conversations Share
Where is my order 52 26%
Login or password reset 38 19%
Refund status 30 15%
Change delivery address 24 12%
Invoice request 20 10%
Everything else 36 18%

The top four topics are 144 of 200 conversations, which is 72%. Your numbers will differ, and for a SaaS product the list will look nothing like this. The method is the same: a few topics usually account for most of the volume, and those are your first articles.

Choose the first ten articles

Not every frequent question deserves an article. Pick the ones that pass three checks:

  • It comes up often. Take it from the count above, not from memory.
  • The answer is stable. If the answer changes weekly, a canned reply is easier to keep correct.
  • A customer can act on it alone. "Reset your password" can be self-served. "Why was my payment rejected" often needs an agent who can look at the account.

Ten articles written well are worth more than fifty written fast. Also write down the questions where the honest answer is "contact us", and make sure the article says how.

An article template you can copy

Every article should look the same, so readers learn where to find the answer and writers don't reinvent the format.

Title: [What the customer wants to do, in their words]

Applies to: [plan, app version, country or channel, if it matters]
Last reviewed: [date]   Owner: [name]

Short answer
[One or two sentences with the answer itself.]

Steps
1. [One action per step.]
2. [Name the button or screen exactly as it appears.]
3. [What the customer should see when it worked.]

If it did not work
- [Most common reason and the fix]
- [Second most common reason]
- Still stuck? [How to reach support, and what to include in the message]

Related articles
- [Link]
- [Link]

A few habits help. Put the answer in the first two lines, because many readers stop there. Write the title the way a customer would type it into a search box ("Change my delivery address"), not the way your team names the feature. Add the "last reviewed" date and an owner to every article, since that is what makes maintenance possible later.

Structure: categories by task

Keep the top level small, five to eight categories. Name them after what the customer is trying to do, not after your departments:

  • Getting started
  • Orders and delivery
  • Payments and refunds
  • Account and login
  • Using [feature or product area]
  • Contacting us

If a category holds only one article, merge it into another. If one holds more than fifteen, split it. Make sure every article can be reached from search and from at least one category, and link related articles to each other so a reader who landed on the wrong one can move on.

Keeping it current

A knowledge base is a small product with an owner. Without one it decays.

  • Assign an owner per category, not one person for everything. The person who knows refunds owns refund articles.
  • Add a review step to releases. When a screen, price or policy changes, someone checks which articles mention it before the change goes out.
  • Turn new answers into articles. If an agent writes a long, careful reply to a question for the third time, that is an article waiting to happen.
  • Hold a monthly 30-minute review. Re-run the label count, look for new frequent topics, open the oldest "last reviewed" dates and either confirm or fix them.
  • Delete what nobody needs. An article about a discontinued feature does more harm than a gap.

Linking from chat and canned replies

An article nobody finds doesn't help, so connect it to where conversations happen. The simplest way is to put the link inside a canned reply, so the agent's answer and the article stay together:

Hi {{contact.first_name}}, you can change the delivery address until the order is packed. The steps are here: [article link]. If the order is already packed, reply here and I'll check with the warehouse.

Notice that the reply still answers the question. Sending only a link feels like being told to read the manual. The link is for the details and for the next customer who asks.

Other places to link from:

  • Widget announcements. If a topic is spiking, an announcement at the top of the chat widget can point to the article. See announcements and warnings in the widget.
  • Chatbot options. A decision-flow chatbot can answer common questions with a short message that includes the link, and hand over to an agent when it isn't enough.
  • Ticket and confirmation emails. Add a line with the link to the most relevant article.

Checking whether it works

Pick the label of an article you just published and compare conversations with that label for the month before and the month after. If the number does not drop, either the article is hard to find, or it doesn't answer the question. Ask three people outside support to find the answer using only the help center. Their path will show you where the title or structure fails.

Also watch first contact resolution: a good article lets agents close more conversations in one reply. The wider picture is in 10 customer support KPIs.

To link your help center from chat, labels and canned replies in one inbox, request a free demo. For how conversations from your widget are handled, see live chat.

Frequently asked questions

How many articles do we need before launching?

Ten is enough if they cover your most frequent topics. Launch with those, then add articles from the monthly label review. A small, accurate help center is better than a large one nobody maintains.

Should the knowledge base be public or internal?

Both are useful, and they are different documents. A public one answers customer questions. An internal one holds procedures for agents, such as how to handle a chargeback. Start with the public one for your top topics, and keep internal notes separate so that you never expose them by accident.

Does Hodhod include a knowledge base?

No. Hodhod does not host articles. You publish them on your site or a docs tool and link to them from canned replies, chat and the widget. Labels and reports in Hodhod help you decide what to write.

How do we know an article is out of date?

Give each one a "last reviewed" date and an owner, and check anything older than a set period, for instance six months. Also review the articles that mention a screen or policy whenever that thing changes.