KoltrixTurning support email into a knowledge base
A worked example: mine a quarter of support threads for repeat questions, write help articles in customer words, link them in replies, keep them fresh.
On this page(10 sections)
- The starting point
- Step 1: Pull a quarter of threads
- Step 2: Tag questions by topic
- Step 3: Pick the first articles
- Step 4: Write in the customer's words
- Step 5: Link articles in replies
- Step 6: Measure which articles get used
- Step 7: Keep articles owned and dated
- What the example team ended up with
- Key takeaways
Your support inbox already contains the outline of your knowledge base. Every question customers ask more than once is an article waiting to be written, phrased in exactly the words people use when they search.
This post walks through a worked example: taking one quarter of support email at a fictional small SaaS company, finding the repeat questions, writing the first articles, and building the habits that keep them useful.
The starting point
Our example company makes a scheduling tool. Three people share support. They have a docs site with setup instructions written at launch, but customers rarely find answers there and email instead. The team suspects many emails ask the same things, but nobody has checked.
The goal: a small set of articles that answer the most common questions, linked from replies, and kept accurate.
Step 1: Pull a quarter of threads
Start with the last three months of customer email. A quarter is long enough to see patterns and recent enough to reflect the current product.
Export or list the subject lines and first messages. You don't need every reply, just enough to understand the question. If your inbox has labels for topics, use them; if not, you'll create rough ones in the next step.
Step 2: Tag questions by topic
Read through the first messages quickly and give each a short topic tag. Use the customer's problem, not your internal feature name. Don't aim for perfect categories; aim for consistency.
A slice of the example team's tagging sheet:
Thread | Topic tag
"Can't connect my Outlook calendar" | calendar-connect-outlook
"Booking link shows wrong time zone" | timezone-wrong
"How do I add a teammate?" | add-teammate
"Outlook sync stopped working" | calendar-connect-outlook
"Clients see times in my zone not theirs" | timezone-wrong
"Refund for unused month?" | refund
"How do I add buffer between meetings?" | buffer-time
After an hour or two of tagging, count the tags. In our example, a handful of topics account for a large share of all email, which is typical: repeat questions cluster.
Step 3: Pick the first articles
Rank topics by how often they appear, then adjust for two other factors:
| Topic | Frequency | Can an article solve it? | Priority |
|---|---|---|---|
| timezone-wrong | High | Yes, it's a settings issue | 1 |
| calendar-connect-outlook | High | Mostly, with troubleshooting steps | 2 |
| add-teammate | Medium | Yes | 3 |
| buffer-time | Medium | Yes | 4 |
| refund | Medium | No, needs a person | Skip |
Some frequent topics shouldn't become self-serve articles. Refunds need judgment; an article can explain the policy, but customers will still email. Focus first on questions where a clear article fully answers the question.
Start with five articles, not fifty. Five good, linked articles help more than a large library nobody maintains.
Step 4: Write in the customer's words
This is where support-sourced articles beat docs written by product teams. Use the language from the emails.
The example team's original docs had a page titled "Configuring Host Locale Settings." Customers wrote "booking link shows the wrong time" and "clients see times in my time zone." The new article is titled:
"Why does my booking page show the wrong time zone?"
Article structure that works for support-driven content:
- Title as the question customers ask.
- Short answer first (one or two sentences).
- Steps to fix it, numbered, with the exact names of buttons and menus.
- Common variations: "If you use Outlook..." or "If your clients are in several time zones..."
- What to do if this didn't help: a link or address to contact support, ideally with what details to include.
Pull the steps from the best replies your team already sent. Someone has written the perfect answer to this question in an email at least once. Find it and turn it into the article.
Step 5: Link articles in replies
An article nobody sees doesn't reduce email. The main distribution channel at first is your own replies:
- When answering a question covered by an article, answer it directly in the email and include the link: "Here's how to fix it... I've also put the full steps here: [link]."
- Add links to your reply snippets so every teammate uses them.
- Link the top articles from your contact page and your auto-acknowledgment email, if you send one.
Answering in the email and linking is better than replying with only a link. Customers who wrote in want an answer, not homework. The link helps them next time and helps whoever they forward it to.
Step 6: Measure which articles get used
Keep measurement simple:
- Article views, if your docs tool reports them.
- Links in replies: how often the team links each article. Frequent linking means the article answers a real repeat question.
- Follow-up questions after linking. If customers reply "that didn't work" after reading an article, the article is incomplete.
- Topic tag counts next quarter. Repeat the tagging exercise. If a topic's share of email shrinks, the article is probably helping.
Avoid inventing precise "deflection" numbers. You can't know how many people read an article and didn't email. Watch the trend in tag counts and listen to what customers say.
Step 7: Keep articles owned and dated
Knowledge bases rot when nobody owns them. Three rules for the example team:
- Every article has an owner, usually whoever wrote it.
- Every article shows a "last reviewed" date internally, even if not public.
- Product changes trigger article review. When a release changes a screen, the release checklist includes "check help articles that mention this screen."
Once a quarter, re-run the tagging exercise. New repeat questions become new articles; topics that disappeared might mean an article can be archived.
What the example team ended up with
After one quarter, the team had a short set of articles covering the most common questions, all titled in customer language, all linked from snippets, and each with an owner. Email on those topics didn't disappear, because some customers will always prefer to ask, but replies became faster because the answer was a link plus two sentences instead of a fresh explanation each time.
Key takeaways
- Your support inbox is the best source for knowledge base topics and wording.
- Tag a quarter of first messages by customer problem, then count.
- Start with a handful of articles on frequent questions an article can fully answer.
- Title articles with the customer's question and answer it first.
- Link articles in replies, measure trends rather than precise deflection, and give every article an owner and a review date.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
