How to write work instructions: template and examples
Reviewed .
Work instructions explain how to carry out one task at the point of work. A reader should be able to identify the starting state, perform the actions and check the result without guessing what the author intended. The document can be short, but it must include the decisions that change what someone should do.
Start with a task such as ?assign an existing support ticket to a queue,? rather than ?manage support.? A narrow task is easier to test and update. This guide explains how to write work instructions, how they differ from SOPs and checklists, and how to use a copyable template without buying documentation software.
Work instructions, SOPs and checklists
Teams use these names differently. The practical distinction below helps you decide how much explanation a reader needs; it is a working convention, not a claim that every organization must classify documents this way.
| Document | Main question | Example |
|---|---|---|
| SOP | What process applies, who is responsible, and which controls govern it? | How support tickets are triaged, assigned, escalated and closed. |
| Work instruction | How do I perform this specific task in this environment? | How to assign an existing ticket to the correct queue in the support application. |
| Checklist | Have I completed the required checks? | Confirm customer, queue, assignee and saved status before finishing. |
A checklist is useful for an experienced operator who already knows the method. It may be insufficient for a new colleague who cannot find the queue field or decide which queue applies. A work instruction can link to the governing SOP and finish with a checklist. Avoid copying the entire policy into every task document; duplicates become inconsistent when one copy changes.
Define the task boundary
Write a title with a verb and object. Then state the audience, application, environment and required permissions. Explain what must already be true: the ticket exists, its customer is known, and the user has permission to assign it. If the task excludes changing priority or sending a customer reply, say so.
Describe the final state before writing the clicks. For the example, success means the existing ticket shows the intended queue after saving, with no unintended changes to customer or priority. That gives the author a test target and helps the reader recognize a partial result.
Identify who supplies the inputs and decisions. ?Choose the correct queue? is incomplete unless the reader has a routing rule or a person to consult. Link to the approved routing table, explain how to use it, and state what to do when no entry applies. Keep live credentials and private customer details outside the instruction.
Observe once, then explain the actions
Perform the task in a suitable test environment while taking notes. Separate necessary actions from habits and detours: opening a menu is necessary; repeatedly switching between tabs to find a record may indicate a missing prerequisite. Capture useful screens manually and record the exact labels the reader will see.
Begin each step with a verb, such as open, select, enter, save or verify. Pair the action with a result where it matters. ?Select Save. The ticket returns to its detail view? is clearer than ?Save everything.? If the save fails, specify whether to retry, stop or ask for help based on the real procedure.
Put a warning before the affected action. A note after a destructive click arrives too late. Separate routes that require different permissions or decisions, and make their entry conditions clear. An instruction should not send the reader through irrelevant steps simply because the author captured them.
Copyable work instruction template
Copy the block below into a Markdown editor or paste it as plain text into Word. Replace every bracketed item. Repeat the action section for each meaningful step; remove unused sections only after confirming they do not hide a necessary decision.
# [Verb + task name]
Document ID: [team identifier]
Owner: [responsible role]
Version / reviewed: [version] / [date]
Master: [approved location]
## Purpose and scope
Complete [task] so that [observable result].
Applies to [application, environment, audience].
Does not include [excluded actions].
## Before starting
- Confirm [correct account, customer or record].
- Obtain [required inputs] from [approved source].
- Required access: [permission or role].
- Stop if [prerequisite is missing].
## Instructions
1. [Action and exact control label].
Expected result: [visible state].
Input rule: [where values come from, if relevant].
Screenshot: [reviewed image or reference].
If different: [safe next action or escalation].
2. [Next action].
Expected result: [visible state].
## Finish
- Verify [saved result] against [approved input].
- Record completion in [existing record, if required].
- Stop / escalate to [role or route] if [condition].
## Maintenance
Related SOP: [master reference]
Review when: [screen, permission or rule changes]
Change note: [what changed and why]A worked step: assign a support ticket
Weak draft: ?Change the queue and save.? It does not identify the record, tell the reader where the queue comes from, or show how to check the change. The instruction assumes the reader already understands the routing process.
Improved example: ?Confirm the ticket customer matches the request. In the ticket detail view, select Queue and choose the destination specified by the approved routing table. If there is no matching route, stop and use the team's escalation channel. Select Save, then confirm the intended queue appears on the reopened ticket.?
This is an illustrative writing example, not a procedure for a particular support product. Replace the field names and expected behavior with what you verify in your application. Do not label the instruction approved merely because the written steps sound complete.
Use screenshots to locate, not to decide
Add an image when it helps someone find a control or recognize a result. Keep the relevant heading or navigation context visible. Explain required values in text: a screenshot of an empty field cannot tell the reader which business rule applies. Give images meaningful captions and keep the written sequence usable when an image is unavailable.
Review images and step text for private information before sharing. The screenshot redaction checklist covers names, URLs and notifications. For image selection and sequencing, see creating an SOP with screenshots.
Test with the intended reader
Give the draft to someone with the expected starting knowledge and permissions. Ask them to identify the correct record, follow the steps and show the final state in an appropriate environment. Watch for guesses and requests for verbal help. Add the missing information where the uncertainty occurred.
Keep a reviewed master and a way to report discrepancies. When the interface or routing rule changes, retest the affected steps and replace distributed copies. For broader process controls, adapt the free SOP template and link to the work instruction instead of duplicating it.
Where a browser recorder helps
For repeated Chrome tasks, Ownsteps can capture clicks as editable steps with screenshots. Edit titles and notes, remove detours and replace unsuitable images. It does not write your routing rules or decide when a task is authorized. For a one-off instruction, manual capture and your existing editor may be sufficient.