Your colleague is out next week and someone has to run the refund queue, or close the books, or rotate the API keys. You have about twenty minutes to write down how it works. Spinning up an SOP platform, inviting a seat, picking a template, and learning a recorder is the wrong shape of effort for a job this small.
Here is a method that fits the job: open a browser tab, walk through the process once, narrate as you go, and send a link. No install, no extension, no account required.
Decide what you are actually documenting
Before you capture anything, write one sentence at the top of a scratch doc that names the trigger, the actor, and the outcome. For example: When a Stripe dispute email arrives, the on-call support person opens the dispute in Stripe, gathers evidence from Helpscout, and submits a response within 48 hours. If you cannot write that sentence, you are not ready to record steps; you are still figuring out the process.
Then list the steps in plain text. Five to fifteen is the right range for a one-off. If you are at thirty, you are documenting two processes and should split them. If you are at three, a Slack message is probably enough and you can stop reading.
Capture the screens in order
Open a new review in a browser tab. Put the app you are documenting in another tab or window. Run through the process at normal speed, capturing a still at each decision point: the inbox view that triggers the work, the form before you fill it in, the form after, the confirmation screen, the place you log the outcome.
A few rules that keep this short:
- Capture the state before a click, not after. The reader needs to see what to look for, not what happens when you finish.
- Crop tightly. If the step is about one button in a sidebar, crop to the sidebar. Full-window screenshots make the reader hunt.
- Drop a numbered pin on the exact control you mean. "Click Submit" is ambiguous when there are three Submit buttons on the page.
- One screenshot per step. If a step needs two screens, it is two steps.
For each screenshot, add a comment. Type it, or dictate it in Chrome or Edge using the built-in speech button. Dictation is faster for the kind of conversational instruction that documentation needs ("if the amount is over five hundred dollars, also tag the ticket as escalation"). Firefox users will type.
Write comments the way you would explain it standing next to someone
The single biggest quality difference between a useful one-off doc and a useless one is whether the writer included the why and the edge case. "Click Approve" is not documentation. "Click Approve. If the customer has more than two prior refunds in the last 90 days, do not click Approve; ping #finance instead" is documentation.
Three things to include in almost every step:
- What you are clicking and where it is on the screen.
- What you expect to see next, so the reader knows when something is wrong.
- The branch: what happens in the unusual case, even if it is just "this rarely happens, ask Priya."
Add free-floating comments (no screenshot) for things that do not belong to a single screen: credentials needed before starting, who to escalate to, the SLA, where the audit log lives.
Publish and hand it off
Hit Publish. You get a public URL like /r/abc123 that anyone can open without a login. Paste that into Slack or email along with your one-sentence summary from the top.
Two things to know about that link. The reader can post a comment on any step, so when they hit step 7 and the screen looks different, they can ask you right there instead of starting a new thread. And the same review is available as a PDF, a Word doc, and clean markdown at /r/abc123/markdown. If your team keeps an internal wiki, paste the markdown in and you have a permanent copy without rewriting anything. If they want it printed for a clipboard at a desk, export the PDF.
This is the shape of work that fits documenting a process for one teammate: capture once, share a link, done. You did not pick a tool, you picked a tab.
When this method is the wrong choice
Be honest about the boundary. If this process runs every week and ten people need to follow it identically, you want a real SOP system with versioning and assignments. If you need to track who completed which step, this method does not do that and pretending otherwise will burn you. If the process is mostly video, like "watch how I trace this bug across three tools," a recording belongs in the conversation, though see screen capture versus screen recording for when stills beat video.
For one teammate, one absence, one Friday afternoon, the browser-tab method wins on time-to-useful. Compare it to heavier step-recorder tools if you want, but for a single handoff the answer is almost always: capture the screens, narrate, publish, paste the link.
A worked example you can copy
Say you are documenting "close the monthly books in QuickBooks." Your one-liner: On the first business day of the month, the bookkeeper reconciles December, locks the period, and emails the P&L to the founder. Your steps, captured as eight screenshots with pinned comments: open the reconcile view, match the bank feed, flag uncleared items older than 30 days, run the P&L report, check the three accounts that usually have categorization errors (pin each one), lock the period, export the PDF, send the email with the standard subject line.
Add three free-floating comments at the end: credentials are in 1Password under "QBO admin," the founder wants the email by noon Pacific, if revenue is off by more than two percent month-over-month, do not send, call instead.
Total time to produce: about twenty-five minutes. Total time for your teammate to read and act on it: about five. Open a tab and try it on the next handoff that lands on your plate.