Help centre content

What help centre content is

Help centre content is the organising layer of a support site: the sections, what they are called, what order they sit in, the wording of every article title, and the short text on the landing page that tells a customer where to go. It is the shelving and the signs. All of it is decided by what a customer is trying to do, not by how your product is built inside.

It is not the articles themselves. Writing the individual pieces is knowledge base article work, and a centre that is working needs both: a structure that makes sense and articles worth finding. It is also not the software. Whatever platform holds the centre, the categories and the titles are content decisions, and the platform will not make them for you.

When you need one

You need this when support keeps answering a question by email that is already answered in an article nobody could find. You need it when the centre is grouped by the names of your internal modules, so a customer wanting to change a payment date has to first work out which product team owns payment dates. And you need it once a centre passes roughly a hundred articles, because at that size browsing stops working and the ordering has to do real work.

You do not need this if you have fifteen or twenty articles. At that size put the effort into writing them properly, or into a decent FAQ page on the main site. Restructuring a small centre is rearranging a bookshelf that holds four books.

What gets decided

• The task list. Every distinct thing a customer might be trying to do, taken from support tickets and from the centre's own search log, written in the customer's words rather than yours.
• The sections and their names. Usually five to eight. Named for the task — getting set up, fixing a mistake, billing and payments — never for a product area or a department.
• The order. Sections ranked by how often someone arrives needing them, which is almost never the order in which the product was built.
• The article titles. Retitled to match how the question gets asked. “Can I change my delivery address after ordering” finds a reader. “Address management” does not.
• The dead ends. Articles that duplicate each other, articles describing a feature that no longer exists, and tasks with no article at all.

What you get

The structure map. One spreadsheet, one row per existing article: its current title, the section it moves to, the title it gets, and one of four actions — keep, retitle, merge or delete. Every merge names the article it merges into, so nothing is left unaccounted for.

The written section copy. The section names, a one-line description of each, and the text on the landing page, written out ready to paste in rather than described.

The naming rules. One page for whoever adds article two hundred: how to title it, which section it belongs in, and when a new section is genuinely justified. Without this a structure holds for about six months.

A worked example

An illustration. A payroll software company in Halifax has a help centre of about 140 articles grouped under the names its developers use: Ledger, Timesheet Engine, Remittance. A bookkeeper trying to correct a pay run she has already submitted has no way to guess which of those three holds the answer, so she phones support instead. So do a lot of other people, every second Thursday.

The tickets and the search log produce a list of 62 distinct tasks. Those group into six sections, the first two being getting set up and running your first pay, and the third being fixing a mistake, which is where the submitted pay run now lives under the title the bookkeeper herself used. Of the 140 articles, 96 keep their content and take new titles, 26 merge into 11, and 18 are deleted because the features they describe are gone. The support team gets the naming rules, and the fixing a mistake section is moved to the top of the landing page for the first fortnight of every month, because that is when the calls come.

How it runs

1. A half-hour call. What the centre holds now, who uses it, and which questions your support people answer most often. No charge.
2. A fixed price in writing. Agreed before anything starts, based mostly on how many articles exist.
3. Inputs. Read access to the centre, an export of the last few months of support tickets, and the internal search terms if your platform records them.
4. The task list and draft structure. Within five working days. You and one support person read it and tell me where the names are wrong, because they will hear it in the tickets before I do.
5. The map and section copy. Within ten working days of the call, with the naming rules and a walkthrough for whoever will do the moving.

Two to three weeks from first call to a structure you can implement, for a centre of a hundred or so articles.

What it costs

This is not one of the published bands on the pricing page, so it is quoted as a fixed price in CAD after the half-hour call. What moves the price is the number of articles, whether ticket data can be exported in a usable form, and whether rewriting the articles themselves is included or handled as separate work. The number is fixed in writing before anything starts.

What happens next

A structure produces a list of articles to write and rewrite, so the articles are the usual next job. Where one long task keeps needing a chain of short articles, it is better served by a single document a customer can follow front to back. And somebody has to move all of it, which is content entry work if you would rather not tie up the support team for a week. This piece of work stands on its own: you have the structure, the map to reach it and the rules to keep it, and nothing further is assumed.