Write a useful help-centre article

A help-centre article is successful when someone can finish a task without guessing what the writer meant. That requires more than a friendly tone or a neat screenshot. The title must match the customer's question, the steps must work on the current product, and the page must explain what happens when the expected path is unavailable.

Use this method for a public how-to, policy explainer or troubleshooting page. Internal runbooks need a different level of permission and decision authority, but they benefit from the same discipline. The template collection provides reusable shapes; the method below explains how to fill one with reliable content.

Choose one task and define the boundary

Start with a ticket or search query, not a heading invented in a meeting. Ask what the person is trying to accomplish and what evidence shows this is recurring. “Delivery” is a category; “change the delivery address before dispatch” is an article-sized task. Note who can perform it, when, and which cases require a person. If different plans or product versions have materially different steps, say so explicitly or create separately maintained versions.

Write a one-sentence promise before drafting: “This page shows a signed-in customer how to change an address before an order is dispatched.” That promise becomes the test for every paragraph. A paragraph about general shipping history may be interesting but does not help complete the task. If another question arises, link to a distinct article rather than hiding a second procedure in the middle.

For a high-consequence topic such as account access or payment, identify a stop condition early. Public content can explain the process but should not instruct people to bypass identity checks, share passwords or post sensitive details in chat. The escalation route is part of the answer, not evidence that the article failed.

Draft a title and opening that orient the reader

Use a verb and an object when possible: “Download an invoice”, “Reset your password” or “Fix an invitation that has expired”. For symptoms, name the symptom in the customer's terms. Avoid clever headlines and internal acronyms. Google advises unique, clear titles that accurately describe the page; this is also what helps a visitor recognise the right result in a help-centre search.

The first two or three sentences should answer: is this my problem, can I do it myself, and what happens next? For example: “You can change a delivery address in your account until the order enters dispatch. If dispatch has begun, contact support; we cannot guarantee a carrier change.” That is more useful than a generic introduction about excellent customer experience. Do not overpromise an outcome the team cannot control.

If a task needs preparation, state it under a short “Before you start” heading. Include required access, product version, permission or document. Avoid prerequisites that only apply to a rare edge case; place those beside the step they affect. A reader should be able to begin without reading the entire article twice.

Write steps that can be performed and checked

Use numbered steps for a sequence. Name the control and the location, then describe the expected result. One step should usually contain one action; combining five clicks in a sentence is hard to follow and hard to update. If there are choices, use a short branch: “If the button is unavailable, check whether the order has entered dispatch.” Do not use “simply” to gloss over a difficult or restricted action.

Replace vague instructions with observable ones. “Go to settings and update your details” leaves too much unknown. “Open Account → Orders, choose the order, select Change address, then confirm the new address” is testable—but only if those labels are current. Check them against the real product or the authoritative policy source. Where the interface changes frequently, prefer durable descriptions and review more often.

After the steps, state what success looks like: a confirmation email, changed status or saved setting. Tell the reader when the result may take time to appear. If the operation can fail without an error message, explain how to verify it and when to contact support. A page that ends immediately after “Save” may leave the customer unsure whether anything happened.

Use media carefully and accessibly

A screenshot can show an unfamiliar control, but its text may be too small on a phone or unreadable to assistive technology. Put the instruction in the article body and use the image as a supplement. Add alternative text describing the relevant control or state, not “screenshot”. Crop out unrelated personal data and do not publish a real customer's account details. Replace outdated images when the interface changes; a screenshot of an old button can be more misleading than no screenshot.

Tables help compare a few conditions, such as dispatch stage and available action. Avoid wide tables for core instructions on mobile. For a complex diagnosis, consider a troubleshooting tree with a clear human stop. Keep captions, headings and link text descriptive so a reader can scan the page.

Test before publishing

Have a subject owner follow every step in the current product or policy. Then give the draft to someone unfamiliar with the process and ask them to complete the task without coaching. Watch where they hesitate and what they search for. Test a normal case, an ineligible case and a failed attempt. The test should reveal whether the opening correctly sets expectations and whether the escalation route works.

Check mobile, keyboard navigation, link destinations and the page's position in category browsing and search. Use a non-admin account to confirm a public customer can see the article but not internal notes. Freshdesk's authoring guidance describes a rich-text and HTML editor within a category/folder system; your review must still validate the published result rather than trusting the editing preview.

Publish with a named owner, review trigger and month. Significant product, policy or pricing changes should prompt an immediate check. Negative article feedback and repeat tickets about the same step are also review signals. Google's helpful-content guidance emphasises substantive useful information rather than pages made mainly for search queries; an article that helps someone finish the task meets both the reader's need and the site's long-term quality goal.

Sources

• Freshdesk on creating and editing knowledge-base articles
• Google Search Central SEO starter guide
• Google Search Central on helpful, reliable content

The drafting process is editorial guidance. Verify each published instruction against the current product or policy it describes.