Work instruction template you can copy off this page

The template

A work instruction covers one task, done by one person, usually in one tool or at one bench. It is not a process document. If your draft has two owners in it, you are writing an SOP and should split it.

The whole template is five header fields and a numbered step list. That is it. Everything beyond those is something a reader will skip, and every field you add is another field that has to stay true.

The five header fields

Copy this block to the top of every work instruction you write. The right-hand column is what goes in it, not an example.

The field people leave out is "you need first", and it is the one that decides whether the instruction works. Somebody following a refund instruction who turns out not to have refund permission has wasted four steps discovering it. Put the prerequisite at the top and they find out in five seconds.

The field people fake is "last checked". A date that was copied forward without anybody re-running the task is worse than no date, because it tells the reader to trust something nobody verified.

How to write the steps

Six rules. They are boring and they are the difference between an instruction people follow and one they ask a colleague about instead.

1. One action per step. If the step contains the word "and", it is usually two steps.
2. Start with the verb. "Click Refund." "Weigh the carton." Not "you should then click" or "the next thing to do is".
3. Name what you click or touch exactly as it appears, capital letters included. A reader scanning for a button matches on the label, not on your paraphrase of it.
4. Say where it is only when it is not obvious. "Refunds, in the right-hand panel" saves a hunt. Describing the location of every element turns the instruction into prose.
5. Put decisions in the SOP, not here. If a step asks the reader to judge whether the refund is justified, that judgement belongs in the procedure above this one. A work instruction tells someone how, once the whether has been settled.
6. Screenshot the steps people get wrong, not all of them. Every screenshot is a maintenance liability with a shelf life of about one vendor redesign.

Filled example: a screen task

A refund issued in Shopify, written the way the template asks for it. Read it as a shape to copy rather than a procedure to adopt, since your refund rules are your own.

1. Open Orders and search the order number.
2. Open the order and check the fulfilment status. A fulfilled order needs the return received before you refund.
3. Click Refund.
4. Enter the approved amount. Leave the quantity fields alone unless you are refunding specific items.
5. Decide the shipping line. Refund shipping only where the returns SOP says to.
6. Untick Restock if the item is coming back damaged or is not coming back at all.
7. Add the reason in the note field, in the wording the returns SOP uses, so reporting stays consistent.
8. Click Refund to confirm. This cannot be reversed.
9. Reply to the customer on the existing ticket, not a new one.

Notice what is missing. Nothing in there decides whether the customer deserves a refund, how much, or whether shipping is included. Those are policy, they change without the software changing, and they live one level up.

Filled example: a physical task

The same template holds at a packing bench or a machine. The fields change meaning slightly: the system becomes a station, and the prerequisites become equipment.

1. Check the pick against the packing slip, item by item.
2. Inspect each item for damage before it goes in the box. Damage found now is a reprint, damage found by the customer is a return.
3. Line the base of the carton with void fill to a depth of two fingers.
4. Wrap each fragile item separately. Two items touching inside a box is the most common cause of breakage in transit.
5. Fill the voids until nothing moves when you shake the closed carton gently.
6. Tape the carton along the centre seam and both edge seams.
7. Apply the fragile label to the top and one side.
8. Scan the order to mark it packed before it leaves the bench.

Five mistakes that kill one

These come up again and again in documentation nobody uses. None of them is about writing quality.

• Written by the expert, never tested by a novice. The person who does the task daily cannot see the step they perform without thinking. Hand the draft to somebody who has never done it and watch where they stop.
• Policy smuggled into the steps. A refund limit sitting inside a work instruction gets changed in one document and stays wrong in four others. Keep thresholds in the procedure above.
• A person's name instead of a role. The instruction goes stale the day they change jobs, and nobody notices until somebody new reads it.
• Screenshots of every step. They look thorough for a fortnight. Then the vendor moves a menu and the whole document looks wrong, including the ninety per cent of it that is still correct.
• Stored somewhere other than where the work happens. An instruction in a shared drive folder loses to asking the person at the next desk, every time.

Where it sits next to the SOP

A standard operating procedure describes a process across people and systems. A work instruction describes one task inside it. The practical consequence is that they rot at different speeds: the SOP changes when the business changes, the work instruction changes when the software or the equipment does.

That is why they should be separate documents rather than one long one. A vendor redesign should force an edit to a page of clicks, not a re-read of your refund policy.

Keeping it true

Work instructions go wrong faster than anything else you write, because they name buttons owned by companies that redesign without telling you. A calendar review misses this. By the time the annual review comes around the instruction has been wrong for months, and people have quietly stopped using it.

Three triggers worth more than a schedule:

• Somebody asks a question the instruction should have answered. That is a defect report. Fix the document, not just the question.
• A tool ships an interface change. Every instruction naming that tool needs a pass, and the ones with screenshots need it first.
• A new starter follows it. Their first run is the only unbiased test you will get, and the window closes once they learn the workarounds.

Start with the task your team asks about most often. One instruction that gets followed is worth more than a folder of templates that got downloaded and never filled in.