Agiled Docs

Well-structured wiki pages are easier to scan, update, and reuse. Use a consistent structure when your team writes procedures or policies.

Structure pages for the reader who is doing the work, not for the person who already understands the process.

Recommended Structure

Use these sections for most internal pages:

Introduction: Explain the topic, audience, and why the page exists.
Key Details: Capture the core instructions, policy, or reference details.
Resources: Link to supporting files, workspace records, owners, or related pages.

Add a short owner or review note near the top for pages that affect finance, HRM, customer communication, security, or approvals. This makes it clear who can confirm changes later.

For pages tied to a setting, workflow, template, or integration, link the source configuration near the top. Readers should know where the live process is controlled.

Procedure Pages

For a procedure, use:

Purpose
Owner
Before you start
Steps
Review or approval
Troubleshooting
Related pages

Checklist Pages

For a checklist, use short action items. Put the most common path first, then add exceptions below it.

Make each checklist item verifiable. A teammate should be able to tell whether the item is complete without asking the writer what they meant. Use "Confirm invoice preview matches approved pricing" instead of "Check invoice".

Put prerequisites before action steps so users do not discover missing access, files, approvals, or records halfway through the process.

Policy Pages

For a policy, make the rule clear before adding background context. Users should not need to read a long explanation before understanding what to do.

Add a short "What changed" or "Last reviewed" note when the policy affects customer work, billing, HR, security, or approvals. This helps teammates know whether they are reading current guidance or old context.

Keep Sections Maintainable

Avoid turning one wiki page into a full manual. If a section needs many steps, move it to its own page and link it from the overview. Put owners, approval rules, and related records near the top so future editors know who can update the page.

Use headings that match search terms. A teammate is more likely to search refund approval than special cases, so section names should use operational language.

Split Long Pages

Split a wiki page when it has multiple audiences, multiple workflows, or a long exception list. Keep the overview short and link to focused pages for setup, daily use, troubleshooting, and policy details.

Section Review

Before publishing or updating a page:

make the first section explain the page purpose
keep steps in the order users perform them
move exceptions below the common path
link to source records instead of copying changing details
add a review owner for policy, billing, HR, or security pages

If users keep asking the same question after reading a page, split or rename the section that hides the answer.

Review high-impact pages after process changes and update section names so search and scanning still match how the team talks about the work.

Example Section Sets

For onboarding: purpose, owner, before kickoff, setup steps, customer handoff, exceptions, related templates.

For finance: policy, owner, approval threshold, steps, report checks, exceptions, related invoices or templates.

Wiki Page Structure