Walk into almost any small business that has tried to document its processes and you'll find the same artifact: a folder on someone's drive with a dozen Word documents, the most recent of them eighteen months old, none of them open right now on anyone's screen. Standard operating procedures, written with the best intentions, used by no one.
The problem is rarely the willingness to write things down. It's the format. SOPs written like Word documents (introductions, sections, paragraphs, page numbers) feel like reading a textbook to a technician trying to remember how to handle a specific situation in the field. They are too long, too prose-heavy, and too cumbersome to update when the actual process changes, which it does, constantly, in a real business.
Why most SOPs fail.
Three failure modes account for almost all of them:
They're written for the wrong reader. SOPs that read like they were written for an auditor or a new hire who's never done this work make the assumption that the reader has unlimited time and reads carefully. The actual reader is a tech in a truck with thirty seconds and a phone screen. The format has to match.
They're stale. A process changes. The SOP doesn't get updated. Within six months, the document and the actual practice are different, the team learns to trust the practice over the document, and the document loses authority. Once that's happened, it never recovers.
They cover the wrong things. SOPs for routine, obvious work that everyone already knows how to do. No SOP for the rare edge case where the cost of doing it wrong is high. The document set is comprehensive in the wrong direction.
The three formats that work.
Different kinds of process need different kinds of documentation. Using the wrong format for the kind of process is the most common mistake.
A numbered list of steps, in order, each one a single action. Used for any task where the steps happen in sequence and the same way every time. The format is famous in aviation for a reason. It works under pressure.
- Call customer 15 min before arrival
- Confirm truck has correct parts for job type
- Park where directed; if unclear, ring bell first
- Boot covers on before entering home
- Greet by name, confirm scope of work
- Photo of work area before starting (in app)
A short "if this, then that" structure for situations where the right answer depends on conditions. Used for any process that involves the tech deciding between two or three responses based on what they see.
- If repeat customer (3+ jobs in last 12 months) and discount ≤ 10%: approve.
- If new customer: politely decline. Offer the maintenance plan instead (which has its own price).
- If request > 10% or escalated: escalate to office, do not commit in the moment.
A one-page sheet of facts that doesn't change often but is too much to memorize. Pricing reference cards, supplier contact lists, standard upsell scripts, warranty terms. Lives on a phone or a clipboard, not in a binder.
- Water heater 10+ years old → mention replacement quote (no pressure)
- Sump pump with no backup → mention battery backup option ($XYZ)
- Toilet flapper replaced → mention shut-off valve check ($ABC)
- Service plan eligible (residential, no current plan) → always mention
Where to start: the ten highest-leverage processes.
Don't try to document everything. The Pareto pattern is real. About ten processes drive most of the operational consistency in a trades business. Document those, leave the rest to judgement until they start causing problems.
- How we answer the phone (script + qualifying questions for the office)
- How we schedule a job (priority rules, lead times, slot allocation)
- The pre-arrival checklist (what every tech does before knocking)
- How we quote (pricing reference + judgement triggers)
- How we close out a job (sign-off, payment, photos, review ask)
- How we handle complaints (decision tree for refunds, redos, escalations)
- How we follow up on quotes (cadence + script for the office)
- How we collect overdue receivables (the sequence of calls and letters)
- How we onboard a new tech (the 30/60/90 plan)
- How we run the weekly numbers review (the format + the participants)
That's it. Ten processes. Each one fits on one page. The set is small enough that someone can actually read them all, current enough that they get updated, and visible enough that they get followed.
Keeping them current.
SOPs that aren't maintained die fast. The maintenance discipline is the part most shops skip and then wonder why the documentation broke down. Three rules keep them alive:
One owner per SOP. Every document has one person whose job includes keeping it accurate. The dispatcher owns the scheduling SOP. The lead tech owns the pre-arrival checklist. The bookkeeper owns the collections sequence. When something changes, that person updates the document. No owner means no updates.
Quarterly review. Once a quarter, fifteen minutes per SOP, the owner reads it and asks: is this still how we actually do it? Most of the time no changes are needed. When changes are needed they're usually small. The quarterly cadence catches drift before it becomes contradiction.
Update at the moment of change. When you decide in a meeting that "from now on, we do X this way," update the SOP that day. Not next week, not when there's time. That day. The discipline matters more than the elegance of the update.
Where they live matters too.
An SOP in a shared drive that nobody has bookmarked is functionally invisible. The format has to match where the user actually is. The pre-arrival checklist belongs in the field service app on the technician's phone, not a Word doc on a server. The pricing reference belongs as a laminated card in the truck and a PDF on the phone. The collections sequence belongs in the CRM as a workflow, not in a separate document.
Better to have a five-step checklist embedded where the work happens than a thirty-step SOP perfectly written and never seen.
Document one process.
- Today: pick the single process where inconsistency costs you the most. (Most shops: how techs close out a job.)
- Tomorrow: write it as a checklist. No paragraphs. Ten steps maximum. One page.
- This week: put it where the work happens (in the field service app, on a card in the truck, wherever the tech actually is).
- Two weeks from now: ask the team: did the checklist help, or get in the way? Revise based on what they say.
- Then: pick the next process. Same drill. You're never trying to do all ten at once.
Templates for each format. The Process Documentation Template includes checklist, decision tree, and reference card layouts. Pairs well with the 90-Day Rocks Tracker for prioritizing which to write next.
See the Operations tools →