Why people stop reading your help centre
A help centre rarely fails because the articles are badly written. It fails because it was built to describe the product rather than to answer the question the customer arrived with. Those are different jobs, and only one of them ends with someone getting on with their work.
The help centre is not the problem
When support volume rises, the instinct is to write more articles. More articles produce a longer list. A longer list produces a search box. A search box produces results that all look plausible, so the customer picks the first one, finds it does not match, and opens a ticket anyway.
The article was there. It was findable. It still did not work. Adding a fortieth article to a collection of thirty nine that already fail in the same way does not change the outcome.
What people are actually doing
Nobody reads a help centre for pleasure. People arrive mid task, slightly annoyed, with a specific sentence in their head. That sentence is almost never the name of your feature. It is something closer to “it will not let me change the date” or “where did my invoice go”.
Articles are usually titled after the feature instead. “Managing bookings.” “Billing overview.” The gap between what the customer typed and what you titled the page is where the ticket comes from.
Three things that make an article unreadable
It starts with context nobody asked for. Two paragraphs explaining why the feature exists, before the first instruction. The reader skims past it, misses step one, and gets lost at step three.
It covers every case at once. One article that handles the admin path, the member path, the legacy account and the mobile app. Every reader has to work out which quarter of the page applies to them before they can start.
It describes the interface rather than the outcome. “Navigate to Settings, then select the relevant tab.” Which tab. The customer does not know, because if they knew, they would not be reading.
What to do instead
Title articles with the sentence the customer would say out loud. “Change the date on a booking” beats “Managing bookings”, and it matches what they type into the search box.
Put the answer first. If there are six steps, the six steps belong at the top of the page. Background, caveats and related settings go underneath, where the people who want them will still find them.
Split by path, not by feature. An administrator and a member doing the same thing are doing two different tasks. Two short articles beat one long one that both of them have to filter.
Write down what happens when it goes wrong. Most tickets are not “how do I”, they are “I tried, and something unexpected happened”. If you know the three ways a step fails, say so in the article. That is the paragraph that closes the ticket before it is opened.
Where to start
You do not need to rewrite the whole thing. Take the ten questions that generated the most tickets this month, and find the article that should have answered each one. Read it as though you are the person who wrote the ticket. In most cases the fix is a better title and a reordered first screen, not new content.
That is the work a Knowledge Audit does, and it is the reason the output is a short list of specific changes rather than a strategy document. The value is in knowing which ten to fix.
