System runbook
Access, configuration, and the troubleshooting path for one internal system, documented well enough that the request stops arriving in your DMs.
Record it in this order
Requesting access
Capture the actual request path: the form, the approver, the group. Most "I cannot get in" tickets are really "I did not know how to ask".
First-time configuration
The settings a new user has to change before the tool is usable. Record yourself doing it on a genuinely fresh account, not yours.
The two or three failures you actually see
Not every possible error. The ones that generate real tickets, each with the check that identifies it and the fix.
Escalation
What to try before escalating, and exactly where it goes when those do not work.
Recording this safely
Runbooks are the highest-risk thing to record, because you are inside admin consoles with real data on screen.
- Password, one-time-code, and card fields are blurred automatically from DOM signals, before the screenshot is stored.
- That covers form fields, not text. Tokens and keys rendered as page text are not detected, so blur them in the editor.
- Pause the capture before you open a password manager, then resume. Nothing is recorded while paused.
- Keep it private, or share it with a specific group. Do not publish a public link for a runbook out of habit.
Full detail: security.
What to annotate afterwards
- Blur account identifiers, hostnames, and internal URLs that appear in the address bar.
- Add a warning callout on anything that affects other people, before that step.
- Number the troubleshooting branches so someone can jump to their symptom.
Who should have it
Grant view on the specific runbook rather than making everyone an editor of the workspace. Grants can carry an expiry, which is the right shape for a contractor who needs one system for one month.
Related: Knovvy for IT.