Support load feels random and is not. A handful of questions account for most of it, they repeat indefinitely, and they are largely the same at every hosting provider.
Answering one of them properly removes that ticket permanently rather than for one client.
Find out what you are actually answering
Read the last hundred tickets and group them. Do not estimate. The result is usually not what anyone expected, and it is the only input that matters.
The recurring set is normally some version of: mail client settings, a forgotten password, "my site is not showing" after a DNS change, how to upload files, a disk quota warning, how to install an application, and how to point a domain here.
Those seven answered well remove a large share of the volume.
Write for the moment the question arises
Documentation fails when it is written as reference rather than as an answer.
A client asking about mail client settings needs your hostnames, your ports and the exact screens of the two clients they actually use. A generic explanation of IMAP does not resolve the ticket, and they will write to you anyway.
Specific beats comprehensive. One page that fully answers one question is worth more than a manual.
Put the link where the question happens
This is the part that decides whether any of it works.
Nobody searches a knowledge base they have never been shown. The link has to appear in the notification or the interface that prompted the question: the quota warning email links to the page about what fills an account; the welcome message links to the mail setup page; the suspension notice explains what to do next.
A well-written page nobody finds is a page that did not reduce anything.
Onboarding is the highest-return document
The single most effective piece is the one sent in the first week, because a client who never forms the wrong expectation never raises the ticket.
What is included and what is billed. How to reach you and what response time to expect. What to do if the site goes down. Where the control panel is and what the login looks like.
Fifteen minutes of writing, sent to every new client, and it is also the document you refer back to in every later disagreement, onboarding a new hosting client explains what belongs in it, and what support to include deals with the boundary it states.
Write the page while answering the ticket
The moment you have written a careful explanation for one client is the moment to make it a page. The work is done; it is a copy and an edit.
Then reply with the explanation and the link. The client gets their answer, and the next one gets the page.
Waiting for a quiet week to write documentation is waiting for a week that does not arrive.
Say what you will not do, too
A page explaining that website work is outside hosting support, with what you charge for it, deflects requests before they become negotiations, and it does so without any individual having to be told no.
Clients handle a stated policy far better than an inconsistent one.
Keep it true
Documentation that is wrong is worse than none, because a client follows it, fails, and now has two problems.
Anything naming a screen, a port or a version needs checking when those change: particularly after a panel update, which is precisely when interfaces move. Review the top ten pages once a year and after any major change. Update preferences and release tiers sets out when those changes arrive.
Measure it
Count the same ticket categories again after a few months. A category that has not fallen means the page is wrong, hard to find, or answering a question nobody was asking.
That is useful information instead of a failure; it tells you which of the three to fix. The reseller support workflow goes into the handling side of the tickets that remain.
Write it once, use it in three places
The same explanation is needed in the knowledge base, in the ticket reply, and in the onboarding message. Writing it three times is how documentation stops being maintained.
Write the page, then link to it from the other two. A ticket reply that says "here is the answer, and here is the page that covers it" both resolves the ticket and teaches the client where to look next time.
The habit that keeps it working is never answering a recurring question in a ticket alone. If the answer is worth writing carefully, it is worth writing once. Onboarding a new hosting client goes into the message it should be linked from.
Screenshots are the part that rots
A page illustrated with panel screenshots is accurate until the panel updates, and then it is actively misleading: a client following it looks for a button that has moved.
Two mitigations. Describe the path in words as well as showing it, so the text survives a redesign that the image does not. And keep a list of which pages contain screenshots, so a panel update produces a short review in place of a vague worry.
Panel updates arrive on a schedule you can anticipate, which makes this a planned review in place of a surprise. Update preferences and release tiers deals with knowing when.
Write for the person who is already annoyed
Documentation is read at the moment something is broken, not while browsing.
That changes the shape of a good page: the answer first, the explanation afterwards. A page that begins with three paragraphs of background loses the reader before it helps them.
Lead with what to do. Follow with why, for the people who want it. And say plainly when the answer is "contact us"; a page that pretends a problem is self-serviceable when it is not wastes the client's time and yours.
Make it findable from the panel, not just the site
Clients spend their time in the control panel, not on your website. A knowledge base linked only from your marketing pages is one most of them will never see.
Where the panel allows customisation, put the link there. Where notifications are sent, include the relevant page. The measure is whether somebody with a problem encounters the answer without deciding to go looking for it.
That is also the difference between documentation that reduces tickets and documentation that merely exists, and it is measurable: the same ticket category should fall after the link is added, not merely after the page is written.