How to create SOP templates that survive the first handover

An SOP set earns its place one handover at a time. Follow an incoming invoice from task selection through observation, drafting, testing, release, and review. The worked case shows how to decide whether the task merits a procedure, whether its know-how can be recorded, and whether another person can finish it unaided.

A handover is scheduled for an incoming invoice

Use incoming-invoice routing as the worked case. Before drafting, ask whether mistakes have consequences, whether people who do the work perform it rarely, and whether one person's knowledge carries the task. A strong score on any one test makes it a candidate for early documentation.

Ask people to name work they perform that another person could reasonably take over. Keep each task description in the words people use at work, rather than turning it into job-description language. The aim is to uncover actual tasks, not to produce a polished inventory that hides how the work is done.

Tasks that score low on all three tests can wait. Documenting the entire operation can bury useful procedures, so rank candidates by priority rather than treating a complete inventory as the goal. State plainly why lower-priority work is deferred, and start with serious consequences, infrequent performers, or know-how held by one person.

The person doing the work narrates each decision

Once invoice routing is selected, observe the person who performs it and have them narrate the task as the work happens.

Capture the real sequence, awkward parts included, instead of polishing it into an ideal process. Write down what the person actually does, not what a writer expects the process to be.

Keep the conversation on decisions that belong in writing. Ask what makes the doer stop, what they check before starting, and when the task has gone wrong. The answers shape stop rules, prerequisites, and exceptions, surfacing information that might otherwise stay unspoken.

Write the procedure on the day of the narration, while observations are fresh. Let the doer supply the content and another person write it down. A week's delay risks replacing what happened with what the writer assumes; daily performers can stop noticing details a newcomer needs.

One invoice draft takes the shared shape

With the narration captured, agree on a shared page structure before filling in the invoice instructions. A house template teaches readers one arrangement across the set and prevents individual procedures from acquiring competing layouts by accident, without reopening design decisions at every draft.

The U.S. Environmental Protection Agency's quality management tools distinguish the controlling structure from individual procedures. Set the shared structure once across the collection, then add procedure-specific content. This keeps layout decisions out of each draft and leaves the invoice instructions to reflect the actual task.

Filled example: routing an incoming invoice (adapt the details to your own policy):

The newcomer tests the route without coaching

Give the invoice draft to someone who has never performed the task. Observe without coaching and note every hesitation, question, or deviation; the test assesses the document, not the tester. Watching the task matters because reading a procedure does not establish that it works unaided.

During the invoice run, compare observed behavior with the written sequence. A different order usually means the sequence is wrong; a step skipped without affecting the result is usually unnecessary. Record either pattern as a finding about the document, rather than as an error by the person testing it.

Use a copyable Handover test record to keep the results usable for revision and the next handover. Include the procedure name and version, tester, task attempted, pauses or questions, missed or reordered steps, outcome, corrections, retest outcome, and owner sign-off. The record keeps each observation connected to the document change it prompts.

For the invoice route, correct a reordered sequence or remove a skipped step only when it has no effect, then repeat the test. Mark Pass only if the newcomer finishes without coaching, follows the relevant stop rule, and creates the required record. Otherwise mark Revise, correct the document, and test it again.

An hour of observation finds more than a week of review. Aviation and clinical procedure work is validated through observed performance rather than reading alone. Published guidance behind the WHO surgical safety checklist describes a comparable cycle: draft, watch real use, and cut unnecessary material.

The approved copy lands in one known place

A successful observed run does not finish the invoice handover. Release the procedure only when the newcomer completes the task unaided, follows the applicable stop rule, and creates the required record. If any condition is missing, revise the instructions and repeat the test before publication.

Give the released procedure an owner, a single plain home, and a date showing when it was last performed against the document. Without these controls, instructions can start decaying immediately, with nobody positioned to notice the change or take responsibility for correcting it.

Choose one findable location, named so a new starter can locate it without asking. Use one place per team. Multiple copies can leave teams using different versions, so do not circulate alternatives to the canonical procedure.

For a small team, keep the master as a shared Google Docs document or Microsoft Word file in the team's existing shared storage, and name one canonical location. If the task needs confirmation rather than instruction, choose the shorter operational checklists form and its template instead of an SOP.

Rules for the rest of the procedure set

For work beyond invoice routing, use changes in the work to prompt review instead of relying on a calendar date alone. A system or supplier change, incident, newcomer struggling, or correction can mean the written method no longer matches the task and should be checked.

Keep one annual sweep as a backstop, but let these triggers do most of the work. Each connects review to a change, incident, struggle, or correction that gives the owner a reason to check whether the written instructions still match the task.

Once procedures cover the high-priority tasks and each deferred task has a note explaining why it waits, the set is complete for now. Publish that list: it explains missing coverage for a particular task and prevents expansion from burying the useful work.

A familiar failure is producing eleven documents in three weeks and then never reviewing them. Six maintained procedures outperform forty that were accurate only in the month they were written. For most small teams, the right set is a single-figure number of high-priority procedures, not a shelf of fiction.

After the queue is covered, maintain rather than expand by default. Verify procedures through performance, log changes, and retire documents for tasks that no longer exist. Approve only changes that alter what the task achieves or who is accountable. Requiring approval for a typo guarantees the typo remains, so reserve formal approval gates for procedures that truly need them.

When a task changes every few months, document its stable part and reference the changing part instead of embedding it. If nothing is stable, the task needs a trained person, not a document. Stop expanding when priority work is covered and deferred tasks have a stated reason.