A standard operating procedure, usually shortened to SOP, records how an agreed recurring task is carried out. For ordinary administrative work, it should answer a practical question: could a suitable person complete this task using the document and the agreed access, without repeatedly asking the original author what they meant?
That does not require a long manual. It requires the details that are easy to overlook when you know a task well: where to begin, which source is current, what a decision depends on and when to stop for help. Use this approach for a bounded process such as preparing a meeting pack or updating an approved project tracker.
Give the SOP one clear job
Start with a specific title and outcome. “Prepare the weekly delivery meeting pack” is clearer than “meeting administration”. State who the procedure is for and what they need to know already. An SOP can explain your local process, but it should not assume that a reader has specialist competence simply because instructions exist.
Define the trigger and finish condition. For example, work starts when the meeting date is confirmed and ends when the approved pack is available in the agreed location and attendees have been told where to find it. Keep related but separate activities outside the boundary, with a reference to their owner or procedure.
- Title, purpose and intended reader.
- Start trigger and evidence of completion.
- Owner, approver, version and review date.
- Required inputs, access and templates.
- Steps, decision points, exceptions and final checks.
Capture the task while it is being done
Ask the person who normally does the work to demonstrate a recent ordinary case. Draft the instructions from that sequence, then ask about exceptions. Notice small actions they perform without mentioning them: checking a document date, comparing two totals or asking whether a late item should be included. These may be the steps another person most needs.
Separate the process from personal habits. A saved desktop shortcut might be convenient for one person but unavailable to everyone else. Name the agreed shared location or record instead. If the demonstration reveals conflicting sources or an undocumented approval rule, resolve the process question with the owner before presenting it as settled instruction.
Write steps that say what to use and what to produce
Begin each step with an action. Add the source, the relevant rule and the expected output where needed. “Check the tracker” is vague; “open the current project tracker and identify actions due before the meeting date” tells the reader what they are checking for. Keep one main action in each numbered step.
Use exact internal document names when they are stable, with an agreed link or location in your actual SOP. Explain terms a new reader might not know. Screenshots can support a step, but the written instruction should still explain the goal. A screenshot of a button alone becomes hard to use when the screen layout changes.
| Vague instruction | Usable instruction |
|---|---|
| Get the latest figures | Use the approved figures in the current reporting folder; stop if approval is missing. |
| Send it for review | Ask the named meeting owner to approve the draft pack before circulation. |
| File the final version | Save the approved pack in the meeting folder using the agreed date and version name. |
Include the points where the reader must decide or stop
The normal route is only part of a useful procedure. Write down the common exceptions and what the reader is authorised to do. If source information is missing, should they request it, mark the item as awaiting input or pause the whole task? If the meeting date changes, which steps need checking again?
Use clear conditions rather than “use your judgement” where the decision has an agreed rule. A fictional meeting-pack instruction could say: “If a report has not been approved, list it as awaiting approval and tell the meeting owner; do not circulate it as final.” This names the situation, the allowed action and the boundary.
Include a route for unfamiliar exceptions: who to contact, what context to provide and where to record the answer. The person following the SOP should not need to invent policy or make commitments outside their agreed authority to finish the task.
Ask someone else to follow the draft
Choose a reader with the background and access the SOP is written for. Use a suitable test case or an agreed live task, and ask them to work from the document. Resist explaining the missing details immediately. Note where they pause, misinterpret a step, use the wrong source or ask a question the procedure should answer.
Check the result as well as the reader’s experience. Did they produce the right output, save it in the right place and seek the necessary approval? Revise the instruction at the point where it failed. Adding a general warning at the end rarely fixes an unclear step near the beginning.
Publish one current version and give it an owner
Store the approved SOP where the intended readers can find it. Make the current version clear, keep superseded copies out of the normal working route and record what changed when a revision affects the task. A reader should not have to compare several similarly named files to discover which one to follow.
Assign someone to review questions and proposed changes. Revisit the SOP when the process, template, access or approval route changes, as well as at the review point you set. Keep feedback close to the work: a short note about a failed step is more useful than waiting for a complete rewrite. The procedure earns its place by remaining usable.
Put it to work.
- Define one task, its required inputs and its observable finish condition.
- Write action steps with decision rules, checks and clear stopping points.
- Test the draft with its intended reader and maintain one approved current version.
Could a little support make a difference?
Tell Anna about the task or process you would like help with. A clear starting point is enough for a first conversation.
Discuss your support
