How to Create a Quick Reference Guide (Template + Examples)

Maya is two weeks into a support role. A customer wants a partial refund, which she's done exactly once, in training, eleven days ago. She remembers there was a thing about the order status, and a box you have to tick, and an email. She opens the team's "Refunds & Billing Process" doc. It's fourteen pages. There's a section on refund policy history. There's a flowchart for disputed chargebacks. Somewhere in there is the answer to "what do I click," but she's three tabs and four minutes in and the customer is waiting, so she does what everyone does: she pings a teammate.

That fourteen-page doc isn't wrong. It's just the wrong shape for what Maya needed, which was a card she could glance at while doing the task. That card is a quick reference guide, and most teams either don't have one or have buried it inside something nobody opens.

I've watched a lot of teams try to fix "people keep asking the same question" by writing a longer document. It almost never works. The fix is usually a shorter one. Here's how to build a quick reference guide that earns a spot on someone's second monitor.

What a quick reference guide actually is

A quick reference guide (sometimes a "QRG," or a "job aid," or just a "cheat sheet") is a short document, usually one page, that gets a person through one task or helps them recall key information without reading anything long. It's performance support. You reach for it while you're doing the work, not before.

The distinction that matters is shape, not subject. A user manual or an SOP is built for coverage: it explains the why, walks the edge cases, and stands up to an audit. A quick reference guide is built for the common path and nothing else. Same process, two different jobs.

You don't have to pick one. The strongest setup is both: the manual or SOP as the full source of truth, and a quick reference guide pulled out of it for daily use. The guide points back to the long doc for the rare stuff.

When to make one (and when not to)

A quick reference guide pays off when a task is done often, done by people who don't do it every day, or done under a little pressure. Refund processing, closing out a shift, running payroll, onboarding a new vendor in your procurement tool, the steps to escalate a Sev-1. Anything where someone thinks "I know I've done this, I just can't remember the exact order."

It's the wrong tool when the task is genuinely complex and branchy, where every situation is different and judgment matters more than steps. A guide for "how to handle an angry enterprise customer" turns into either uselessly vague or a manual in disguise. For those, train people and give them principles, not a cheat sheet.

How to create a quick reference guide

Five steps. None of them take long once you stop trying to be comprehensive.

1. Name the one task

Title the guide after the single thing it helps someone do, in their words: "Issue a refund," not "Refund and Reimbursement Procedures." If you find yourself wanting to add "and" to the title, you've got two guides. Split them. A reader should know from the title alone whether this is the card they need.

2. Write the steps as plain actions, in order

Each step starts with a verb and does one thing. "Open the order in the billing tool." "Click Refund." "Choose Partial or Full." Short lines. No background, no rationale, no "as you may recall from training." The reader is mid-task; every extra word is a word they have to skip.

3. Show the screen for anything done in software

This is the step that separates a guide people trust from one they second-guess. "Click the refund button" raises the question "which button?" A screenshot with the right spot marked answers it before it's asked. For a quick reference guide, you want a clean image per click-step, cropped tight to what matters.

This is also the part teams quietly avoid, because grabbing, cropping, annotating, and then re-grabbing every screenshot when the interface shifts is genuinely tedious. It's worth solving rather than skipping. One option: with a record-once workflow like WriteHow, you walk through the task a single time and the AI drafts an ordered, screenshotted guide you then trim down to the essentials. You approve and edit it; nothing ships without your review. For a quick reference guide, the trimming is most of the work, and starting from a captured draft beats starting from a blank page.

4. Mark the one or two decisions that matter

Even simple tasks have a fork. "Refund over $500? Get a manager's sign-off first." Call it out where it happens, in bold, so nobody blows past it. But keep it to the forks that actually come up on the common path. Bury the rare ones in the long doc.

5. Add a single "if it goes wrong" line

One short note for the most common failure: "Refund button greyed out? The order hasn't settled yet, wait an hour or escalate to billing." That one line prevents a chunk of the follow-up questions. Don't try to cover every failure. Cover the one that happens most.

A copy-paste quick reference guide template

Here's the whole thing on one screen. Fill the brackets, delete what you don't need, and resist the urge to add a preamble.

Three quick reference guide examples

To make this concrete, here's how the same shape plays out across different teams.

Support — issuing a refund. Title: "Issue a refund." Trigger: a customer asks. Five steps, two with screenshots (the refund button, the partial-vs-full toggle), one decision ("over $500, get a lead's okay"), and one failure line ("button greyed out means the order hasn't settled"). Lives pinned in the team's help desk, linked from the full billing SOP.

IT — onboarding a new laptop. Title: "Set up a new hire's laptop." Trigger: a start date is confirmed. Steps cover imaging, the security agent, and account provisioning, each with a screenshot of the admin console. The decision: "contractor or full-time?" changes which group they go in. This one saves the IT team from re-explaining the same setup every Monday.

HR — running the monthly payroll check. Title: "Pre-payroll review." Trigger: the 25th of the month. A short checklist, not a how-to: confirm new hires are in, confirm leavers are out, check flagged timesheets, approve. The "if it goes wrong" line points to who can unlock a closed pay period. People who run it twelve times a year still appreciate not having to remember the order.

Keep it from going stale

A quick reference guide goes wrong the same way every other doc does: the tool changes, a step stops matching reality, and people quietly stop trusting it. The difference is that a stale guide does more damage, because people rely on it in the moment without double-checking.

Two things keep it honest. First, give it an owner by role and a review trigger that isn't a vague calendar reminder. "The support lead rechecks this whenever the billing tool ships a UI update" beats "review quarterly," because it's tied to the thing that actually breaks guides.

Second, make updating cheap. This is the part most teams underrate. If correcting one wrong screenshot means re-recording the whole walkthrough and re-cropping six images by hand, the correction won't happen, and you'll watch the guide drift. If re-capturing a step takes two minutes, fixes actually get made. That's the real reason to use a tool that drafts and re-drafts guides from a recording rather than building each one by hand: not the first draft, but every draft after, when the interface has moved and you need the screenshots to catch up. The AI does the redraw; you approve it.

Maya didn't need a longer document. She needed a card with five steps and two screenshots she could glance at while the customer waited. Build that, keep it current, and you'll answer the same question once instead of every week.