Writing Restoration SOPs Your Techs Will Actually Follow

Open the back door of almost any restoration truck and you'll find the SOP binder. It's three inches thick, it has a coffee ring on the cover, and it's doing excellent work as a clipboard stand. Somebody gave up a lot of weekends to write it. As far as anyone can tell, it hasn't been opened since the day it was handed out.

Nobody on the crew is being lazy. The binder was written for a different reader. Most SOP binders are written to prove a process exists, and very few are built for someone standing on a ladder with a meter in one hand. Procedures your techs will actually use look different, and they're not hard to write.

Why the binder fails

Binders tend to fail for the same handful of reasons:

• It's too long. Nobody reads eighty pages in a truck between jobs.
• It's written as an essay. Paragraphs explain the philosophy of drying when the tech needs to know which readings to take.
• It mixes everything together. The vacation policy, the drying procedure, and the truck inspection share one binder, so none of them is easy to find.
• It's out of date. Once a tech catches the binder being wrong about one thing, they stop trusting it about anything.
• It describes the job you wish you had. It was written in an office, and it includes steps nobody has done in years.
• The real procedure lives somewhere else. Usually in your best tech's head, which works fine right up until that tech takes a week off.

One page per job stage

Organize your SOPs the way a job actually moves: first call, arrival and safety, inspection and documentation, setup, daily monitoring, demolition, equipment pickup and final readings, final walkthrough and closeout. Use the stages your company really runs, not a list borrowed from somewhere else.

Give each stage one page. When a stage won't fit, the page is usually trying to do the training's job too, and the explanations belong in a class, not on the checklist. The top of each page should answer when the stage starts, what "done" looks like, and who owns it.

A one-page format has a side benefit. It fits on a phone screen, which is where your techs are going to look anyway.

Write it as a checklist

Procedures people follow read like checklists, not manuals. A few rules help:

• Start every line with a verb. "Photograph the source," not "The source should be photographed."
• One action per line. A line with an "and" in it is often two lines.
• Separate the must-dos from the judgment calls. Some steps happen every time. Others depend on the job, like whether to flood cut a wall or dry it in place. For those, the SOP says how to decide and how to document the decision, not what to decide.
• Explain the steps people skip. One short line of "why" next to the step that always gets skipped does more than a page of reminders.

Here's what that can look like for a daily monitoring visit:

• Readings. Take readings at the same marked points as the last visit, plus the dry reference.
• Equipment. Confirm every unit is running, draining, and placed where the plan says.
• Photos. Photograph any reading that changed and anything that looks different from the last visit.
• The customer. Check in with the homeowner before you leave, and answer what you can.
• The plan. Note anything that changes the plan, and tell the project manager the same day.

Show what "done right" looks like

A photo settles arguments that a paragraph starts. For each stage, add a few pictures of the work done correctly: a finished containment, a labeled contents box, a meter photo with the reading and the material both in the frame, a cord run nobody will trip over.

Use photos from your own jobs, taken by your own crew. They show your equipment, your standards, and the kind of houses you actually work in. And the tech whose photo made it into the SOP will mention it, possibly more than once.

Write it with your senior techs

The quickest way to write an SOP nobody follows is to write it alone. Your senior techs know which steps really happen on a job, which shortcuts are harmless, and which ones cause trouble a week later.

• Ask a senior tech to walk you through a stage on a real job while you write down what they actually do.
• Ask what new techs get wrong most often. Those answers become your "why" lines.
• Hand them the draft and ask what's missing or wrong. Brace for "nobody does that," and take it seriously. Either the step matters and needs a reason, or it doesn't and should go.
• Put their name on it. A tech who helped write a procedure tends to defend it on the job.

One source of truth

Two versions of an SOP can be worse than none, because each tech follows whichever one they saw last. Keep one current version in one place your crew can reach from the field, with a date at the top and a line about what changed. Retire the old copies, including the printed ones taped inside truck doors. Give each stage page an owner who is responsible for keeping it current.

Review on a schedule, and retire what nobody does

An SOP is accurate on the day it's written and starts aging the next morning. Put a review on the calendar, such as once a quarter, and treat it like any other appointment.

At each review, look for three things:

• Steps nobody does. Decide whether each one matters. If it does, explain why and hold people to it. If it doesn't, delete it. A procedure full of ignored steps teaches people to ignore procedures.
• Mistakes the SOP didn't cover. When a job goes wrong, ask whether a step was missing or simply skipped. Your weekly WIP meeting is a good place to spot the pattern, since the same kind of stuck job turning up week after week usually points to the same missing step.
• Changes in how you work. New equipment, new forms, new requests from the people who send you work. If you start collecting the certificate of completion at the final walkthrough, for example, that belongs on the closeout page.

If you run your company on a weekly scorecard and quarterly priorities, as our post on a business operating system describes, the SOP review fits naturally into that rhythm.

Putting the checklist inside the job

An SOP works best when it shows up at the moment it's needed, inside the job, instead of in a binder behind the seat. In riivet, custom workflows hold your own job stages, checklists, and approvals, so each stage's checklist travels with the job, every tech works the same process, and the steps that need a manager's approval get one. You can see how that looks in a demo, or read more on the features page.

Start with one page

You don't need to rewrite the whole binder this month. Pick the stage where jobs go wrong most often, sit down with your best tech, and write one page: a checklist, a few photos, an owner, and a date. Use it for a few weeks, fix what's wrong with it, then write the next one.

• One page per job stage, written as a checklist.
• Photos of the work done right, from your own jobs.
• Senior techs as co-authors from the first draft.
• One current version, reachable from the field.
• A review on the calendar, and the nerve to delete steps nobody does.

As for the binder, give it a dignified retirement. The clipboard will find another stand.