Write a standard operating procedure your team will actually use

Open a procedure for a job your team does regularly. Find the first instruction that says “check,” “process” or “handle.” Does it tell a colleague what to inspect, where to find it and what to do when the result is wrong?

If it does, you have a useful instruction. If it doesn't, the author may still be needed to explain the procedure every time.

A standard operating procedure, or SOP, is a set of instructions for a recurring activity. For a small team, it should answer four practical questions: when to use it, how to do the work, when to stop and what completion looks like. Here is how to write one without starting a documentation department.

Choose a procedure that earns its place

Start with a repeat task that produces questions, inconsistencies or handover problems. Preparing a room booking, checking a weekly order or setting up a new project folder can each be a sensible size.

Avoid beginning with “how we run operations.” That is several procedures wearing one title.

Choose the kind of help the reader actually needs. An experienced person doing a familiar task may need a short checklist to catch omissions. Someone covering an unfamiliar task needs the steps, inputs and decision points. A rare problem with several possible causes may need a troubleshooting guide. Calling all three an SOP does not make the same format useful for all three.

For a mixed audience, put the ordinary sequence first and link to the detail that occasional users need. Explain “compare the requested arrival date with the confirmed workshop date” in the main instruction; put the guide to finding the workshop schedule beside it. This keeps the repeat user moving without abandoning the backup colleague.

Choose a person who performs the task to draft it. Ask them to show a recent ordinary example and one that needed judgment. Record the details they check automatically: which source is current, what a field means, how they recognize a duplicate and whom they ask when something does not fit.

The EPA's 2007 SOP-writing guidance recommends concise, unambiguous instructions and testing a draft with someone other than its writer. Its setting is an environmental quality system; those writing principles are useful here without adopting its specialist format or requirements.

Write the boundary before the steps

At the top, put the task's purpose, the event that starts it and the point where it ends. State the access or knowledge a person needs before beginning.

This matters particularly at an approval boundary. Preparing a purchase request is a different responsibility from authorizing a purchase. The procedure should make that visible where the decision occurs.

Keep the current procedure in one accessible place. Include the responsible role, version, last review date and a route for suggesting a correction. A screenshot can help someone recognize the right screen, but the instruction must still say what they are trying to accomplish when the interface changes.

Write one sentence about what the procedure excludes. For the example below: “This procedure prepares a supplies request; it does not approve purchases or substitute items.” That sentence will help you decide which details belong in the steps and where to link a separate process.

If the team cannot agree how the work should be done, record the unresolved decision before polishing the document. “Which stock count should we trust?” is a process question. Formatting the answer as a numbered list cannot settle it. Use the workflow triage guide when the job itself needs simplifying first.

A short SOP, worked through

The business and procedure below are fictional. A small training company collects stationery requests for its upcoming workshops. The coordinator prepares an order request; the operations lead approves any purchase.

Procedure: Prepare the weekly workshop supplies request
Owner: Operations coordinator
Version: 1.0, reviewed 8 September 2026
Use when: Preparing the next week's confirmed workshops.
Finish: One checked replenishment request is ready for the operations lead.
You need: Access to the confirmed workshop schedule, current supplies count and approved item list.

1. Confirm the scope. Open the workshop schedule and list the confirmed sessions for the following week. Keep provisional sessions separate and identify who will confirm them. Do not silently count them as confirmed demand.

2. Calculate the requirement. For each item, record the quantity needed, usable stock available and shortfall. Use the units in the approved item list. “One box” and “one pen” must not share a quantity column without explanation.

3. Check for an existing order. Look for open requests covering the same items and workshop dates. Link an existing request rather than creating another one. If it is unclear whether a delivery is included in the stock count, ask the stock-count owner before subtracting it twice.

4. Prepare the request. Include item, unit, quantity, required arrival date and workshop reference. Link the schedule and stock count used. Record provisional demand as a separate open question.

5. Handle exceptions. If an item is unavailable, its unit is unclear or the request falls outside the approved list, identify the affected line and refer it to the operations lead. Keep the rest of the request available for review. Do not substitute an item or place an order under this procedure.

6. Check and hand over. Recheck units, dates and duplicate requests. Mark the request “Ready for approval” and name the approving person. Completion means the checked request has been handed over; it does not mean a purchase is approved.

For example, a fictional workshop needs 24 pens and has 10 usable pens in stock. The request is for 14 individual pens. If the supplier sells boxes of 12, the purchase quantity and any surplus need a separate decision by the approver. That small detail is exactly the kind of knowledge an apparently simple procedure can lose.

Put the decision where the reader encounters it

The ordinary arithmetic above is 24 − 10 = 14. Now introduce an open delivery of 12 pens. The coordinator needs to establish whether it will arrive before the workshop. A separate available-stock report might already show 22 because it includes that delivery; a physical count still shows 10. The procedure needs to explain which figure is being used.

This remains a fictional example. Its purpose is to show what “check stock” leaves out: which quantity is being compared, whether future stock counts and where uncertainty goes. The procedure should put that explanation beside the stock calculation, where somebody will need it.

Use the same pattern elsewhere: look at this evidence; apply this rule; take this action; stop here if the evidence is missing. For booking a room, the evidence might be the confirmed attendee count and available layout. For setting up a project, it might be an accepted brief and the correct client workspace. The details change; the need to make the decision observable remains.

Test it without narrating the missing steps

Give the draft and a safe example to a colleague with the expected background and permissions. Ask them to work through it while you observe.

When they hesitate, note the instruction involved. If you explain the missing detail verbally, put that explanation into the next draft. Also note places where the document spends a paragraph explaining something the reader already understands.

Test the exception as well as the routine case. Can the reader identify where to stop, whom to contact and what information to pass on? A procedure that works only when nothing goes wrong leaves its hardest job unfinished.

Keep a small observation log. The entries below are hypothetical examples of what a test might reveal; they are not results of a test we performed.

Run the revised steps again for the affected cases. A successful retest means the intended reader reaches the correct handoff with the expected evidence and handles the exception correctly. Speed is useful to observe, but finishing quickly with the wrong quantity is not a pass.

Ask the reader one last question: “What would you do if this link stopped working?” The answer should lead to the procedure owner or an approved alternative source. It should not depend on guessing which exported spreadsheet looks newest.

For specialist or safety-critical work, use the qualified people and controls that work requires. This office-work example is not a substitute for technical training.

Keep revisions understandable

Name the current document clearly and avoid circulating detached copies as the normal reference. When a step changes, record what changed and tell the people using it.

Google Docs version history lets editors inspect earlier versions and name versions. SharePoint libraries with versioning enabled also support tracking and restoring file versions. Use the history available in your existing tools, and keep an obvious current-version label for anyone reading an export or printout.

Review after a meaningful process change or a recurring point of confusion. A date changed at the top of an unread document is not much of a review.

Keep the change note brief and useful: “Version 1.1: added the check for incoming deliveries to prevent double counting; stock-count owner confirms uncertain lines.” Link the earlier version through the document history where possible. Someone who already knows the task needs to spot the changed instruction without rereading every paragraph.

Move repeated corrections into the procedure, then remove obsolete workarounds. If every meeting produces an action to explain the same stock rule, the action register is telling you where the SOP needs attention. Include the procedure and its source links in a software handover, so the document remains accessible when its author leaves.

The small-team SOP template gives you the structure to fill in. Choose one task, write the decision points and watch a colleague try it. Their first unanswered question is the best place to improve the draft.