Tool list · Updated · 6 min
9 SaaS help center examples worth copying
The best way to plan a help center is to look at how good ones are organized. These nine come from SaaS products of different sizes and types. For each, we note how it's structured and the one pattern worth taking for your own. We looked at each one on October 6, 2026; help centers change, so check the live page before copying.
Short answer
The patterns worth copying: a short “start here” path to a first success (Fathom, Raycast), categories named after customer jobs rather than menus (Kit, Buffer), a clear split between help for users and docs for developers (Cal.com, Lemon Squeezy), troubleshooting as its own section (Fathom, Kit), last updated dates (Plausible), and visible links to the changelog (Tally, Raycast).
What makes a help center worth copying?
A good help center gets a stuck customer to the answer quickly. In practice, that comes down to a few structural choices: a clear starting point for new customers, categories that match how customers think, troubleshooting that's easy to find, and signals that the content is current. The examples below each do at least one of these especially well.
We judged structure only, from each public help center's home page and navigation. We didn't assess how accurate or complete the articles are.
1. Plausible Analytics: dates and a linear start
Plausible's docs are organized into a handful of clear sections: getting started, website settings, the stats dashboard, goals and events, APIs and data access, account settings, team, and billing. New users follow a straight path: register, add a website, install the script, with separate install guides for platforms like WordPress, Shopify, and Webflow. Pages show a last updated date, and the APIs get their own top level section.
Worth copying: last updated dates on articles. They tell readers how much to trust a page and remind you which pages haven't been touched in a while.
2. Tally: six sections and a visible changelog
Tally's help center keeps the top level to six sections: get started, features, integrations, guides, plans and pricing, and resources. The home page leads with search, then quick links into each section. “What's new” and roadmap links sit in the main navigation, and the help center includes comparison pages against tools like Typeform and Google Forms.
Worth copying: a small number of top level sections, and a changelog link where customers can see it. Customers who notice a change can check what moved without writing in.
3. Linear: popular pages first
Linear's docs cover a lot of ground, from teams and issues to projects, cycles, integrations, and analytics, but the home page doesn't lead with the full list. It opens with a Popular section, including a start guide, importing, and GitHub automations, then “Linear basics” with short descriptions under each title.
Worth copying: leading with the most used pages instead of the full category tree, and a one line description under every link so readers know what they'll get before clicking.
4. Fathom Analytics: start here and real troubleshooting
Fathom's help docs open with search and a “Start here” path: create your first site, install the script, explore the dashboard. Sections cover how tos, your account, script settings, features, event conversions, integrations, and API docs, and there's a dedicated troubleshooting section with more than fifteen articles on data discrepancies and technical conflicts.
Worth copying: troubleshooting as its own section, built from the problems customers actually hit. It's often the most visited part of a help center and the hardest to find when it's scattered across feature pages.
5. Lemon Squeezy: help, guides, and API kept apart
Lemon Squeezy's docs separate general help from developer guides and the API reference. The help side is organized by what merchants deal with: getting started, products, orders, checkout, payments, tax forms, affiliates, email, licensing, and webhooks. The getting started path covers fees, supported countries, store activation, identity verification, and test mode.
Worth copying: giving high stakes topics like payments and taxes their own top level sections, and keeping developer material out of the way of customers who just want to sell.
6. Raycast: start here, then explore
The Raycast Manual splits its home page into “Start Here”, with cards for basics, account, and teams, and “Explore Raycast”, covering core features, power features, AI, and iOS. A latest releases area links to the changelog, search opens with a keyboard shortcut, and a “Get in touch” footer links support and troubleshooting.
Worth copying: separating “what you need first” from “what you can explore later”. New users aren't buried in advanced features, and power users can skip the basics.
7. Cal.com: users and developers, clearly split
Cal.com's help center is explicit about who it's for: it serves end users of hosted Cal.com and sends developers to a separate docs site for APIs and self hosting. It opens with a quick start, encourages readers to check the docs before contacting support, and publishes an llms.txt index of its articles for AI tools.
Worth copying: saying plainly who a help center is for, and publishing an llms.txt so AI assistants can find the right article. Both cut down on customers landing in the wrong place.
8. Kit: jobs as categories, with article counts
Kit's help center (formerly ConvertKit) organizes more than a dozen collections around what creators do: getting started, switching to Kit, subscribers, audience growth, send, automate, monetization, deliverability, managing your account, and troubleshooting. Each collection shows a short description and its article count, and there's a dedicated section for people switching from other tools.
Worth copying: a “switching to” section for customers migrating from a competitor. They arrive with specific questions, and answering them well makes the switch, and the sale, stick.
9. Buffer: categories for every channel
Buffer's help center leads with “What can we help you with?” and search, then fifteen or so categories with article counts: getting started, channel management, creating and scheduling posts, billing, team collaboration, analytics, the mobile app, integrations, and the API. Social network specific guides get their own category.
Worth copying: a category for each of the outside platforms your product works with. Customers think “how do I post to Instagram”, not “channel configuration”.
What do the best help centers have in common?
Across all nine, the same few choices repeat.
| Pattern | Seen at |
|---|---|
| A short path to a first success | Plausible, Fathom, Raycast, Cal.com |
| Categories named after customer jobs | Kit, Buffer, Lemon Squeezy |
| A separate place for developers | Cal.com, Lemon Squeezy, Plausible |
| Troubleshooting as its own section | Fathom, Kit |
| Visible changelog or what's new | Tally, Raycast |
| Signals that content is current | Plausible (last updated dates) |
None of these needs a big team. They're decisions about structure, and you can make them on day one. If you're starting from zero, The First 15 Articles Every B2B SaaS Help Center Needs lists the articles to write first.
What none of the structure can fix
A well organized help center still fails if the articles describe last quarter's product or skip the questions customers actually ask. Structure gets readers to the right page; only upkeep makes that page right. How to keep your help center up to date covers a routine for that, and usedocs automates the two hardest parts: proposing edits when merged pull requests change what an article describes, and drafting the articles customers asked for but nobody wrote.
FAQ
What should a SaaS help center home page include?
Search, a short “start here” path for new customers, your main categories in customer language, and a way to reach a person.
How many top level categories should a help center have?
Usually five to ten. Fewer than five gets crowded inside each; more than fifteen is hard to scan.
Should developer docs and the help center be separate?
If you have an API, usually yes, with links between them. Customers looking for billing help shouldn't have to wade through API references.
Should help articles show a last updated date?
Yes. It builds trust and helps you spot pages that haven't been reviewed in a while.
Is it fine to copy another company's help center structure?
Copying structure is fine and common; copying their articles isn't. Organize like the best examples, then write in your own words about your own product.