A procedure is not finished when someone documents the steps. It is finished enough to rely on when another qualified person can use it, reach the intended outcome, and recognize when to stop. Testing an SOP with a backup operator exposes knowledge that the author uses without noticing.
Choose a bounded task
Start with a recurring task that has a clear beginning and end, such as preparing a routine customer report or reconciling a standard intake queue. Avoid using a high-consequence live event as the first test. Use a training record or supervised environment where appropriate.
Give the backup person the procedure and ordinary access. The author observes but does not narrate. If the author explains a missing step verbally, record that intervention. Otherwise the test can look successful only because the undocumented expert remains in the room.
Observe four kinds of failure
- Access: the operator cannot open a system, locate a file, or use the required permission.
- Sequence: a step depends on work that the document never requested.
- Judgment: the instruction says “review for accuracy” without defining the checks or tolerance.
- Completion: the operator cannot tell whether the output has been accepted or who owns the next step.
Record elapsed time, pauses, questions, rework, and the final output. Distinguish a training need from a documentation defect. A new operator may need foundational skills that do not belong inside every individual procedure.
Replace vague verbs with observable checks
Consider “send the completed customer report.” A usable version identifies the report template, required period, source data, reconciliation check, recipient, delivery location, and evidence of delivery. It also states what to do when a source total differs from the report.
Do not solve ambiguity by making the document longer without purpose. Put rare exceptions in a separate reference and keep the normal path easy to follow. Link to one maintained source for system access instructions rather than copying stale instructions into every SOP.
Define passing evidence
Before testing, specify what an acceptable result looks like. For a routine report, that might mean the correct period, reconciled totals, appropriate recipient, and an audit trail. Set the criteria before seeing the output so the team does not lower the standard to declare success.
In a fictional test, a backup operator completes a report in 35 minutes but sends an old version because the storage folder contains three similarly named files. The fix may be version control and a single source folder, not faster typing or more training.
Retest the changed parts
Update the SOP, identify the owner and review date, and repeat the failed portion with the backup person. Keep a short test log. Revisit the procedure when systems, roles, or customer requirements change; a calendar review alone cannot catch every operational change.
Use the resource library for companion documentation tools, and retain the backup-person test as evidence that a procedure works in practice.
Download the working checklist
Download the how to test whether an sop works without its author worksheet (CSV). Fill it with verified information; blank cells identify work still to be done.