How to Test Whether Someone Can Follow Your SOP

Test a narrow task with a beginning and an output that another person can recognize. Write down which inputs the tester receives, what the procedure is supposed to produce, and which decisions are outside the tester's authority. For the fictional restock task, the input is a dated count sheet and a supplier list, while the output is a draft request for a manager to review.

Decide what counts as a successful run before anyone starts. The tester should use the information in the SOP, complete the ordinary path, and stop or ask for help when a required input is absent. This prevents the reviewer from changing the standard after seeing what the tester did.

Give the tester the version of the SOP that you intend to use, along with the normal forms, references, or equipment the procedure says they need. Record the version and date so later feedback can be tied to the exact instructions. Avoid adding verbal hints that are missing from the written procedure, because those hints can conceal a gap in the document.

Include one ordinary case and at least one exception that the SOP claims to handle. A restock sheet can include a known pack size in the ordinary case and omit that detail in the exception case. Do not make the task difficult for its own sake; the input should resemble the conditions the process owner expects in real work.

Ask the tester to work from the SOP and say when they cannot determine the next action. Note the step where they pause, which instruction they consulted, and what output they produced. If they guess, record the assumption and the step that allowed it. A facilitator who answers every question may help finish the task, but the test will no longer show whether the written procedure was sufficient.

Keep the review focused on the procedure, not on judging the person. Ask what wording or missing reference caused confusion, then compare the result with your agreed criteria. The goal is to find where the instructions fail to guide the task, not to turn one person's first attempt into a general claim about staff performance.

Three fictional scenarios test the normal path and two exceptions.

• Scenario: Normal restock; Input condition: Count sheet and pack sizes are present; Expected behavior: Prepare a draft list for manager review; Observed fictional result: Tester produced the list and linked the count sheet
• Scenario: Missing pack size; Input condition: One item has no supplier pack size; Expected behavior: Stop and ask the named manager; Observed fictional result: Tester guessed a quantity, so the stop instruction needs emphasis
• Scenario: Conflicting count; Input condition: Two count sheets show different totals; Expected behavior: Retain both references and request a decision; Observed fictional result: Tester found no exception path and paused at step four

A procedure can work with complete inputs and still fail when an item is missing, a reference conflicts, or the responsible person is unavailable. Pick exceptions that have a plausible effect on the task and decide what the tester should do when they appear. The correct outcome may be to stop and escalate rather than to complete the process.

Record whether the tester noticed the exception, knew where to route it, and avoided inventing a value. If a test case exposes a missing decision, return it to the process owner. Do not ask the tester to resolve policy or business choices that the SOP does not grant them authority to make.

Use observations to make a specific edit, such as adding an example input, naming the owner of an exception, or explaining what output to save. Record the revised version and keep the original result attached to the earlier version. A retest should check that the changed instruction now works and that it has not made another step ambiguous.

A successful run tells you what happened in that scenario. If the procedure varies by location, job type or system, choose additional representative cases with its owner and consider the consequences of an error.

The CSV records the SOP version, scenario, expected behavior, observed result, and next revision. In the fictional example, the second tester guessed a pack size, so the next draft should say to stop and ask the manager. The third tester paused on conflicting counts, which signals that the exception path or its owner is absent from the procedure.

SweetProcess provides SOP examples and describes elements such as steps and responsibilities. Those templates do not prove that a particular procedure can be followed. Your observed test results are the evidence for the document you are revising.

Ask Areinum Assistant to organise the procedure version, test inputs and observations into a review log. The process owner sets the expected result, observes the test and decides what to revise.