How to Build an SOP Your Team Will Actually Use
January 7, 2025 · Ritter & Co.
Most SOPs end up in a binder no one opens. Here's the format we use with contractors that actually gets followed in the field, even by new hires on day one.
A standard operating procedure isn't a wall of text. It's a job aid. If your tech has to read more than thirty seconds of instructions before they can act, the SOP has already failed.
Start with the trigger. Every SOP should answer one question first: when does this process start? "When a customer calls to schedule." Or "When a job is marked complete in the CRM." Without a clear trigger, people don't know when to follow it.
Then list the steps as verbs, not paragraphs. Number them. Keep each one to a single action. "Confirm appointment by text" beats "Once the appointment has been entered into the calendar, the office should reach out to the customer in order to confirm…"
Add a definition of done. What does the finished state look like? A photo uploaded? A field marked complete? A customer signature captured? If you can't describe the finished state in one sentence, the step isn't tight enough.
Include the exit handoff. Who picks the work up next, and how do they know? Most processes break at the handoff, not the work itself.
Finally, version it and date it. SOPs are living documents. Put a revision date at the top so the team knows they're looking at the current version and not last year's.
Build the first three SOPs for the processes that go wrong most often, usually scheduling, invoicing, and job close-out. Roll them out one at a time, train on each, and only move to the next once the previous one is sticking.