Support load is usually a documentation problem wearing a costume. On a project of mine, one page cut the recurring questions dramatically, and it was not the page I expected.
Nobody reads a manual, everybody reads an answer
My first attempt was a structured reference: every setting, every option, alphabetical. Traffic was fine and support tickets did not move.
The page that worked was written as questions in the user's own words, in the order they actually get asked. Not "Configuration options" but "Why is my result different from the example?"
Write the top ten questions first
I pulled every repeated support message for a month and grouped them. Ten questions covered roughly four out of five tickets:
- Why does this not work the way the demo does?
- What do the defaults assume?
- How do I undo this?
- Where does my data go?
- Why is it slow sometimes?
- Can I use the output commercially?
- What happens if I close the tab?
- How do I get a consistent result twice?
- What is the cheapest way to do this repeatedly?
- Who do I contact when it breaks?
Each answer got a short paragraph and a link to the relevant screen. No screenshots of every button — just the ones people could not find.
Put the answers where the failure happens
A documentation page only helps people who go looking. The bigger win was linking the specific answer from the error state itself, so the person who just hit the problem lands on the paragraph that explains it.
Keep it honest about limits
Stating plainly what the tool does not do reduced refund requests more than any feature I added. That is a strange thing to write and a true one.
If you maintain anything with users, treat your hotel lobby AI guide as a product surface, not a chore. It is read far more than your changelog.
Written after a single FAQ page outperformed three months of onboarding work.
Top comments (0)