Tag: how to write standard operating procedures service business

You cannot delegate a process that only exists in your head. Everything else about growing is downstream of that.

TL;DR Record yourself doing it rather than writing it from memory. One page per process. Written for the person who has never done it. Store where the work happens, not in a folder nobody opens.

Record first, write second

Writing an SOP from memory produces a document that skips the steps you no longer notice you take.

The better method

1. Screen record or film yourself doing the task once, narrating as you go.
2. Get it transcribed.
3. Edit the transcript into steps.
4. Have somebody else follow it and note every point where they had to ask a question.
5. Fix those points. That is the actual SOP.

Step four is where the value is. The gaps are invisible to the person who wrote it and obvious to the person following it.

Which processes first

Not everything needs an SOP. Prioritise ruthlessly.

Priority	Type	Why
1	Done often, by several people	Highest total impact
2	High cost when done wrong	Compliance, safety, invoicing
3	Only you know how	Single points of failure
4	New hires need it week one	Onboarding bottleneck
Last	Rare and low stakes	Rarely worth documenting

Start with the five things that happen every single day. Booking a job, arriving on site, handling payment, closing a job, handling a call-out.

The format

One page. Every time.

Process: Closing out a completed job
Owner: Field technician
When: Before leaving site
Time: 10 minutes

Steps
1. Walk the customer through what was done. Point at it.
2. Take the after photos, same angles as the before set.
3. Complete the job record in the app: parts used, time on site, anything noted for next visit.
4. Hand over the care sheet and explain the first-48-hours section.
5. Ask the pencil-it question for the next service.
6. Mark the job complete. This triggers the invoice and the feedback request.

If something is not right: do not promise a fix on the spot. Say you will confirm by end of day and flag it to the office before you leave the street.

Common mistakes: forgetting the after photos, marking complete before the record is filled in.

The “common mistakes” section is the most valuable part and the one everybody omits.

Write for the person who has never done it

Assume no context.

• Name the actual buttons and screens, not the concept. “Tap Jobs, then the job, then Complete” not “close the job in the system”.
• Say where things are. Physical location, folder path, drawer.
• Include the decision points. “If X, do this. If Y, do that.”
• Say who to ask when the SOP does not cover it.

Avoid “as appropriate”, “use judgement”, “as normal”. These are the phrases that mean the writer could not be bothered to specify, and they are exactly where new people fail.

Process mapping before writing

For anything with branches, sketch it before you write it.

Simple mapping

• Boxes for actions.
• Diamonds for decisions.
• Arrows for sequence.
• Mark handoffs between people, because handoffs are where things get dropped.

Do this on paper. Software mapping tools slow this down and the map is a working tool, not a deliverable.

What mapping reveals, reliably: steps that exist for no reason, handoffs with no confirmation, and approvals nobody actually performs.

Where to store them

The location determines whether they get used.

Good

• Linked directly from the job in your field app.
• A QR code in the van or on the equipment.
• A pinned channel in whatever your team already uses to communicate.
• Printed and laminated, for physical processes.

Bad

• A shared drive folder nobody has opened since induction.
• A wiki with a search that does not work.
• Anything requiring a separate login.

The rule: the SOP must be reachable from where the work happens, in under ten seconds.

Keeping them current

An out-of-date SOP is worse than none, because it teaches the wrong thing with authority.

• Date every document and show the date prominently.
• Name an owner per SOP.
• Review annually, or whenever the process changes.
• Make correction easy. Anyone who follows an SOP and finds it wrong should be able to flag it in one message, and be thanked for it.
• Version the video too, if the interface changed.

Delegation and accountability

An SOP without an owner is a suggestion.

For each process, be explicit about

• Who does it. By role.
• Who checks it, if anyone.
• What the standard is, measurably.
• What happens when it is not met. Retraining first, always.

Delegating properly

1. Show them.
2. Do it together.
3. They do it, you watch.
4. They do it, you check the output.
5. They do it, you check the metric.

Most delegation failures are jumping from step one to step five.

Measure it

• Time to competence for a new hire, before and after.
• Repeat questions. The same question asked twice is a missing SOP.
• Error rate on documented versus undocumented processes.
• Hours you personally spend on work that has an SOP. If it is not falling, the SOPs are not being used.

Record yourself doing your most repeated daily task tomorrow, narrating as you go. That recording is the raw material for your first SOP, and it takes no extra time because you were doing the task anyway.

Need a pro to build them? [BOOK A CALL]