The Ten Articles Every SaaS Product Needs
A reusable article inventory for SaaS help centres, from account setup through billing to troubleshooting, with the question each one is meant to intercept.
Help centres for wildly different products converge on the same skeleton, and it is not because the people writing them copied each other. It is because the questions a customer asks in their first month are determined more by the shape of a subscription business than by what the software does. Access, permissions, limits, money, failure, escape. Every SaaS has those, so every SaaS help centre needs the same load-bearing pages underneath whatever is specific to it.
Get the skeleton right and the product-specific articles have somewhere to attach.
The ten
| # | Article | The question it intercepts |
|---|---|---|
| 1 | Getting your first result | "What am I meant to do now?" |
| 2 | Connecting the external thing | "It wants an API key and I do not have one" |
| 3 | Inviting people and what each role can see | "Can my contractor access billing?" |
| 4 | Plans, limits, and what happens at the cap | "What if I go over?" |
| 5 | Changing, pausing or cancelling a plan | "How hard is it to leave?" |
| 6 | Getting your data out | "Is my data trapped in here?" |
| 7 | The most common error, titled verbatim | pasted straight into a search box |
| 8 | Why the thing you just did has not appeared yet | "Is it broken or is it slow?" |
| 9 | Security, access and where data lives | the question procurement asks |
| 10 | What this product is not for | the bad-fit signup you would rather avoid |
Four of those are not about your features at all. Five, six, nine and ten are about the relationship - what happens with your money, your data and your exit - and they get written last or never, despite being the ones a cautious buyer reads first.
The three that punch above their weight
Number seven, titled with the literal error text. Users do not search for concepts. They copy the red string in front of them and paste it. An article whose title is exactly that string will beat any general troubleshooting page you write, and it takes ten minutes because you already know what the error means. Do this for your top three errors and watch what happens to the corresponding tickets.
Number eight, on latency. Every product has something asynchronous - an import, an analysis, a sync, a build. Users cannot distinguish "in progress" from "silently failed", and the ambiguity converts directly into support contacts. One page saying "this normally takes two to five minutes; here is how to tell it is still running; here is what to do if it has been longer" removes an entire category of message.
Number ten, on what you do not do. Almost nobody writes it. It turns away signups that would have cost you a trial slot, a support conversation and a churn event, and it earns disproportionate trust from the people it does not turn away. It is the highest-leverage page in the list and the most uncomfortable to publish, which is presumably why the two facts coexist.
What this list gets wrong
It is calibrated for self-serve SaaS with a technical setup step, and it will mislead you if that is not what you sell.
If your product is sold through demos and onboarded by a human, articles one and two are largely redundant - a person walked them through it. Your abandonment risk sits in month two, around the feature nobody demonstrated, and your equivalent list would start at what is here numbered three. If you sell to enterprise, article nine stops being a page and becomes a trust centre with subprocessors and certifications, which is a different project.
The list also says nothing about API reference documentation. That is deliberate. Reference docs should be generated from your schema and kept beside your API, not hand-written into a help centre where they will drift.
And ten articles will not make your help centre feel complete. It will make it useful, which is a different and more achievable goal.
How to use it
Do not write them in order. Write number seven first, because it is the cheapest and you can measure the effect within a fortnight.
Then work backwards from whichever question you answered most often by hand last month.
About the Author
Simon Moxon has been building SaaS companies since 2009. He's scaled teams to 20+ people, hit £2m ARR, and learned most of the lessons the hard way. Now he's building SupportPages.io - help docs that write themselves when you ship code. He writes about what's changed in SaaS and what hasn't.