Most help centers fail quietly. They launch with a burst of articles, traffic is low, tickets do not drop, and a year later half the screenshots show a UI that no longer exists. The problem is rarely the software. It is that the content was organized around the product instead of around the questions customers actually ask.
This guide covers how to build a help center that customers use: how to structure it, which articles to write first, how to make search work, what every article should look like, and how to tell whether it is reducing tickets.
Step 1: Mine your ticket queue first
Before you pick a tool or write a word, export the last few months of support tickets and chat transcripts. Tag each one with the underlying question, in the customer's words. You are looking for repeats.
- Group tickets by question, not by product area. "How do I add a teammate?" and "Invite not received" may be two different articles.
- Count how often each question appears. Sort descending.
- Note the exact words customers use. These become your article titles and your search keywords.
- Mark which questions need a human (refunds, bugs, account-specific issues). Those do not belong in the help center.
If you do not have a ticket history yet, use onboarding call notes, sales demo questions, and your own list of "things we explain every week". The goal is the same: a ranked list of real questions.
Step 2: Write the top 20 articles first
In most support queues, a small set of questions accounts for a large share of volume. Your ranked list will show you where that is true for your product. Take the top 20 and write those before anything else.
Twenty is a useful target because it is small enough to finish in a couple of weeks and large enough to cover the common paths. Typical candidates for a SaaS product:
| Area | Example articles |
|---|---|
| Getting started | Create your account, Set up your workspace, Complete your first project |
| Team and access | Invite a teammate, Change someone's role, Reset your password, Set up SSO |
| Billing | Change your plan, Update payment method, Download an invoice |
| Integrations | Connect your main integration, Fix a failed sync |
| Core workflows | The three to five tasks customers do most often |
| Troubleshooting | The top known issues and their workarounds |
Resist writing feature tours. An article titled "Reports overview" helps far fewer people than "Export a report to CSV".
Step 3: Keep the structure shallow
Information architecture sounds grand, but for a help center it comes down to three rules.
- Five to eight top-level categories. More than that and the home page becomes a wall of links.
- Name categories in customer language. "Billing and plans" beats "Subscription management". Use the words from your ticket tags.
- Two clicks to any article. Home, category, article. If you need sub-categories, you probably need fewer, better articles.
Put a "Getting started" collection first, ordered as a path rather than alphabetically. New customers should be able to read it top to bottom. If you have different audiences (admins and end users, or customers and internal teams), consider a separate collection or portal for each rather than mixing them.
Step 4: Make search work
Many visitors will type before they browse, so search quality matters as much as structure. Most help center platforms provide search; your job is to make the content findable.
- Title articles as the question or task. "Invite a teammate" matches what people type. "User provisioning" does not.
- Put synonyms in the first paragraph. If customers say "seat", "user", and "member" interchangeably, use all three once.
- Review search terms that return nothing, if your platform reports them. Each one is either a missing article or a missing synonym.
- Put a search box on the home page and every article, not only in the header.
Step 5: Use one article template
Every article should look the same so readers can scan it in seconds. Here is a template that works for task-based articles, which will be most of your help center:
- Title: the task, starting with a verb.
- One-line answer: the short version for people who only need a reminder ("Go to Settings, then Members, then Invite").
- Before you start: required role, plan, or information.
- Steps: numbered, one action per step, with a screenshot or short clip for each. Use the exact button labels from the UI.
- Result: what the reader should see when it worked.
- Troubleshooting: the two or three ways it commonly fails.
- Related articles: two or three links to the next likely question.
Visuals do most of the work in a help article. A reader who can see the exact button does not need to parse a paragraph describing where it is. The screenshot work is where help centers usually stall, though. Capturing, cropping, and annotating every step by hand is slow, and it has to be redone every time the UI changes.
Steperly is built to remove that step. Support agents record the fix once, Steperly generates a draft guide with screenshots and steps, and they edit it before publishing. The same guide can go into a branded help center, be shared as a link, or be embedded where users already look for help. It can also be shared as a narrated walkthrough video for people who prefer to watch.
Step 6: Put the help center where questions happen
A help center that customers have to remember to visit will underperform. Bring it closer to the moment they get stuck:
- Link the relevant article from the product screens where people get stuck, and from error messages.
- Show suggested articles in your contact form before the ticket is submitted.
- Have agents reply with article links instead of retyping answers. If an answer does not exist yet, write it after the ticket closes.
- For complex flows, consider guiding users inside the product. Steperly's Help Mode can launch live in-app walkthroughs from the same guides you publish in the help center.
Step 7: Measure deflection simply
"Deflection" means a customer found the answer without opening a ticket. It is hard to measure perfectly, because you cannot count tickets that were never filed. A simple approach works well enough to guide decisions:
| Metric | How to measure it | What it tells you |
|---|---|---|
| Ticket volume per topic | Count tickets tagged with each article's question, before and after publishing | Whether an article is reducing the question it covers |
| Article views | Views per article from your help center or guide analytics | Which content people actually find and open |
| Self-service ratio | Help center visitors divided by tickets created, tracked over time | Whether self-service is growing relative to tickets |
| Failed searches | Search terms with no results or no click | Which articles to write next |
| Contact after viewing | Tickets submitted shortly after viewing an article, if your tools can link them | Which articles are not answering the question |
Do not chase a single number. Watch the trend for each of your top 20 topics. If an article gets views but its ticket tag does not move, the article is probably unclear or out of date. Rewrite it, ideally re-recording the steps so the visuals match the current UI. Steperly's guide analytics show engagement with published guides and portals to help you decide which articles to update first.
A launch checklist
- Ranked list of real customer questions from tickets or call notes.
- Top 20 articles written using one template, each with a visual per step.
- Five to eight categories in customer language, with a "Getting started" path first.
- Search box on every page and synonyms in article intros.
- Articles linked from the product, the contact form, and agent replies.
- A monthly review of ticket tags, article views, and failed searches.
- An owner for each category and a guide check on the release checklist.
Launch with 20 good articles rather than 100 thin ones. You can add to a help center every week; it is much harder to win back customers who decided on day one that the help center never has the answer. For a closer look at turning recorded fixes into articles, read how to turn a screen recording into a step-by-step guide.