Somebody on your team knows how to reset a stuck Stripe webhook, or export the weekly active users chart, or kick off a release. Right now that knowledge lives in their head and a few Slack messages. You want it written down once, in fifteen minutes, in a format the next person can actually follow.
Below is a template you can copy into a doc, a wiki page, or a Cobalt Capture review. It is built for short, screenshot-led how-tos: the kind of thing that takes someone three to seven steps to do, not a 40-page runbook. Each section comes with a note on when to tighten it or drop it entirely.
The template, in full
Copy this whole block first, then read the explanations underneath.
Title: How to [do the specific thing], for [who]
When to use this: One or two sentences. The exact trigger or situation.
Before you start: Access, permissions, accounts, or info you need in hand.
Steps:
1. [Action verb + where you do it]. Screenshot with a pin on the button or field. One line of commentary if the screenshot is not self-explanatory.
2. [Next action]. Screenshot. Note any field that trips people up, with the exact value or format expected.
3. [Continue until done]. Final screenshot showing the success state, so the reader knows what "finished" looks like.
If something goes wrong: The two or three failure modes you have actually seen, and what to do about each.
Who to ask: A name or a channel. Not "the team".
Last checked: Date and who walked through it.
Why each section is there
The title
A title like "Stripe stuff" is useless six months later. Write the task and the audience: "How to refund a duplicate charge, for support". If two roles do the same task differently, write two how-tos. Do not try to cover both in one.
When to use this
This is the line that stops the wrong person from following your instructions. "Use this when a customer reports being charged twice within the same hour." If the trigger is obvious from the title, cut this section. If you needed two sentences to describe the trigger, the how-to is probably trying to cover too much.
Before you start
List the access and inputs the reader needs: a Stripe dashboard login, the customer's email, admin role in the CRM. If the reader has to stop halfway through to request access, your doc has failed. Skip this section only when the prerequisites are truly just "be logged in".
The steps
Each step is a single action plus a screenshot. The action verb goes first: Click, Paste, Select, Run. The screenshot shows where. A numbered pin on the exact button removes any guessing.
Two rules that keep steps short. One: if a step has the word "and" in it, split it. Two: do not narrate what the screenshot already shows. "Click the blue Save button in the top right" plus a screenshot with a pin on Save is one thing too many. Pick the screenshot.
Always end with a screenshot of the success state. "Done" is invisible otherwise, and the reader will keep poking around looking for one more step.
If something goes wrong
Skip the generic "contact support" advice. Write the failure modes you have personally hit: "If the refund button is greyed out, the charge is still pending. Wait an hour and try again." Two or three entries is plenty. If you have ten, the underlying process is broken and a how-to will not save it.
Who to ask and last checked
A name beats a channel. A channel beats nothing. The "last checked" line is the difference between a doc people trust and a doc people quietly route around. Re-walk the steps every quarter or after any tool update, then bump the date.
Filling it in fast with screenshots
The slow part of writing a how-to is not the words. It is the screenshots: capturing, cropping, pasting them into the right spot, then redoing two of them because you missed a step. A browser tab that captures the screen and lets you talk through what you see makes this part go.
Open a new review, click Capture screen, and walk the process the way you would do it normally. After each action, take a still and dictate the one line of commentary that step needs. Add a numbered pin if the target is not obvious. When you finish, publish. You get a public link to share, a PDF or Word version to attach to a ticket, and a markdown version if you want to paste it into your wiki.
Because there is no install or signup, you can hand the template to anyone on the team and they can produce their first doc the same afternoon. This is the workflow our quick documentation use case is built around, and it works just as well for a one-off Slack reply as for a permanent runbook.
When to adjust the template
For a Slack-only answer, drop everything except the steps and the success screenshot. Three pinned shots and a sentence each is often the whole deliverable.
For an FAQ entry that customers will read, expand the "if something goes wrong" section and rewrite the steps in customer language. The companion piece on writing FAQ entries with screenshots covers the tone shift.
For a process that gets handed to an engineer or an AI coding agent, keep the markdown export in mind: clean steps and pinned screenshots translate well. If the receiver is Cursor or Claude Code, the guide on giving feedback to an AI coding agent covers what to add.
For client work where you are documenting a process for the client to follow themselves, the no-tool-to-learn approach applies: send them the public link, not an invite to a platform.
Copy the template into a doc now. The first how-to you write with it will take longer than the second, and by the fourth you will stop thinking about the structure at all.