Help & Support Builder

The platform can carry a help library of your own, so users find guidance inside the application rather than being sent elsewhere.

Where to find it

Architect Panel → Help & Support:

• Manage Articles — master categories, then down to articles

Architect Panel → Automation:

• Tasks — scheduled work, covered under Automation

Four levels of structure

Master categories, categories, subcategories, and the articles themselves. Each article belongs to a category and a subcategory, carries its content, any attachments, and an order within its subcategory.

Four levels is more than most libraries need. Use as few as your content genuinely requires — depth that exists because it was available is depth users have to navigate.

Write for the person who is stuck

Not for somebody reading in order. Nearly every help article is opened by a person part way through a task who has hit a specific problem, and they will read the first two paragraphs.

Put the answer first and the background after it.

Title by the question

"How do I reopen a closed case" finds itself. "Case lifecycle management" does not, because it is not what anybody types.

Cover what people actually ask

Your support contacts are the content plan. The ten questions asked most often are the ten articles to write first, and writing them is the cheapest reduction in support volume available.

Writing a comprehensive library nobody asked for is the opposite.

Screenshots go stale

Faster than text. A screenshot of a screen that has since changed is worse than no screenshot, because it tells the reader they are in the wrong place.

Use them where they genuinely help, and note which articles contain them so they can be checked after an interface change.

Attachments for the things text cannot carry

A form, a template, a checklist. Not for content that should be in the article — an article whose substance is a document is one people have to download to read.

Order within a subcategory matters

Articles appear in the order you set. Put the common case first; alphabetical order is nobody’s idea of helpful.

Give it an owner and a review date

Help content decays silently. Nobody reports a stale article — they simply stop trusting the library and go back to asking a person, which is the outcome the library existed to prevent.

An annual review of the twenty most-read articles is usually enough.

Worked example

An organisation wrote its first twelve articles straight from its most frequent support questions, titled as those questions, with the answer in the opening lines. Support contacts on those topics fell noticeably within a month. The library is reviewed each January and after any significant interface change.

Recommendations

• Write the ten most-asked questions first.
• Title articles as questions people would type.
• Answer first, background afterwards.
• Give it an owner and an annual review.