Independent knowledge base software guide Evidence-led Updated 2026
Knowledge base article templates: 6 formats to copy
Knowledge base article templates give writers a reusable structure for answering a question, explaining a concept, or guiding someone through a task. Choose from the six copyable formats below, then use the completed how-to and troubleshooting examples to see how the fields become a finished article.
These are original, platform-neutral content templates—not website themes or verified instructions for a particular product. Start with the reader’s need, keep the sections that serve it, and fill them with checked information. A completed template still needs a technical review.
Choose the template that matches the reader’s need
| The reader needs to… | Choose | Important distinction |
|---|---|---|
| Complete a defined task | How-to | Explain the route to an observable result. |
| Investigate something that is not working | Troubleshooting | Choose actions according to diagnostic findings. |
| Get one direct answer | Short answer or FAQ entry | Answer first; add only necessary conditions. |
| Look up settings or specifications | Reference | Organize facts for lookup, not as artificial steps. |
| Understand a concept or behavior | Explanation | Explain relationships and limits rather than repeat a procedure. |
| Carry out a controlled internal handoff | Internal procedure | Identify authorized roles, stop conditions, and completion records. |
Reference and explanation serve different purposes. Diátaxis distinguishes tutorials, how-to guides, reference, and explanation; its tutorial category focuses on learning rather than simply completing an immediate task. The six formats here are practical editorial options, not a claim that every support article maps to a separate Diátaxis category.
How to use the fill-in fields
Copy the relevant template and replace its bracketed fields with verified information. Unmarked fields are the core of that format; sections labeled Conditional belong only when they apply. Remove unused sections rather than leaving empty headings. Add or remove steps to fit the real task—the sample number of steps is not a limit.
The bold labels identify fields in the reusable resource. In the finished article, put the title in its title field and turn substantial section labels into real headings. Keep applicability and prerequisites visible to readers; store ownership, review evidence, and confidential notes in the appropriate editorial system.
A template determines structure. A style guide determines wording and presentation. A completed example contains actual answers. None of these, by itself, defines who may access the published content.
1. How-to article template
Use this format when the reader knows the outcome they want and needs instructions. Make prerequisites explicit and give the reader a way to recognize success. Google’s procedure guidance supports numbered sequences, clear context, optional-step labels, and useful descriptions of results.
Copyable how-to template
Title: [Action and object that identify the task]
Goal: Use this procedure to [achieve a specific outcome].
Applies to: [Audience, product or process, and relevant version or environment.]
Before you begin: [Required permission, input, tool, or starting state. State “No special prerequisites” only when verified.]
Conditional — warning: [Consequence of the affected action and what the reader must check before proceeding.]
Steps:
- In [starting location], [perform the first action using the actual control or instruction].
- [Perform the next action]. [Include a necessary intermediate result or a clearly labeled optional branch.]
- [Finish or save the change]. Confirm [observable completion signal].
Check the result: [Describe the state or behavior that demonstrates completion, not merely a successful button click.]
Conditional — if the result differs: [Safe next check, relevant troubleshooting article, or verified support route.]
Keep a coherent task together, including small necessary branches. Split a branch into another article when it becomes a separate task with different prerequisites. Do not require screenshots or a troubleshooting section when they add nothing to the procedure.
2. Troubleshooting article template
Use this format when the reader recognizes a symptom but does not yet know the right remedy. Organize it around checks and conditional actions—not an undifferentiated list of fixes to try.
Copyable troubleshooting template
Title: [Observable symptom or exact error] when [relevant context]
What you see: [Describe the behavior, when it occurs, and the expected behavior. Include exact error text if relevant.]
Applies to: [Affected environment, versions, audience, and relevant permissions.]
Before checking: [Safe starting conditions and any action the reader must avoid.]
Choose the matching path: Perform the relevant check, then follow the action for its result. Do not apply unrelated remedies.
| Check | Result | Next action |
|---|---|---|
| [A specific, safe observation or test] | [Finding that supports this path] | [Matched correction and verification; stop here if resolved.] |
| [Next check if the first path does not apply or fails] | [Finding that distinguishes this case] | [Matched correction, another defined check, or escalation.] |
Conditional — confirmed cause: [Established cause and the evidence that identifies it. Omit this section when the cause is unknown.]
Conditional — temporary workaround: [Interim action, limits, and conditions for returning to the normal process. Do not label it a permanent fix.]
Verify resolution: [Repeat the relevant task and describe the expected outcome.]
If unresolved: [Verified escalation route and the minimum diagnostic details needed. Exclude passwords, credentials, and unrelated personal information.]
A hypothesis belongs in a diagnostic check, not in a statement of confirmed cause. The KCS v6 article-structure guidance explicitly treats Cause as optional. Do not manufacture an explanation to fill a blank field.
3. Short-answer or FAQ article template
Use this format for a question that can be answered directly, such as whether a setting changes everyone’s experience or only the current user’s. A single-answer article can stand alone or become one entry in a tightly themed frequently asked questions (FAQ) collection.
Copyable short-answer template
Title: [The specific question in the reader’s language]
Answer: [Direct answer, including any condition essential to keeping it true.]
Applies to: [Relevant audience, environment, or version. Omit as a separate line if already clear in the answer.]
Conditional — exceptions: [Circumstances in which the answer changes and what the reader should do instead.]
Conditional — example: [A brief case that resolves likely ambiguity without adding a new task.]
Conditional — next step: [Specific action or descriptive title and verified destination of a detailed procedure.]
Do not bury a qualified answer beneath a misleading “Yes.” Keep unrelated questions in separate articles, and move long instructions into a how-to rather than turning a short answer into a catch-all page.
4. Reference article template
Use a reference article when readers need precise information: a field’s meaning, accepted values, a default, or a supported constraint. Organize around what they will look up. Do not add a procedure merely to make the article look like other help content.
Copyable reference template
Title: [Feature, setting group, format, or field set] reference
Scope: [What this reference covers, its audience, and applicable product or specification version.]
Reference details:
| Item | Meaning and accepted values | Defaults and constraints |
|---|---|---|
| [Exact field or setting name] | [Purpose, allowed values, data type, and units where applicable.] | [Verified default and when it applies; separately identify any limit.] |
| [Next field or setting] | [Meaning and permitted values.] | [Dependencies, limits, or an explicit statement that no default applies.] |
Conditional — example: [A valid value or configuration, labeled as an example rather than a default.]
Conditional — interactions: [Which settings affect one another and under what conditions.]
Conditional — setup instructions: [Verified destination of the separate how-to article.]
Verify defaults, maximum values, and version-specific behavior against the authoritative specification. They are not interchangeable with recommended settings. Split a wide table into focused sections rather than shrinking text to fit more columns.
5. Explanation article template
Use this format when the reader needs to understand why something works as it does. For example, explaining the difference between a saved view and a copied task list requires a mental model, not just a menu path.
Copyable explanation template
Title: How [concept or behavior] works
Direct explanation: [Define the concept in familiar terms and explain why it matters to the reader’s situation.]
Scope: [Audience, relevant environment, and what this explanation does not cover.]
Key relationships: [Explain how the important parts connect. Define necessary terms when first used.]
Example: [A concrete situation showing the concept’s behavior, with enough context to avoid misleading generalizations.]
Limits and misconceptions: [What the concept does not imply and the conditions that change its behavior.]
Conditional — act on this information: [Relevant task or reference article, using its verified destination.]
Keep large configuration tables in reference material and operational steps in a how-to. Link to those resources when needed instead of forcing understanding, lookup, and execution into one long article.
6. Internal procedure and handoff template
Use this format when work must pass between authorized roles and produce a completion record—for example, handing an unresolved request to the next support shift. Its distinguishing features are responsibility, stop conditions, and acknowledgment, not merely an “Internal” label.
Copyable internal procedure template
Title: [Complete a defined internal process or handoff]
Trigger: Start when [event or condition]. This procedure ends when [completion condition].
Authorized roles: [Who performs the work, who receives it, and any required approver.]
Inputs: [Required records, permissions, approved tools, and checks before starting.]
Stop conditions: If [unsafe, unauthorized, or incomplete condition], stop at [safe state] and notify [responsible role through the approved route].
Procedure:
- [Starting role] checks [input] against [acceptance condition].
- [Responsible role] performs [action] and records [necessary evidence] in [approved system].
- [Receiving role] reviews [handoff information] and acknowledges [acceptance or the required correction].
Completion record: [Required outcome, responsible role, timestamp, and acknowledgment. Keep unnecessary personal information out.]
Conditional — exception or handoff failure: [Who retains responsibility and what to do when acceptance is refused or absent.]
Publish this material only to its authorized audience. A heading or tag does not enforce access restrictions. Keep confidential records in their approved system rather than pasting them into a broadly visible article.
Two completed knowledge base article examples
The following examples use a fictional browser-based task workspace. Members can create personal saved views. A view remembers its filters, its name does not control those filters, and later filter changes persist only after saving. These invented interface labels and behaviors demonstrate the templates; they are not instructions for a real platform.
Completed how-to: Save a personal view of open tasks
Goal: Create a personal view that shows only tasks whose status is Open.
Applies to: Members using the fictional workspace in a browser. You need access to the tasks you want to see.
Steps:
- In the sidebar, open Tasks, then All tasks.
- In the Status filter, select Open.
- Select Save view. In Name, enter Open tasks.
- Select Save. The view appears under My views.
- Open All tasks, then return to My views > Open tasks. Confirm that the Status filter remains set to Open.
Expected result: The saved view displays accessible tasks with Open status and excludes tasks with Completed status. An empty view is valid if you have no accessible open tasks.
If the result differs: If completed tasks appear, use the troubleshooting example below. If no view appears after saving, ask your workspace administrator to investigate and report the failed step without sending task contents.
The example states applicability, provides ordered actions, and checks the saved behavior after reopening. It does not confuse reaching a confirmation screen with verifying the result.
Completed troubleshooting: An “Open tasks” view shows completed tasks
Symptom: A personal view named Open tasks contains tasks marked Completed.
Applies to: Your own saved view in the fictional browser workspace. These checks do not require changing or deleting any tasks.
Check the view first. Open My views > Open tasks. If you were viewing All tasks, selecting the saved view may explain the difference. Check whether the symptom remains.
If the Status filter is not Open: Select Open, then select Save changes. Leave the view and reopen it. Confirm that the saved filter is Open and that no displayed task has Completed status. Stop here if the symptom is resolved.
If the Status filter is already Open: Leave the view and reopen it without changing tasks. If Completed tasks still appear, stop changing settings and ask your workspace administrator to investigate.
Cause: A mismatched saved filter explains the symptom only when the check establishes that mismatch. The view’s name alone does not determine its results. A correctly filtered view that still returns completed tasks remains unresolved.
Escalation details: Report the view name, the displayed Status filter, the time observed, and which check failed. Use the approved private support route; do not share credentials or private task descriptions.
The second example separates cases instead of telling everyone to run the same fixes. It states a cause only where supported and leaves the unexplained case for investigation.
Adapt a template without creating another duplicate answer
Search the existing collection before starting a new article. Zendesk recommends checking for existing documentation and flagging needed updates. If an accurate answer exists but is hard to find, first consider its title, terminology, and links rather than cloning it into a new format.
Collect the approved source facts before filling fields: intended audience, supported environment, required permissions, actual labels, behavior, and known exceptions. Keep unanswered questions in the review record. Do not replace missing facts with plausible instructions, whether you write the draft yourself or use AI assistance.
Separate the public article from its maintenance record. Readers need relevant applicability and warnings; editors need an accountable owner, source references, verification evidence, and review triggers. Customer-specific incident details belong in the appropriate case record, not the reusable answer.
Check what “template” means in your platform
A starting layout is different from synchronized reusable content. Mozilla’s article-writing guide describes templates that reuse common instructions within articles. Copying one of the structures on this page does not create that kind of live component. Plan how shared instructions will be maintained and verify the behavior of any reuse feature you adopt.
Platform restrictions also matter. In Jira Service Management Cloud’s documented article workflow, template selection is available for unpublished drafts. Changing templates creates a new article rather than carrying the current content into the new template. Do not assume that another editor behaves the same way or that changing a template updates previously published articles.
Should every article use one structure?
Not necessarily—but more templates are not automatically better. Knowledge-Centered Service (KCS) v6 recommends a simple shared structure built around Issue, Environment, Resolution, and optional Cause. It describes that structure as serving several kinds of support needs.
The six formats here are an alternative editorial toolkit, not an official KCS template set. A team already using KCS can retain its core fields while adapting the resolution to the task. Adopt only formats that answer a real need; do not create separate templates for “setup,” “onboarding,” and “getting started” when they produce the same article.
Check the filled article before publishing
Review structure, writing, and factual accuracy separately. Zendesk’s guidance calls for subject-matter review before publication. For procedures, ask a qualified reviewer to verify the steps safely in the applicable environment and record the result—not merely confirm that every template field contains text.
- Applicability: Can the intended reader tell whether the article covers their task, role, environment, and version?
- Actionability: Are prerequisites, permissions, branches, warnings, and expected outcomes complete? Does the failure path lead somewhere useful?
- Accuracy: Do claims, controls, values, and known causes match approved sources or verified behavior? Have unresolved assumptions stayed out of the published answer?
- Access and privacy: Can the intended audience reach the article and linked resources without exposing restricted content or unnecessary case details?
- Cleanup: Are all fill-in fields replaced, irrelevant sections removed, and real destinations checked? Keep the reusable master separate from the completed article.
Use real headings, descriptive links, and appropriately marked-up lists. These practices align with W3C’s writing accessibility guidance. Keep necessary instructions and error messages selectable as text; add screenshots only when they clarify context, with suitable text alternatives. Check that tables and examples remain readable in the published layout.
Assign an owner and a review trigger tied to relevant changes, such as a revised interface, permission model, process, or credible failure report. The template can remain stable while the facts inside an article need revision.
Choose the smallest structure that fully answers the reader’s need. Fill it with verified information, remove the parts that do not apply, and test the result. The purpose of a template is to support a dependable answer—not to make every page look equally full.
Sources verified: November 5, 2026.
