SOP vs checklist: how to turn a procedure into the documents a field team uses.

An SOP, a standard operating procedure, describes how a job is done and why: the steps, the decisions, the exceptions and who owns them. It is the reference for training and for settling the unusual case. A job checklist is something else: a short list of the steps that must not be missed, used during the work to confirm they were done. Asking one document to do both produces a procedure too long to use on site and a checklist too thin to learn from.

The approach here treats the SOP as the single source and derives the working documents from it: the job checklist, the new-hire onboarding sheet and the customer handover sheet. Each is short, each is written for a particular reader at a particular moment, and each carries the SOP's version so it can be replaced when the procedure changes. Capturing the procedure in the first place is covered in how to document a business process before you automate it.

Each document is defined by who reads it and when. Get that right and most of the content decisions make themselves; get it wrong and the document is either ignored or used for something it was never written to do.

A checklist that repeats the whole procedure is a procedure in a smaller font, and it gets skipped for the same reason. Research on checklist design in aviation, where NASA's study of normal flight-deck checklists is a standard reference, treats length, format and the way checklists are actually used under time pressure as design problems in their own right. The service-business version is a filter: a step goes on the checklist only if missing it causes a real problem, it is easy to miss, and someone can tell afterwards whether it was done.

Hold points belong on it too. These are the moments where the right action is to stop: a condition the procedure does not cover, a reading outside the normal range, a customer request that changes the scope. A checklist that names its hold points turns "use your judgment" into "call the supervisor before continuing", which is an instruction a newer technician can actually follow.

Three tests for each candidate line:

• CRITICAL

  Would skipping it cause a callback, damage, a safety problem or a complaint?

• EASY TO MISS

  Is it the kind of step people forget when they are interrupted, rushed or doing the job for the fortieth time?

• CHECKABLE

  Could someone confirm afterwards that it was done, from a photo, a reading, a signature or something else observable?

Each line should start with a verb and describe a result someone can see: "Photograph the finished work from the street" rather than "Check the job". Put the lines in the order the work happens, keep the whole thing to a page, and leave the explanations in the SOP, where there is room for them.

Decide how it will be used. Some checklists are followed line by line as the work happens; others are run at pause points, before starting and before leaving, to confirm that nothing was missed. The World Health Organization's surgical safety checklist is a well-known example of the second kind, organized around three pauses in an operation rather than every step of it. For most field jobs, a start-of-job pause and an end-of-job pause catch more than a long list checked off on the move.

Consider the conditions as well: gloves, rain, a phone in a pocket. A checklist that is awkward to use in the conditions of the job will be filled in afterwards from memory, which is the failure it was meant to prevent.

An onboarding sheet answers a new hire's question, what do I need to learn and in what order, and a supervisor's question, how do I know they are ready. Derived from the SOP, it lists the parts to read first, the jobs to watch, the jobs to do under supervision, and the evidence that ends supervision.

Make sign-off a decision with criteria rather than a feeling. A short check on the SOP's key decisions, and a supervised job completed against the checklist and signed off by a named person, is enough for most service work. Where a trade requires a license or qualification for a task, the onboarding sheet records that requirement; it never substitutes for it.

A customer handover sheet is written for someone who was not watching. It says what was done, what to expect over the following days, any care instructions, and who to contact. It is also a document the customer may keep and produce later, so everything on it should be something the business is willing to be held to.

Care instructions and warranty terms come from the manufacturer's documentation and the business's own written terms, quoted rather than paraphrased. If a handover sheet is drafted with an AI, the AI is given those sources and told not to add anything; an AI asked to be helpful will otherwise produce plausible care advice that nobody approved.

The quickest way to find what a procedure and its checklist are missing is to watch someone without the knowledge try to use them. Ask a capable colleague from another role, or a new hire in their first week, to walk through the job with the SOP and the checklist, and write down every question they ask. Each question is a gap: a step assumed rather than written, a term nobody defined, a decision with no criteria.

An AI can do a rough version of the same test. Given the SOP and asked to act as a new technician, it will ask the kind of questions a newcomer might ask. It is a useful first pass, not a substitute, because it cannot tell you which questions a real person would never think to ask.

Where a step exists for safety, or because a regulation, an insurer or a manufacturer requires it, the SOP quotes the source and names it, and the checklist carries the step without rewording it into something shorter and different. This is the one place where the advice to write in your own words is wrong.

The same applies with more force to AI drafting. An assistant asked to add the safety steps will produce safety steps that are confident, generic and unverified. Tell it explicitly not to add any, and add them yourself from the source documents, checked by someone qualified to check them.

Derived documents drift apart quietly. The SOP is updated after a callback; the laminated checklist in the van is not. The defense is mechanical. Every derived document shows the SOP version and date it came from, a register lists each SOP with the documents derived from it, and a change to the SOP is not finished until those documents are updated and the old copies collected.

A register can be a spreadsheet. What matters is that someone owns it and that it is checked on a schedule, because a procedure nobody has looked at in a year describes how the work used to be done.

What a register row records:

• SOP AND OWNER

  The procedure's title and the person responsible for it.

• VERSION AND DATE

  The current version and when it was approved.

• NEXT CHECK

  When it will next be compared with how the work is actually done.

• DERIVED DOCUMENTS

  Each checklist, onboarding sheet and handover sheet made from it, with the version each one carries.

Aevrion Ops documents recurring operations as working procedures with businesses: observing the work, writing the SOPs and the documents derived from them, and setting up the register that keeps them current. Safety, licensing and employment requirements stay with the qualified people and sources that set them.

1. An SOP explains and a checklist confirms; asking one document to do both produces neither.
2. Derive the job checklist, the onboarding sheet and the customer handover sheet from one approved SOP.
3. Put a step on the checklist only if it is critical, easy to miss and checkable, and name the hold points.
4. Write checklists for the conditions of the job: verbs first, observable results, one page, clear pause points.
5. Make onboarding sign-off a decision with criteria and a named person.
6. Copy safety and regulated steps from their source, and never let an AI add them.
7. Version every derived document against the SOP and keep a register with an owner and a date for the next check.