What to document first
Prioritize the articles that will deflect the most tickets, fast.
You’ve decided to build a knowledge base. The tool is set up, the blank editor is open, the cursor is blinking, and now comes the genuinely hard part: what do you actually write first? Staring at an empty content library, most people freeze, because everything feels equally important and equally optional.
Here’s the good news. You don’t need to document your whole product before launch, and you definitely shouldn’t try. The fastest path to a knowledge base that earns its keep is to write the handful of articles that answer the questions people ask most. Once you know how to structure a knowledge base, figuring out what to document first is mostly a matter of following your own support data.
What to document first (and what to skip)
The short answer to what to document first: write for the questions that already flood your inbox, not the features you’re proudest of. Your instinct will be to start with the clever edge cases and the deep configuration guide only three customers will ever read. Resist it.
Every article should earn its place by removing real work from your team or real friction from a customer. The questions that do that best are the ones that show up over and over, because one good article can answer them thousands of times. That’s the whole game early on: maximum deflection for minimum writing.
How to find your most-asked support questions
You don’t have to guess which questions matter most. You’re already sitting on the data, and support tickets are the richest seam of all.
Start by mining your tickets and conversation history:
- Tag or search your help desk. Your help desk is a running log of everything customers couldn’t figure out on their own. Sort by tag, subject line, or macro usage to see which topics repeat.
- Ask your agents. The people answering tickets all day can rattle off the top ten questions from memory, and it takes one Slack message to collect that list.
- Read your canned responses. If your team already saved a reply as a template, that’s proof the question comes up enough to be worth an article.
Then widen the net beyond tickets:
- Check your site search logs. What people type into your search bar (and especially the searches that return nothing) tells you what they expect to find and can’t.
- Look at chat transcripts and contact-form submissions. Same signal, different channel.
The 80/20 of support questions
When you actually tally your tickets, a familiar pattern shows up. A small set of question types accounts for a huge share of your volume. This is Pareto’s 80/20 principle in action: roughly a fifth of your topics tend to drive the bulk of your incoming requests.
Password resets, billing questions, “how do I cancel,” “where’s my order,” that one setting everyone misconfigures. These aren’t glamorous, but they’re the questions drowning your queue. Document that top slice and you make a visible dent in ticket volume before you’ve written article number twenty.
The payoff is real because people genuinely want to help themselves first. Harvard Business Review found that 81% of customers try to resolve an issue on their own before reaching out to a live agent (Harvard Business Review). If your top questions are documented and easy to find, you catch that traffic. If they aren’t, those same customers give up and open a ticket anyway.
How to prioritize your first knowledge base articles
Once you’ve got a list of candidate topics, rank them on two axes: how often the question comes up (volume) and how much effort the article takes to write (effort). That gives you a simple matrix for deciding which knowledge base articles to write first.
| Ticket volume | Writing effort | Priority | Do this |
|---|---|---|---|
| High | Low | Quick win | Write it today |
| High | High | Big rock | Schedule it next |
| Low | Low | Filler | Batch these when you have time |
| Low | High | Skip for now | Revisit only if volume grows |
Start in the top-left. High-volume, low-effort articles are pure quick wins: a password-reset walkthrough takes fifteen minutes and deflects questions forever. Knock out every one of those before you touch the high-effort guides.
High-volume, high-effort topics (a full onboarding guide, say) matter just as much, but they’re projects. Schedule them deliberately rather than letting them block the easy wins.
Turn it into a launch list
Pull it all together and you’ve got a ranked backlog. The tickets told you what’s common, the effort axis told you what’s fast, and the top-left of your matrix is your launch list.
A practical target for launch is your ten most-asked questions, written clearly and made easy to find in your help center. We break that starter set down in your first ten articles, and once the core library is live you can layer on the rest of your self-service support channels.
One last reason to nail the topics before the polish: a self-service article only counts if it actually resolves the issue, and plenty never do. Picking the right questions is step one. Writing about them clearly enough to actually resolve the issue is what closes that gap.
Start with the questions your customers are already asking, and your knowledge base pays for itself long before it’s finished.
