Writing an SOP a Tech Will Actually Follow

Why this matters

An SOP that sits in a binder and never gets opened isn't a standard, it's a formality. Most shops write standard operating procedures once, during a burst of good intentions, in language that reads more like a compliance document than something a tech would actually pull up mid-job. If the procedure is too long, too vague, or written for an auditor instead of a technician standing at the truck, it gets skipped, and every tech ends up doing the job their own way again, which is exactly what the SOP was supposed to prevent.

Step 1: Write it for the moment it will actually be read

An SOP gets opened in one of two moments: a tech doing something unfamiliar for the first time, or a tech double-checking a step they don't do often. In both cases, they're standing at the job, phone or tablet in hand, wanting an answer fast. Write for that moment, not for a training classroom. Short, numbered steps beat paragraphs every time, because a paragraph makes the reader hunt for the specific step they need.

Step 2: Start with when to use it, not what it is

Open every SOP with a one- or two-sentence trigger: the exact situation that means "use this procedure now." Not a description of the procedure's purpose in the abstract, the specific condition that should make a tech pull it up.

• Weak: "This procedure describes the process for handling a customer complaint about pricing."
• Clear trigger: "Use this procedure any time a customer questions or disputes a price, in person or by phone, before or after the work is done."

A clear trigger is what makes a tech think to open the document at all. Without it, a tech has to already know the SOP exists and remember its title, which rarely happens under pressure.

Step 3: Write steps as actions, not descriptions

Every step should be something a tech does, starting with a verb, not a description of a process. Compare:

• Descriptive (harder to follow): "The technician should ensure that the customer is made aware of the estimated cost prior to beginning work."
• Action step (easy to follow): "Tell the customer the estimated cost before starting work. Get a verbal or written yes before proceeding."

Action steps are also easier to check off. A tech scanning a numbered list under pressure needs to know exactly what to do next, not interpret a description of a policy.

Step 4: Keep each step to one action

A step that bundles three actions into one sentence ("inspect the unit, document any pre-existing damage, and inform the customer of your findings before beginning work") is really three steps pretending to be one, and it's easy to do only part of it and think you're done. Split it:

1. Inspect the unit for pre-existing damage.
2. Document anything found, with a photo if possible.
3. Tell the customer what you found before starting work.

Splitting steps this way also makes gaps obvious. If step 2 got skipped on a real job, it's clear which specific step failed, instead of a vague sense that "the process wasn't followed."

Step 5: Name the exception path, briefly

Nearly every real-world procedure has a common edge case, and an SOP that doesn't address it forces the tech to guess or call the office every time it comes up. Add a short "if this happens" note right after the relevant step, not buried in a separate section:

"3. Tell the customer what you found before starting work. If the customer is not present or reachable, take photos, do not proceed with anything beyond the original scope, and note it in the job record for the office to follow up."

Handling the exception in the same place as the rule (see the general rule about hedging exceptions where the rule lives) keeps a tech from having to search the whole document for the edge case they're actually facing.

Step 6: Test it on someone who didn't write it

The best test of an SOP is handing it to a tech who wasn't involved in writing it and watching them try to follow it cold, ideally on a real or simulated version of the task. Every place they hesitate, ask a question, or do something differently than intended is a gap in the document, not a gap in the tech. Revise based on what actually confused them, not what you assume should be clear.

Step 7: Keep it short enough to actually finish reading

If an SOP runs several pages for a routine task, most techs will skim it once, never fully read it again, and eventually stop opening it at all. Aim for something that fits on one screen without much scrolling for common procedures. If a procedure genuinely needs more length, split it into a short "quick steps" version up top and a fuller reference below, so the tech who just needs a reminder isn't forced through the whole document every time.

References

• See related: Writing an Employee Handbook in Plain English
• See related: The Service Report That Actually Gets Read
• Trade-standard practice for standard operating procedures and field documentation