How to Write Work Instructions (With a Template and Examples)

A teammate of mine once inherited a task called "run the weekly billing export." The whole handover was a sentence in a leaving email: "the billing export is easy, you just pull it from the dashboard and send it to finance." On Friday she opened the dashboard. There were four exports. Three date-range options. A toggle she didn't recognize. She sent the wrong file, finance reconciled against bad numbers, and it took two people half a day to undo.

The task really was easy. The instruction was not. "Pull it from the dashboard" assumes you already know which export, which range, and which toggle. That gap between "I know how to do this" and "I can write down how to do this" is where work instructions live, and it's where most of them fall apart.

Here's how to write a work instruction that gets a real person through a real task without a single follow-up question.

Work instructions vs SOPs: the difference that trips people up

People use "SOP" and "work instruction" as if they're the same thing, then argue about which template to use. The distinction is simpler than the debate suggests, and once you see it the writing gets easier.

An SOP describes a whole standardized process. It covers the why, the who, the when, and the rough shape of the steps. A work instruction zooms into one task inside that process and answers a single question: how do I do this, exactly? The SOP is the map of the trip. The work instruction is the turn-by-turn for one leg of it.

Why does this matter for writing? Because the two documents fail in opposite ways. SOPs fail when they're too vague to act on. Work instructions fail when they zoom out and start explaining policy instead of clicks. If you find yourself writing "the purpose of this procedure is to ensure compliance with" in a work instruction, stop. That's SOP language. The reader of a work instruction is mid-task, hands on the keyboard, and they want the next click, not the mission statement.

If you're building the higher-level document too, our guide on how to write an SOP people follow covers the process side. This post stays at the task level.

How to write a work instruction, step by step

Six moves. None of them are complicated. The discipline is in not skipping the boring ones.

1. Name one task and one reader

A work instruction covers exactly one task. "Run the weekly billing export," not "manage billing." If your title needs an "and," you're describing two instructions. Then picture the person who'll read it on their worst day: the new hire in week one, covering for someone on leave, with the clock running. Write for them. Everything you'd skip because "they'll obviously know that" is the thing they don't know.

2. List what they need before they start

Nothing kills momentum like getting three steps in and discovering you need an access level you don't have. Put the prerequisites up top: the tools, the logins, the file, the permission. A reader should be able to glance at the header and know whether they can finish this right now or need to go ask for access first.

3. Write one action per step, starting with a verb

This is the rule that does the most work. "Open," "select," "click," "confirm." One action, one step. The reader should be able to do a step, look up at their screen, look back, and instantly find their place. The moment a step contains two actions joined by "and," a beginner loses the thread between them.

4. Show the screen

For any task done in software, a picture beats a paragraph at the exact moment it matters: when the reader has to find something. "Click the export button" is fine until there are three buttons that could be it. An annotated screenshot with the right one circled ends the hunt. This is the part most people skip, because capturing, cropping, annotating, and then re-capturing every time the interface shifts is genuinely tedious. Our guide to screenshots in documentation goes deep on doing it cleanly. If the task is software-based and you're writing the instruction from scratch, mark where each image goes before you start, so you don't talk yourself out of adding them later.

5. Mark the decisions and the "done" signal

Real tasks fork. "If the export is over 10,000 rows, split it by month first. Otherwise, send the single file." Call those out plainly, because the moment someone has to decide and the instruction stays silent is the moment they guess. And end with how the reader knows they succeeded: "Finance replies to confirm they received it" or "the status shows Reconciled." Without a finish line, people either stop early or keep poking at a task that's already done.

6. Test it on someone who has never done it

Hand the draft to a person who doesn't know the task. Watch them work through it. Don't help, don't hint, don't fill in the gap when they hesitate. Every pause is a place your instruction is broken. You can't catch these yourself, because you already know the answer and your eyes skip the hole. This one test finds more problems than re-reading your own draft ten times.

A copy-paste work instruction template

Steal this. Fill in the brackets, delete what you don't need, and keep it tight. It works in a doc, a wiki, or a help-center article.

Notice what's missing: no purpose statement three paragraphs long, no policy background, no scope-and-compliance preamble. That belongs in the SOP. The work instruction puts the steps first and the housekeeping at the bottom, where it won't slow anyone down.

Two work instruction examples

Templates click into place once you see them filled in. Here are two short ones from different corners of a company, both written for a first-timer.

Example 1: Issue a customer refund (support)

Example 2: Reset a new hire's email password (IT)

Both fit on one screen. Both are written for someone who has never touched the task. Neither wastes a line on why the company has refunds or passwords. If you're documenting a stack of IT tasks like this, the patterns in our IT SOPs and runbooks guide pair well with task-level instructions.

Keep them from going stale

A work instruction is only true until the tool changes. The button moves, the export screen gets a redesign, a field gets renamed, and now your carefully written steps send people in a circle. This is where most documentation dies, and it dies quietly, because nobody gets an alert when an instruction goes wrong. They just stop trusting it.

Two habits keep instructions honest. First, give every one an owner by role and a review trigger, not a vague "review annually." Tie it to the thing that actually changes: "review when the billing tool updates its export screen." Second, make the edit cheap. If fixing one outdated screenshot means re-recording the whole task and re-annotating every image by hand, it won't get fixed. The cost of the edit is the real reason instructions rot, not laziness.

That cost is the whole reason we built WriteHow. You record yourself doing the task once, and it drafts the ordered steps with annotated screenshots and any sensitive data blurred. You review and approve before anything goes live, so a person still owns the final word. When the tool changes, you re-record the affected steps instead of rebuilding the document, and you can publish the same instruction in 50+ languages without writing it five times. The point isn't to remove the human; it's to make keeping the instruction true cheap enough that it actually happens.

Start with the tasks people keep asking about. The ones that generate the most "wait, how do I do this again?" messages are the ones where a good work instruction pays for itself fastest. Write those, test them on a beginner, give them an owner, and you'll have replaced a stack of leaving-email guesses with instructions a first-timer can actually follow. That's the whole job, and it's worth doing well.