A standard operating procedure, commonly called an SOP, explains how a recurring task or process should be performed.
An effective SOP does more than list instructions. It establishes a repeatable method, identifies responsibilities, clarifies required inputs and outputs, supports quality control, and helps an organisation preserve operational knowledge.
This representative case study examines how informal working practices can be converted into useful standard operating procedures for employees, managers, contractors, and other authorised users.
The case study does not identify a real client or claim that the described project was completed for a named organisation. It presents a practical example of the type of procedure-development work that Lamtas can support.
The organisation had several important processes that were being performed through a combination of:
This created operational inconsistency.
Two employees could perform the same task in different ways. New employees required significant supervision. Managers had difficulty confirming whether procedures were being followed. When experienced staff were absent, important knowledge was not always available.
The organisation needed procedures that could be understood and used by the people responsible for carrying out the work.
The project focused on developing SOPs that were:
Undocumented processes create several risks.
When employees use different methods, the quality of the final output may vary.
New staff may need to depend on experienced employees for instructions that should already be documented.
Important knowledge may exist only in the memory of one person or a small group.
Employees may repeatedly ask managers how to perform routine tasks.
Missing steps, unclear responsibilities, and inconsistent checks may lead to errors.
When responsibilities are not documented, it may be difficult to determine who performs, reviews, approves, or records each activity.
An organisation cannot easily improve a process that has not first been described accurately.
The purpose of the SOP project was therefore not simply to create documents. It was to make operational knowledge visible and usable.
A useful SOP answers practical questions such as:
A procedure that only says “process the request and update the system” is too vague for many operational situations.
The reader needs to know what “process” means, which system is used, what information is required, what checks must be performed, and what evidence should be retained.
Not every activity requires a lengthy SOP.
The first step is to identify processes that would benefit most from formal documentation.
Priority may be given to processes that are:
A simple process-prioritisation method can assess:
| Criterion | Low Priority | Medium Priority | High Priority |
|---|---|---|---|
| Frequency | Rarely performed | Performed periodically | Performed daily |
| Business impact | Limited impact | Moderate impact | Significant impact |
| Error risk | Low | Moderate | High |
| Staff dependency | Minimal | Some dependency | Highly dependent |
| Training need | Simple | Moderate | Complex |
| Compliance relevance | None | Some relevance | Significant relevance |
This helps the organisation avoid spending excessive time documenting low-value activities while important processes remain undocumented.
Before writing an SOP, the actual process should be understood.
The documented process may differ from the process employees believe they follow.
Information can be gathered through:
The review should distinguish between:
This distinction is important because copying an outdated policy may produce an SOP that looks formal but does not reflect real work.
Process mapping helps show the sequence of activities and the relationship between different roles.
A simple workflow may include:
Not every process follows this exact sequence.
The workflow should be based on the actual activity being documented.
A process map can reveal:
The SOP should document the approved process, not automatically preserve every inefficient historical practice.
Every SOP should have a clear scope.
The scope explains where the procedure begins and ends.
For example, an employee onboarding SOP might begin when a signed employment offer is received and end when the employee has completed the required induction activities.
A customer complaint SOP might begin when a complaint is received and end when the complaint is resolved, recorded, and reviewed.
A purchasing SOP might begin when a purchase request is submitted and end when the goods or services are received, checked, and recorded.
Clear scope prevents the document from becoming unnecessarily broad.
If related activities require separate procedures, the SOP should link to them rather than attempting to describe every organisational process in one document.
A practical SOP may contain the following sections:
The exact structure should be adapted to the organisation.
A short internal procedure may not need every section. A regulated or high-risk process may require more formal controls.
The purpose section should explain why the procedure exists.
A strong purpose statement identifies the activity and the intended result.
For example:
This procedure explains how customer service requests are received, recorded, assigned, resolved, and closed so that requests are handled consistently and relevant records are maintained.
A weak purpose statement may say:
To provide excellent customer service.
The second statement is positive but does not explain what the SOP controls.
The purpose should be specific enough to help the reader determine whether the procedure applies to the task at hand.
Unclear responsibility is a common cause of process failure.
An SOP should identify who:
A responsibility table can be useful:
| Role | Responsibility |
|---|---|
| Process owner | Ensures the procedure remains accurate |
| Task performer | Completes the required steps |
| Reviewer | Checks quality and completeness |
| Approver | Authorises decisions where required |
| Records administrator | Maintains required records |
| Manager | Resolves escalated issues |
The same person may hold more than one role in a small organisation.
The document should nevertheless make the responsibilities clear.
Inputs are the information, materials, approvals, or resources required before the process can begin.
Examples include:
Outputs are the results produced by the process.
Examples include:
Identifying inputs and outputs helps employees understand what they need and what they are expected to produce.
SOP steps should use clear action verbs.
Useful verbs include:
Avoid vague instructions such as:
If an instruction depends on another document, system, or policy, the reference should be identified.
Each step should ideally communicate:
Weak instruction:
Review the request and process it accordingly.
This leaves several questions unanswered:
Improved instruction:
The assigned officer reviews the request for completeness, confirms the customer’s contact details, checks that the required supporting documents are attached, and records the request in the approved tracking system. If information is missing, the officer contacts the requester before the request is assigned for processing.
The improved instruction is more useful because it identifies the action, responsibility, checks, system, and exception.
Some procedures require different actions depending on the circumstances.
Decision points should be written clearly.
For example:
Decision points reduce uncertainty and help employees respond consistently.
They also make the SOP easier to convert into a workflow diagram or digital process.
Real processes rarely operate perfectly every time.
An SOP should explain what happens when:
Exception instructions should identify:
An SOP should not encourage employees to improvise in high-risk situations where a defined escalation route is required.
Quality checks should be placed at the point where they are most useful.
A final review alone may not be sufficient if errors can be detected earlier.
Quality checks may include:
The SOP should explain what constitutes an acceptable result.
A statement such as “check for accuracy” is less useful than a specific instruction describing what must be compared or verified.
Many processes require evidence that the work was completed.
Records may include:
The SOP should identify:
Recordkeeping requirements should be consistent with the organisation’s applicable policies and legal obligations.
A well-written SOP can support employee training, but it should not be treated as a complete substitute for supervision or practical instruction.
Training may involve:
The SOP should be written in a way that allows a new employee to understand the process without assuming that the employee already knows every internal term or system.
Where specialised knowledge is required, the SOP should identify the relevant training or supporting document.
A procedure may be technically accurate but still difficult to use.
Usability testing can involve asking an employee who did not write the SOP to perform the task using only the document and the authorised tools.
The reviewer can record:
The SOP should then be revised based on the findings.
This process is especially useful for procedures used by new employees or by staff who perform the task infrequently.
SOPs should be controlled so employees can identify the current approved version.
Document control may include:
Old versions should not remain in locations where employees may accidentally use them.
A revision history can help explain why a procedure changed.
For example:
| Version | Date | Change | Approved By |
|---|---|---|---|
| 1.0 | Initial issue | New procedure created | Process owner |
| 1.1 | Review date | Clarified approval steps | Department manager |
| 2.0 | Review date | Updated workflow and responsibilities | Authorised approver |
The writer may omit important exceptions or steps that experienced employees perform automatically.
An outdated process may contain unnecessary approvals, incorrect systems, or obsolete responsibilities.
Instructions must describe observable actions rather than general expectations.
Employees need guidance when the normal process cannot be followed.
Someone must be responsible for keeping the procedure accurate.
A single document should not attempt to describe every related process.
Excessive detail can make routine instructions difficult to use. Supporting documents can be linked where appropriate.
The procedure should explain how the user confirms that the task was completed correctly.
Employees may follow different versions if document control is weak.
A document that has not been tested may contain hidden gaps.
A repeatable SOP development workflow may include:
This workflow helps ensure that the SOP is based on actual operational requirements rather than assumptions.
Before approving an SOP, confirm that:
The central lesson is that an SOP should be designed for use, not merely for storage.
A document may look professional and still fail if employees cannot quickly determine:
A strong SOP connects operational knowledge with practical action.
It should be:
The best procedures also create a foundation for training, quality assurance, process improvement, and business continuity.
Lamtas can support organisations that need to document, improve, or standardise operational processes.
Relevant support may include:
Explore Documents, Writing & Content Services for support with SOPs, manuals, work instructions, reports, and other professional documents.
For process reviews, information gathering, and operational improvement support, explore Research and Consulting Services.
You can also explore the Technical Writing Guides and Documents and Content Guides.
A standard operating procedure is a controlled document that explains how a recurring task or process should be performed.
SOPs help improve consistency, support training, preserve operational knowledge, clarify responsibilities, and provide a reference for quality review.
An SOP usually explains the overall process, responsibilities, controls, and sequence. A work instruction normally provides more detailed guidance for completing a specific task or step.
The length depends on the complexity and risk of the process. It should contain enough detail to support correct performance without unnecessary repetition.
Not necessarily. Priority should be given to processes that are frequent, important, complex, risky, regulated, or dependent on undocumented knowledge.
Approval should come from the person authorised to confirm that the procedure is accurate, appropriate, and consistent with organisational requirements.
The review frequency should reflect the importance and rate of change of the process. An SOP should also be reviewed after major system, staffing, policy, or workflow changes.
Yes. Existing SOPs can be reviewed for clarity, structure, completeness, usability, consistency, and document control.
A standard operating procedure is valuable when it helps the right person perform the right task in the right way with less uncertainty.
Effective SOP development combines process understanding, clear writing, responsibility mapping, exception planning, quality control, and document maintenance.
When operational knowledge is documented carefully, organisations can reduce avoidable confusion, support employees more effectively, and create a stronger foundation for consistent service delivery.