Are your processes ready for SOPs?

Start with the actual work

Compare recent cases and identify where the route is stable and where judgement varies.

Look for a method that people can agree on

Start with a recurring process whose trigger, outcome and usual route can be described by the people doing it. Compare recent cases. Which steps repeat, and which differences reflect legitimate customer needs or unresolved disagreements?

A useful SOP records the current authorised method and its boundaries. If two experienced operators disagree about what should happen, name the process owner who can resolve the difference. Writing both opinions into a longer document does not establish a workable standard.

Distinguish normal variation from instability

A repeat order may have a predictable route while bespoke work requires judgement. You can document the stable parts and identify when a case leaves that route. Do not imply that one set of instructions covers exceptions it has never been tested against.

Ask whether recent changes were deliberate improvements, temporary workarounds or reactions to missing information. A process changing every week may need clearer inputs or authority before detailed documentation. Keep a record of the unresolved questions and who must decide them.

Prepare the information a different operator needs

Record the trigger, required inputs, permissions, steps, quality checks, exception route and evidence of completion. Say where the current source information is found. Avoid embedding passwords or unnecessary customer and employee data in the document.

Make judgement visible. An instruction to check the order is incomplete if the operator cannot tell which fields matter, what acceptable looks like and what to do when information is missing. Refer to the appropriate specialist procedure where the task requires one; a general SOP must not replace it.

Test use before calling it complete

Ask a suitable, authorised person other than the usual operator to explain or perform an appropriate case using the draft. Observe where they need clarification. Use a safe rehearsal where live work would introduce unacceptable risk; documentation is not permission to perform a restricted task.

Revise the draft, obtain the relevant approval and give it an owner, version and review route. Record what was tested and which exceptions remain outside scope. The free SOP Readiness Review helps prioritise this preparation; it does not certify a procedure or guarantee that an operator is competent.

What the example does not establish

A documented unstable process may preserve the wrong method.

Look for a case that challenges your first explanation as well as one that supports it. Agree which part of the situation is observed, which is an assumption and which needs another person’s evidence. Keep any proposed change within the authority and commitments already in place.

How do you know whether a change helped?

Record the starting condition and a suitable review point before the change. Compare real cases with similar constraints, including exceptions and any extra work created elsewhere. Separate a prepared document, an implemented change and a tested operating result. If the evidence is incomplete, name the gap rather than treating it as success.