A workflow SOP should explain the trigger, required inputs, responsible roles, steps, completion check and exception route. Write it for the person who must perform the work, then test it with someone who did not design the process. Keep an owner and review history so the instruction changes when the real workflow changes.
- Define the boundaryName a recognizable start, end, reader, and task.
- State usable inputsIdentify prerequisites, permissions, and input sources.
- Show decision rolesIdentify performer, decision owner, and backup.
- Test completion and exceptionsDefine evidence of completion and the exception route.
An SOP should support a defined workflow, not an entire broad responsibility.
Document a defined workflow
Choose a process with a recognizable start and end. An SOP titled “manage clients” is too broad to give a person usable instructions. “Review a submitted intake and accept the delivery handoff” has a clearer boundary.
Name the reader and the task they should be able to complete. State any required permission or prerequisite. Do not assume the reader knows where an input lives or which person is authorized to decide an exception.
Use a practical structure
| SOP element | What to include | Test question |
|---|---|---|
| Purpose | Result this workflow produces | Why does this work exist? |
| Trigger | Event that starts it | When should I act? |
| Inputs | Required information and source | What do I need first? |
| Roles | Performer, decision owner and backup | Who can resolve a question? |
| Steps | Actions in their working order | Can I carry them out? |
| Completion | Evidence of the expected result | How do I know it is done? |
| Exceptions | Stop, correction and escalation routes | What if the normal path fails? |
| Maintenance | Owner and reviewed version | Is this instruction current? |
Screenshots can help with a specific interface, but describe the purpose of the action as well. An interface change should not make the whole instruction impossible to interpret.
- Start conditionsState purpose, trigger, and required inputs.
- Responsible rolesName performer, decision owner, and backup.
- Working instructionsList actions in their working order.
- Completion and exceptionsDefine completion evidence and recovery routes.
Screenshots can help, but should not be the only explanation.
Write actions with visible results
Use specific verbs and references. “Handle the intake” is vague. “Check the approved scope against the submitted deliverables and flag differences for the commercial owner” explains what to do and where the decision goes.
Separate actions from judgment. A person can follow a step to find the current proposal; deciding whether a request is in scope may need the authorized owner. The SOP should show that boundary rather than asking the performer to guess.
For an illustrative approval workflow, the instruction might require checking the current version, reviewing the named approver's decision and recording any conditions. It should not simply say “confirm approval” without explaining what counts.
Include the inconvenient paths
Document missing inputs, conflicting records, unavailable owners and failed automated steps. Keep the exception route close to the relevant step. A general note at the bottom saying “ask someone if stuck” does not establish responsibility.
- Missing inputState who supplies the missing information.
- Conflicting recordsState who resolves the contradiction.
- Unavailable ownerState backup or escalation responsibility.
- Failed automationLink to the applicable recovery instruction.
A generic instruction to ask someone does not establish responsibility.
Link to the exception handling guide for failed automated work and the handoff checklist for incomplete transfers. Use links instead of copying long instructions into several SOPs that may later disagree.
Test with a fresh reader
Give the SOP and a safe example case to someone who did not write it. Observe where they pause, ask a question or produce a different result. Those points reveal missing context.
Do not rescue every uncertainty verbally and then mark the SOP complete. Update the instruction so the next person receives the clarification too. If the workflow still depends on an undocumented expert decision, name that decision owner explicitly.
Maintain the instruction with the workflow
Assign an owner and record a reviewed version. Review after a material process or tool change, and when repeated exceptions show that the documented path is incomplete.
- Assign maintenance ownerName the person responsible for the instruction.
- Review material changesCheck after process, tool, or rule changes.
- Keep reviewed versionRecord the reviewed version and retain older versions.
- Fix repeated gapsUpdate instructions when exceptions reveal missing paths.
A recent date alone does not make an instruction current.
Keep older versions where your team can recover them, while making the current instruction unambiguous. The change control guide connects implementation changes with operating documentation. An SOP is useful when it describes current work, not because it has a recent date in its heading.
Questions and answers
How detailed should an agency SOP be?
Detailed enough for the intended performer to complete the defined workflow and recognize an exception. Include prerequisites, actions, decision boundaries and completion evidence. Avoid adding general background that obscures the steps the reader actually needs.
Can an AI tool create the SOP from meeting notes?
It can help draft an instruction, subject to your data practices, but the workflow owner must verify roles, steps and exceptions. Test the draft with a fresh reader. Meeting notes often contain discussion and alternatives that are not final operating decisions.
When should a workflow SOP be updated?
Update it when the actual process, tools, permissions or decision rules materially change, or when recurring exceptions reveal a gap. Keep a named maintenance owner and reviewed version rather than changing the date without checking the instruction.