A work instruction explains how to perform one specific task.
It is generally narrower than a Standard Operating Procedure.
An SOP may explain an entire process involving several activities and roles. A work instruction usually focuses on one task and provides the level of detail required for someone to perform that task correctly.
This template can be adapted for:
The completed instruction should reflect the actual task, environment, tools, equipment, systems, and requirements involved.
Work Instruction Title:
[Insert task title]
Instruction Number:
[Insert reference number]
Department:
[Department]
Process:
[Parent process]
Task Owner:
[Role]
Author:
[Name or role]
Reviewer:
[Name or role]
Approver:
[Name or role]
Version:
[Version]
Status:
[Draft / Under Review / Approved / Superseded]
Effective Date:
[Date]
Review Date:
[Date]
| Version | Date | Author | Description of Change | Reviewer | Approval |
|---|---|---|---|---|---|
| 0.1 | [Date] | [Name] | Initial draft | [Name] | [Status] |
| 0.2 | [Date] | [Name] | [Change] | [Name] | [Status] |
| 1.0 | [Date] | [Name] | Approved version | [Name] | [Status] |
Record significant changes so users can understand how the instruction has evolved.
Explain what the task accomplishes.
Purpose:
[Describe the task and its intended outcome.]
The purpose should be short and specific.
For example:
Define the boundaries of the instruction.
[Location, system, equipment, department, software version, or operating environment.]
Identify who should perform the task.
Primary User:
[Role]
Required Experience:
[Experience level]
Required Training:
[Training]
Required Qualification:
[Qualification, certification, or authorisation if applicable]
Supervisor or Reviewer:
[Role]
Explain the circumstances under which the instruction applies.
Trigger:
[Event or condition that requires the task.]
Frequency:
[Daily / Weekly / Monthly / Per Transaction / As Required / Other]
Preceding Activity:
[Activity that must occur before this task.]
Following Activity:
[Activity that occurs after completion.]
Describe exactly what successful completion looks like.
Expected Result:
[Describe the final condition.]
A useful expected-result statement should be observable or verifiable where possible.
List everything required to perform the task.
| Item | Description | Quantity | Required Condition |
|---|---|---|---|
| [Tool] | [Description] | [Qty] | [Condition] |
| [Tool] | [Description] | [Qty] | [Condition] |
| [Equipment] | [Description] | [Qty] | [Condition] |
Do not include unnecessary tools simply because they may sometimes be useful.
Identify materials, information, or records required before starting.
| Input | Specification | Quantity | Source |
|---|---|---|---|
| [Input] | [Specification] | [Quantity] | [Source] |
| [Input] | [Specification] | [Quantity] | [Source] |
Examples include:
Where applicable, identify the required software or system environment.
Application:
[Application]
Version:
[Version]
Operating Environment:
[Environment]
Required Account:
[Account or role]
Required Permission:
[Permission]
Required Configuration:
[Configuration]
Never include passwords or other authentication secrets in the work instruction.
Where relevant, identify safety precautions before the task begins.
[Insert safety information.]
| Hazard | Potential Consequence | Control |
|---|---|---|
| [Hazard] | [Consequence] | [Control] |
| [Hazard] | [Consequence] | [Control] |
[Describe required emergency action.]
For safety-critical tasks, the completed instruction should be reviewed by appropriately qualified personnel.
Define what quality means for this task.
[Acceptable range or tolerance.]
[Characteristics that must not be outside specification.]
Complete these checks before performing the task.
Provide a short summary of the task sequence.
This overview should be brief.
The detailed instructions follow below.
Action
[Describe exactly what the user must do.]
Where
[Identify the location, system, component, screen, workstation, or equipment.]
Method
[Explain how the action should be performed.]
Expected Result
[Describe what should happen.]
Check
[Explain how the user verifies the result.]
Action
[Describe exactly what the user must do.]
Where
[Identify the relevant location or system.]
Method
[Explain how the action should be performed.]
Expected Result
[Describe what should happen.]
Check
[Explain how the user verifies the result.]
Action
[Describe exactly what the user must do.]
Where
[Identify the relevant location or system.]
Method
[Explain how the action should be performed.]
Expected Result
[Describe what should happen.]
Check
[Explain how the user verifies the result.]
Action
[Describe exactly what the user must do.]
Where
[Identify the relevant location or system.]
Method
[Explain how the action should be performed.]
Expected Result
[Describe what should happen.]
Check
[Explain how the user verifies the result.]
Action
[Describe exactly what the user must do.]
Where
[Identify the relevant location or system.]
Method
[Explain how the action should be performed.]
Expected Result
[Describe what should happen.]
Check
[Explain how the user verifies the result.]
Identify steps where an error could materially affect quality, safety, security, cost, compliance, or the final outcome.
| Step | Critical Requirement | Verification |
|---|---|---|
| [Step] | [Requirement] | [Verification] |
| [Step] | [Requirement] | [Verification] |
Critical steps should receive particular attention during training and quality review.
If the task requires different actions depending on circumstances, document them explicitly.
Condition:
[Describe condition.]
If Condition A Applies:
[Action.]
If Condition B Applies:
[Action.]
Condition:
[Describe condition.]
If Yes:
[Action.]
If No:
[Action.]
Where the task involves measurable requirements, document them clearly.
| Parameter | Target | Acceptable Range | Measurement Method |
|---|---|---|---|
| [Parameter] | [Target] | [Range] | [Method] |
| [Parameter] | [Target] | [Range] | [Method] |
Always state units where applicable.
Identify points at which the user should stop and verify the work.
Check:
[What should be checked?]
Acceptance Requirement:
[What constitutes an acceptable result?]
If Check Fails:
[Corrective action.]
Check:
[What should be checked?]
Acceptance Requirement:
[Requirement.]
If Check Fails:
[Corrective action.]
Document common mistakes that users should avoid.
| Error | Why It Happens | Prevention |
|---|---|---|
| [Error] | [Cause] | [Prevention] |
| [Error] | [Cause] | [Prevention] |
| [Error] | [Cause] | [Prevention] |
Focus on errors that are realistically likely to occur.
Use this section when the expected result does not occur.
| Symptom | Possible Cause | Check | Corrective Action |
|---|---|---|---|
| [Symptom] | [Cause] | [Check] | [Action] |
| [Symptom] | [Cause] | [Check] | [Action] |
| [Symptom] | [Cause] | [Check] | [Action] |
Explain circumstances where the normal instructions do not apply.
Condition:
[Condition]
Alternative Instruction:
[Action]
Approval Required:
[Yes/No]
Responsible Role:
[Role]
Condition:
[Condition]
Alternative Instruction:
[Action]
Approval Required:
[Yes/No]
Responsible Role:
[Role]
Define circumstances in which the user must stop the task.
Stop work when:
Escalation Contact:
[Role or team]
If the task fails a quality check, document the approved corrective action.
| Failure | Corrective Action | Recheck Required |
|---|---|---|
| [Failure] | [Action] | [Yes/No] |
| [Failure] | [Action] | [Yes/No] |
Corrective actions should not be improvised for safety-critical or highly controlled activities.
After the main task is completed:
Confirm that the task has been completed successfully.
Identify records generated by the task.
| Record | Created By | Storage Location | Retention |
|---|---|---|---|
| [Record] | [Role] | [Location] | [Period] |
| [Record] | [Role] | [Location] | [Period] |
Examples:
If another person or team takes over after completion, document the required handover.
Receiving Role:
[Role]
Information to Transfer:
Handover Method:
[Method]
Confirmation:
[How receipt is confirmed]
Identify the training needed before someone performs the task independently.
[Describe practical training.]
[Describe supervised practice requirements.]
[Describe how competence is evaluated.]
[Describe who authorises independent performance.]
Where measurable standards apply, record them here.
| Measure | Standard | Measurement Method |
|---|---|---|
| [Measure] | [Standard] | [Method] |
| [Measure] | [Standard] | [Method] |
Possible standards include:
A work instruction should not encourage users to sacrifice safety or quality merely to complete a task faster.
Where competing requirements exist, document the priority clearly.
Priority Order:
Adapt this order to the actual operating environment and applicable requirements.
Where useful, include:
[Insert image or diagram.]
Caption:
[Explain what the figure shows.]
[Insert image or diagram.]
Caption:
[Explain what the figure shows.]
Visuals should reinforce the instruction rather than merely decorate the document.
Where appropriate, provide an example of a correctly completed task.
[Describe or show the expected result.]
[Describe a common incorrect result.]
[Explain why the correct result meets the requirement.]
Examples are especially useful when quality depends on visual or contextual judgement.
Use this checklist during execution where practical.
Test the instruction before final approval.
[Name or role]
[Date]
[Task]
[Conditions]
[Pass / Requires Revision]
A useful test is to give the instruction to an appropriately trained user who was not involved in writing it and observe whether they can complete the task correctly.
An SOP and a work instruction can be used together but serve different purposes.
An SOP generally explains:
A work instruction generally explains:
An SOP might state:
“Process customer refund requests according to the approved refund workflow.”
A related work instruction might explain:
“How to enter and approve a customer refund in the payment system.”
The SOP governs the broader process. The work instruction provides detailed task-level execution guidance.
A work instruction may document:
A work instruction may document:
A work instruction may document:
A work instruction may document:
A work instruction may document:
A work instruction may document:
A work instruction may document:
A work instruction may document:
Avoid:
Review the instruction when:
| Date | Change | Reason | Reviewer | Version |
|---|---|---|---|---|
| [Date] | [Change] | [Reason] | [Reviewer] | [Version] |
| [Date] | [Change] | [Reason] | [Reviewer] | [Version] |
Explore related Lamtas resources:
This template is a general framework for developing work instructions.
The completed instruction must reflect the actual task, equipment, software, environment, specifications, safety requirements, quality requirements, and organisational controls.
For safety-critical, regulated, engineering, industrial, medical, cybersecurity, financial-control, or other high-risk activities, the final work instruction should be reviewed and approved by appropriately qualified personnel before use.
A work instruction should answer a practical question:
“If I am authorised and trained to perform this task, exactly what do I need to do, what should I expect to see, and how do I know that I have done it correctly?”
The strongest work instructions connect:
Preparation → Action → Expected Result → Verification → Correction → Completion
That makes them useful for training, operational consistency, quality assurance, knowledge transfer, process control, and continuous improvement.