A standard operating procedure should help someone do the work correctly when the person who usually explains it is not available. That is a more useful test than page count, formatting or the number of screenshots it contains.
Start with one specific job. “Manage customer operations” is too broad for a practical SOP. “Check and route a customer address-change request” gives the document a clear beginning, a clear outcome and a manageable set of decisions.
The approach below is intended for everyday operational work. Specialist procedures involving regulated activities, safety or significant financial consequences need the appropriate expert review. A well-written document does not, by itself, establish compliance.
Watch the work before describing it
Ask an experienced operator to complete a realistic example while explaining their decisions. Observe what they check, what they ignore and where they pause. Do not interrupt every step; note the questions and return to them after the first pass.
Pay particular attention to phrases such as “usually,” “unless” and “you can tell.” These often mark decisions that are obvious to the experienced person but invisible to a newcomer. Ask what evidence supports the judgement and what should happen when that evidence is missing.
Repeat the exercise with a different example. A procedure built from one easy case can accidentally describe an exception as the normal rule. You do not need every possible case before drafting, but you should know which variations the first version covers.
Give the document a clear boundary
At the top, state the purpose, trigger, required inputs and expected output. Include the role that performs the work and the owner who can approve a change. A reader should know quickly whether they are looking at the right procedure.
Specify what is outside the scope. An address-change SOP may explain how to verify and route a request without authorising the operator to change billing details. If the boundary is unclear, the document can encourage people to act beyond their authority.
Add a short readiness check. Confirm that the user has the required access, source information and current reference material before beginning. A procedure should not reveal halfway through that a permission or approval was required from the start.
Write steps as actions with observable results
Use a direct verb and explain what should be true after the action. “Review the request carefully” is difficult to follow consistently. “Compare the customer reference in the form with the account record and flag any mismatch” gives the reader an observable task.
Keep each step focused. If an instruction contains several unrelated actions, separate them or introduce a small checklist. The purpose is to make omissions visible, not to make the document look more detailed.
Use the vocabulary the team sees in the interface. If the system labels a field “Case owner,” do not call it “Request manager” unless you explicitly explain the relationship. Consistent terminology saves the reader from translating between the procedure and the screen.
Put decision rules beside the relevant step
Do not hide every exception in an appendix that nobody consults during work. If a missing identifier changes what the operator should do, place that rule where the identifier is checked.
A practical decision statement has a condition and an action. “If the attachment is unreadable, mark the request as awaiting information and contact the requester using the approved template.” Add the escalation route if the condition remains unresolved.
Use examples to show the boundary between similar cases. Two records with the same name are not necessarily duplicates. Show which supporting fields are required before a merge can be considered, and make clear who has authority to approve it. Where the decision cannot be safely simplified, instruct the reader to stop and escalate.
Use screenshots selectively
Include a screenshot when a location, setting or visual state is genuinely difficult to explain in words. Crop it to the relevant area and label the control that matters. Avoid a full-screen image containing tiny text, unrelated tabs and distracting personal information.
Remove or anonymise sensitive details before putting an image into the procedure. Do not assume an internal document can contain unrestricted customer data. Follow the organisation’s approved information-handling rules for training and documentation.
Pair the screenshot with a written instruction. Interfaces change, images may not load and some readers may use assistive technology. The procedure should remain understandable even when the picture is not the primary way someone receives the information.
Test with the person who did not write it
Give the draft and a realistic practice case to a team member who has the necessary basic skills but has not memorised the process. Ask them to work from the document and explain where they are uncertain.
Resist the urge to rescue every hesitation immediately. The hesitation is evidence about the document. If the reader needs to ask what a status means, add the definition. If the instruction assumes a permission they lack, clarify the prerequisite.
The ASQ Plan-Do-Check-Act model includes testing a change, checking results and acting on what was learned. Applying that cycle to an SOP means treating its first version as something to test in use, not as finished because it was approved in a meeting.
Make updates controlled and visible
Give the procedure a version, an owner and a review date. Record what changed and why. A useful change note might say that a new source field changes the matching rule, rather than simply saying “updated process.”
Keep one authoritative version. If people need printable or downloadable copies, mark them with the version and explain how to check whether they are current. Do not let a shared folder become a collection of nearly identical files called “final.”
When a meaningful instruction changes, tell the affected people and confirm understanding through a short example. A notification is not the same as adoption. Ask the team to show how they would handle a case under the revised rule.
Build a compact SOP template
Use the following structure as a starting point:
- Purpose: The business outcome this procedure supports.
- Scope: The request types included and explicitly excluded.
- Owner and version: Who maintains the rule and which version applies.
- Inputs and access: What must be available before work starts.
- Steps: Actions in the order they should be performed.
- Decision rules: What changes the normal path and who decides.
- Quality checks: What proves the output is ready for the next user.
- Escalation: What to record, who to contact and what to do while waiting.
- Examples: A correct item, a common mistake and a difficult case.
- Change history: What changed, why and when it took effect.
Keep the format consistent across procedures, but do not force every process into the same length. A short workflow may need one page; a more complex workflow may need several linked instructions.
The final test is practical: can someone complete the work, recognise when not to continue and leave a record another person can understand? If yes, the document is doing its job.
Use the customer support playbook for an example of combining rules with judgement. For records-based work, the data quality guide shows how field definitions and review criteria can support the procedure.
Examples and suggested targets are illustrative, not Dhiti client results or contractual commitments. Adapt the approach to your process, risk and team.
