Picture the person you actually wrote the procedure for. They are standing in a mechanical room with one bar of signal, a phone in a gloved hand, and a customer upstairs asking how much longer this is going to take. They have about eight seconds and one thumb. That is the reading environment for a field SOP, and very few procedures are written for it.
The binder is where SOPs go to die
Most SOPs are written at a desk, for a desk. Purpose. Scope. Responsibilities. Three paragraphs of background before the first actual instruction. Numbered sections. A PDF that opens to page one and expects you to read to page 14. That format made sense when the reference copy lived in a binder on a shelf and somebody sat down to study it on a slow afternoon.
Slow afternoons are rare in a service business, and the binder is now a phone. The tech pulls the SOP up on the job, one-handed, in bright sun, mid-task, while the meter is running. If the procedure does not give up its answer in the first screen, they close it and do what they did last time, or text the person who trained them. Either way the documented method just lost to memory, and getting the business off memory was the entire point of writing it down.
What follows is the list of habits to unlearn once you stop judging a procedure in a review meeting and start watching someone try to use it on a roof.
Write the step, not the essay
The unit a crew actually uses is a single step: one verb, one action, one line. Not a paragraph with a step buried somewhere inside it. Here is the kind of thing that ends up in a binder.
"Before energizing the unit, it is important to ensure that all electrical connections have been properly torqued to specification and that the correct refrigerant charge has been verified, since failure to do either is a common cause of premature compressor failure and avoidable callbacks."
Now the version a technician can run from a phone held at arm's length:
- Torque all electrical lugs to the nameplate spec.
- Verify the refrigerant charge against the chart.
- Then energize.
- Why: loose lugs and the wrong charge are our top two compressor callbacks.
Same information, 60 fewer words to fight through, and every line is a thing you can do rather than a thing you have to decode while standing up. Every SOP you own is one of these two shapes. A few rules force the shorter one:
- Start every step with a verb: torque, verify, photograph, log, call.
- One action per line. If a line has an "and" in the middle, it is two steps.
- Give the "why" its own short line, so it can be read or skipped without breaking the flow.
- Cut the throat-clearing. "It is important to ensure that" is four words hiding a single instruction.
Put the answer where the thumb lands
On a phone, the reader is almost never reading for comprehension. They are hunting for one thing: a number, a spec, a decision. Which markup tier. What torque value. Which valve to close first. Whether this counts as a change order. That answer is usually stranded in the third paragraph, because we write in the order we think rather than the order they need.
Front-load it. The decision or the spec goes at the top, in bold if your tool allows it, before any context. Context is there for the people who want it. The answer is there for the 90% who just need to keep moving.
Decisions especially need the if-then made explicit. "Use judgment on borderline jobs" reads like a procedure but works like a wish. A roofer on a tear-off needs a line they can act on from the ladder, not a philosophy of borderline jobs: if you find more than two layers, stop and call the estimator before you pull another square. "Use judgment" leaves them guessing. The if-then does the deciding for them.
A photo settles what a paragraph argues
The fastest SOP in the trades is often not written at all. It is a photo of the right way beside a photo of the wrong way, or a 20-second clip shot on a phone.
A restoration tech setting air movers does not want 200 words on spacing and angle. They want one photo of a correctly dried-in room with the movers circled. An electrician landing a panel wants a picture of a clean, labelled, properly dressed board, because "dress the conductors neatly" means five different things to five people and a photo means one. A fibre splicer wants the reference tray, not a description of the reference tray.
Shoot these on the job while the work is happening. Your best techs are producing the reference material every single day, you are just not capturing it. A phone photo with two lines of caption will out-teach a page of careful prose, and it costs you 30 seconds instead of an afternoon at the keyboard. This is codifying in the most literal sense: taking the thing your best person knows and fixing it in a form the next person can actually use.
One job, one SOP, one screen
The instinct is to write the big document. "Service Call Procedure," everything from parking the van to collecting payment, 14 pages of it. Crews rarely read the big document. They need the two paragraphs about the one thing they are stuck on right now, and the big document buries those two paragraphs under 12 pages they did not ask for.
Scope each SOP to a single job or decision that fits a thumb-scroll. "How to handle a no-heat call after hours." "What to photograph before demolition." "When a scope change becomes a change order." Small, single-purpose, findable.
Then name them the way a stuck person would search, not the way you would file them. Your tech at 7 p.m. types "no heat" into the search bar, not "Emergency HVAC Service Delivery Standard, Rev 3." The title is the front door. If you write the title for the filing cabinet, you have locked the door. That is the writing side of a problem I dug into separately in why your team isn't following the SOPs, which is worth reading alongside this one.
The test that tells you if it works
You cannot judge a field SOP from your desk, because your desk is the one place it will never be read. There is one honest test and it takes about 15 minutes.
Hand the SOP to the newest person on the team. Give them the phone, not a printout, and the actual job. Then stand back and stay quiet. Watch where they slow down, re-read, pinch to zoom, or turn around to ask you something. Every one of those moments points to a gap in the document, and the person is fine. The question they asked is the line you forgot to write.
As you watch, note four things:
- Where did they scroll past the answer because it was buried?
- Where did a step assume knowledge they did not have yet?
- Where did they reach for a photo that was not there?
- Where did "use judgment" leave them stranded?
Fix those, then run it again with the next new hire. Two or three rounds of this and you have a procedure that survives contact with the field, which is the only kind worth owning. A library of documents that pass the desk test and fail the thumb test is just a nicer-looking binder.
For many owners, the SOP problem is a translation problem: real operational knowledge sitting in the heads of their best people, written down (if at all) in a format built for a shelf instead of a screen. Turning that knowledge into procedures the field will actually use, on the phone, mid-job, one-handed, is the work we call Codified Operational Intelligence™. Before you rewrite a single document, it helps to see how much of your operation still lives only in someone's memory.