---
title: "Internal How-To Guides: Share Team Knowledge Faster"
sidebarTitle: "Overview"
description: "Discover how internal how-to guides work, when to use them, and how they differ from formal SOPs — so your team can share knowledge fast."
---

> **For AI agents:** the complete documentation index is at [llms.txt](/llms.txt). Append `.md` to any page URL for its markdown version.

Internal how-to guides are the quickest way to share what you know with the people around you. Whether you're walking a new hire through a tool, documenting a workaround you discovered, or explaining a process only your team uses, a how-to guide gives you a lightweight, structured place to put that knowledge where others can actually find it.

## What Is a How-To Guide?

A how-to guide on this platform is an informal, task-focused article written by and for internal team members. Unlike a Standard Operating Procedure (SOP), a how-to guide doesn't go through a formal review cycle — you write it, publish it, and it's immediately available to your colleagues. The goal is to capture practical, actionable knowledge in plain language so anyone on the team can follow along and get something done.

Think of how-to guides as the "show your work" layer of your team's institutional memory. They sit alongside your formal documentation, filling the gaps that structured SOPs often leave behind.

## How How-To Guides Differ from SOPs

<Info>
  SOPs are authoritative process documents that typically require review and approval before publishing. How-to guides are designed to move faster and stay closer to the day-to-day reality of doing the work.
</Info>

| Dimension | How-To Guide | SOP |
|---|---|---|
| **Approval required** | No | Yes |
| **Who can write it** | Any contributor | Designated owners |
| **Tone** | Conversational, practical | Formal, prescriptive |
| **Update cycle** | On-demand by the author | Managed review schedule |
| **Best for** | Tips, tool walkthroughs, shortcuts | Compliance, audit trails, policy |

Because how-to guides don't require approval, they're ideal for capturing knowledge while it's still fresh — right after you figure something out, not two weeks later when you've forgotten the details.

## Good Use Cases for How-To Guides

How-to guides work best when the knowledge is practical, bounded, and useful to at least one other person on your team. Strong candidates include:

- **Onboarding tasks** — "How to request access to the data warehouse" or "How to set up your local dev environment"
- **Tool tutorials** — Step-by-step walkthroughs for internal tools, third-party apps, or integrations your team uses
- **Process walkthroughs** — Explaining a recurring task like running a weekly report or triaging a support queue
- **Tips and tricks** — Shortcuts, keyboard bindings, config tweaks, or anything that saves time once you know it
- **Troubleshooting guides** — Common errors and how to fix them, written by the person who fixed them

If you find yourself explaining the same thing to teammates more than twice, it belongs in a how-to guide.

## How Guides Are Organized

Every guide you publish is organized along three dimensions so colleagues can browse and search effectively:

**By team** — Each guide is associated with the team that owns it. Guides from the Engineering team appear in the Engineering section, guides from People Ops appear in theirs, and so on. You assign team ownership when you create the guide.

**By topic tags** — You can apply one or more topic tags to a guide (for example, `onboarding`, `data`, `security`, `tooling`). Tags power the platform's related-content suggestions and let people filter the guide library by subject area without knowing which team produced the content.

**By product area** — If your organization uses product areas to group work (for example, "Billing", "Auth", "Mobile"), you can associate a guide with a product area so it surfaces in the right context.

<Tip>
  Apply at least two tags to every guide you publish. Guides with multiple tags appear in more search results and are surfaced more often as related content on other articles.
</Tip>

## Explore the How-To Section

<Columns cols={2}>
  <Card
    title="Creating a Guide"
    icon="pen-to-square"
    href="/internal/how-to/creating-a-guide"
  >
    Follow a step-by-step walkthrough for drafting, formatting, and publishing your first internal how-to guide.
  </Card>
  <Card
    title="Linking Related Content"
    icon="link"
    href="/internal/how-to/linking-related-content"
  >
    Learn how to connect your guide to related SOPs, other how-tos, and external documentation using internal and cross-KB links.
  </Card>
</Columns>

## Frequently Asked Questions

<Accordion title="Who can write a how-to guide?">
  Anyone with contributor access to the Internal KB can create and publish a how-to guide. Contributor access is granted by your workspace admin — if you can log in to the platform and see the Internal KB, you most likely already have it. If you try to click "New Guide" and the option is grayed out, reach out to your admin to confirm your permission level. There is no minimum seniority requirement, and there is no limit on how many guides a single contributor can publish.
</Accordion>

<Accordion title="Do guides require approval?">
  No. How-to guides publish immediately when you click "Publish" — there is no mandatory review or approval step. This is intentional: the goal is to reduce friction so that knowledge gets documented quickly. That said, you can optionally request a peer review before publishing by using the "Request Review" option on the guide editor. If your team has an internal norm around reviewing guides before they go live, you can enforce that socially without needing a platform-level approval gate. Admins can also set team-level publishing policies that require review for specific teams if needed.
</Accordion>

<Accordion title="How do I make a guide searchable?">
  Three things have the biggest impact on how discoverable your guide is in search results. First, write a clear, specific title that uses the words someone would actually type when looking for help — action-oriented phrases like "Set up two-factor authentication" outperform vague titles like "2FA info." Second, apply relevant topic tags when you create the guide; tags feed directly into the search index and related-content suggestions. Third, fill in the description field with a sentence or two summarizing what the guide covers — this text appears in search result previews and helps readers confirm they've found the right article before clicking through.
</Accordion>