Knowledge-base templates

These knowledge-base templates are drafting tools for a small support team. They are deliberately different: a customer trying to complete a task needs steps, while an agent deciding whether to grant an exception needs authority and escalation rules. Forcing both into a generic “question and answer” card makes each weaker.

Copy the structures into your editor, replace every bracketed instruction and verify the facts. A template is not a claim that a provider has a particular policy or button. If your team has not agreed the underlying rule, resolve that first. Publishing an attractive answer to an unsettled policy creates more support work, not less.

Shared header for every article

Keep a small metadata record outside the reader-facing body. At minimum: audience, named owner, source of truth, risk level, last substantive review month and review trigger. Add a second approver for financial, safety, privacy or regulated topics. A review month is useful operationally; do not imply that a page was checked on a date if nobody actually reviewed the steps.

The title and URL are reader-facing. Make them describe the task. Attach synonyms or tags only when they match language in real tickets. A category label is not enough if the page title says merely “Information”. Freshdesk documents categories, folders and articles with visibility settings; Zendesk's user segments illustrate a stronger access-control route. Whatever platform you use, test the published audience with a non-admin account.

Template 1: complete a task

Use this for setup, cancellation, account changes, downloads and routine requests where the reader can safely act.

Title: [Verb + object + important condition]

Short answer: [Who can do this, and the main limitation]

Before you start: [Required access or information]

Steps: 1. [Action and visible result] 2. [Action and visible result] 3. [Confirmation]

If you cannot complete it: [Recognisable reason, safe next step and contact route]

What happens next: [Expected state or timeframe, without a guarantee the team cannot meet]

For example, a “download an invoice” article should specify which account role can see invoices and what to do if the invoice is absent. The instruction “open Billing” is incomplete if different subscription owners see different menus. Write each step so someone can tell whether it worked. Our article-writing guide explains how to test the draft with a new reader.

Template 2: diagnose a symptom

Use this when the reader does not yet know the cause. Keep the first check low-risk and observable. Do not ask a customer to disclose a password, disable security settings or repeat a payment blindly.

Title: [Symptom in customer language]

Check first: [One safe observation that separates common causes]

If A: [Action, expected result, stop condition]

If B: [Different action, expected result, stop condition]

If neither: [Information to collect and human escalation]

For “I cannot sign in”, the first branch may ask whether the account exists under the address being used; another may distinguish an expired invitation from a forgotten password. If verification is needed, route it to the authorised account flow or support team. A troubleshooting tree is useful when several branches are unavoidable. Never hide the human route at the bottom of a path that can loop indefinitely.

Template 3: explain a policy

Use this for returns, refunds, service levels, data retention or eligibility. The reader needs boundaries more than screenshots.

Title: [Policy as a customer question]

The rule: [Plain-language answer with the main conditions]

Who and what it covers: [Audience, product, region and timeframe]

Exceptions: [Specific cases and who decides them]

How to request help: [Action and information needed]

Where the binding terms live: [Link to the authoritative policy or contract]

For a UK shop's return guidance, distinguish a statutory right, a voluntary store policy and product-specific exclusions when relevant; get legal review before publishing a legal claim. Do not turn a generic template into legal advice. If the actual policy is complex, link to the authoritative terms and explain the most common path without contradicting them.

Template 4: internal agent runbook

An internal runbook supports consistent decisions, not public self-service. It may include identity checks, system permissions, exception authority, audit requirements and handoff details. Keep it behind staff access and avoid storing secrets in the article.

Trigger: [Contact reason or alert]

Verify: [Approved identity or account checks]

Decision: [Permitted action and approval threshold]

Action: [System steps and customer-facing response]

Escalate when: [Risk, uncertainty, failure or policy exception]

Record: [Ticket fields, outcome and next owner]

Link to the public article an agent may share, but do not paste the confidential runbook into the public page. If one policy changes, update both through a shared owner or change request. The internal-versus-external guide explains this boundary.

Template 5: incident or exception notice

When a known incident causes repeated contacts, a short status answer may be more useful than a long evergreen article. State what is affected, what customers should avoid doing, the next planned update and the route for urgent cases. Do not invent a restoration time. Expire or replace the notice when the incident ends and link to a durable troubleshooting article if the underlying issue can recur.

Editorial and publishing checklist

Before publishing any of the templates, confirm the title matches a real query, the opening states scope, every action has an expected result, links work, access is correct and the reader can reach a person when the page stops. Remove placeholder brackets. Test on a phone, with keyboard navigation and with a person unfamiliar with the subject. Check the article's location in browsing and search. Assign the review trigger before launch.

When a template seems too rigid, change the template. Consistency is useful only when it reduces reading and maintenance effort. Google's people-first guidance supports complete, useful answers; it does not prescribe one article shape or a target word count.

Sources

• Freshdesk on knowledge-base authoring and visibility
• Zendesk on help-centre audience permissions
• Google Search Central on helpful content

These templates are editorial scaffolds. Product, policy and legal details must be verified for the organisation using them.