How to Set Up a Help Center: Structure, Articles and Launch Checklist

Don't guess what customers need. Read your last few months of support conversations and tally them by topic. Pull data from email, chat, your ticket system and, if possible, the questions your sales team hears before purchase.

Then rank topics by two measures: how often they come up and how much time each takes to answer. High-frequency, low-complexity questions are the first candidates, since they deflect the most tickets per article. Password resets, billing changes, shipping status, getting started and how a common feature works often sit near the top.

Write the list of your top 20 questions before you open any tool. That list is your launch scope. Anything that needs a human judgment call, such as a refund exception, stays out of the help center and goes to a person.

Organize by what the customer is trying to do, not by your internal teams or product modules. "Get started", "Manage your account", "Billing and invoices", "Fix a problem" and "Integrations" are task-oriented. "Team Finance" and "Platform v2" are internal and confusing.

A few structure rules keep things findable:

• Five to eight top-level categories. More than that and people can't scan them.
• Two levels deep at most. Deep nesting hides articles.
• One home per article. Link to it from other places instead of duplicating it.
• Consistent names. If one section says "Billing" and another says "Payments", customers wonder if they're different.
• A visible search box, since most people arrive with a specific question and skip browsing.

Use the same template for every article so customers know where to look:

1. Title as the question or task, written in the customer's words: "How to change your billing email".
2. A one- or two-sentence answer up top, so someone who only needs a reminder can stop reading.
3. Numbered steps, one action each, naming the exact button or menu.
4. A screenshot or short recording for anything with a complicated screen, plus alt text.
5. What to expect after, such as "You'll get a confirmation email within a few minutes".
6. Common problems and their fixes, in two or three lines.
7. Related articles, to help the reader with the next likely question.
8. How to reach a person, so nobody hits a dead end.

Write in plain language at the level of your customer. Avoid internal terms, and define any product term the first time it appears.

Choose a tool that fits your support setup. If you already run a help desk or chat product, its built-in help center is usually the simplest choice, since articles can be suggested in the conversation and linked from replies. Intercom is aimed at teams that want articles tied closely to chat and automated answers, and Zendesk fits teams that need a more structured ticketing and multi-brand support setup. For a fuller comparison, read help desk comparison, and for B2B software specifics, help desk options for B2B SaaS.

Whichever you choose, check in a demo that you can control the design and domain, restrict some articles to logged-in customers, review analytics on searches, and export your content later. Ask about pricing and limits in writing.

Do a quiet launch first. Publish the articles, then use them yourself: for a week or two, support agents answer questions by linking the relevant article, which shows you what's unclear or missing. Fix what agents flag.

Then make the help center visible:

• Link it in your product's help menu and in your website footer.
• Add it to email footers and support auto-replies.
• Suggest articles in the contact form as the customer types, if your tool allows.
• Mention it in onboarding emails.

If you have internal procedures and customer-facing answers mixed together, decide which is which. Customer-facing articles belong in the help center. Internal how-tos belong elsewhere, and the difference is explained in process documentation vs a knowledge base.

Give every article an owner and a review date, and update articles when the product changes. Add a habit: when an agent answers the same question twice, they either link an article or write one.

Each month, review a short set of numbers:

• Searches with no results. These are topics you haven't covered or words you haven't used.
• Most viewed and least helpful articles, using any helpfulness rating your tool provides.
• Tickets on topics that have an article. If people still write in, the article is hard to find or doesn't answer the question.
• Contact rate per customer over time, which should fall as coverage improves.

For teams exploring automated answers built on top of this content, the guide on internal knowledge base agentification covers the preparation, and Zendesk vs Intercom for IT consulting shows a services-firm view. Whatever you add later, a clean, current set of articles is the foundation.