Processes and SOPs: getting the work out of one person's head

How to get your processes written down, and what to get back at the end

The way your business runs usually lives in one or two heads

Ask who knows how a new client gets set up. Or how the invoices go out at the end of the month. The answer is usually a name, and often it's yours. That works while that person is around. When they're out sick, on vacation, buried in something else, or gone for good, the work stalls. Or it gets done twice. Then somebody texts you on your day off to ask where the login is. New people learn the job by sitting next to whoever has done it longest. Every one of them learns a slightly different version.

Most businesses grow this way. They do the work first and write it down never.

Written processes are the operating system your business runs on

A process document holds what someone else needs to do a job the way it's done now. That means the order, the decisions, and what finished looks like. Put enough of them together and you have the operating system of the business. Once it's written down, the people you already have can run the work without checking with you first. The quality holds when the job changes hands.

This matters even more for some owners. Maybe you can map out the whole thing in your head and still lose half of it by the end of the week. If that happens to you, writing it down stops the business depending on you remembering. The page holds it, so your head doesn't have to.

Work that repeats gets a process document, and one-time work gets a plan

Start looking for how to write this down and you'll meet three or four names for it. Process document, SOP, and work instructions all mean the same thing. Each is written instructions for a job your business does again and again. The US Environmental Protection Agency's guidance on SOPs defines them that way and says other names get used too. So don't spend long on the word. What matters is whether the job is written down at all.

One name does mean something else. A handover document is the record of what changed hands when outside work ends. What belongs in it is in the project handover checklist.

What makes something a process document is that the work repeats. Sending the monthly invoices repeats. Setting up a new client repeats. A rebrand doesn't, and neither does a move to a new system or a launch. Work like that happens once, so it needs a project plan, and Launches, Rebrands, and Migrations covers planning it. When it's over, it leaves new routine work behind. That routine work is what you write down as processes.

Document the process while the work is getting done

The usual plan is a documentation push later, once things calm down. Things don't calm down. By the time a quiet week arrives, the details are gone. So is the reason step four has to happen before step three.

The better time to write a process down is during the work. The person doing it writes it, while every step is still in front of them. Want processes someone else can follow from the page, without waiting for a quiet week? Start with our guide on how to document business processes while the work is getting done.

What a process document needs to say

You don't need a template to start. A useful document says what the process is for, who is responsible for it, and the steps in order. The guide covers what each process document needs part by part.

Each written process needs an owner to keep it current

Written processes go stale quietly. The work changes and nobody touches the page. The next new hire follows steps that stopped being true a while ago.

Each document needs a named person on your side whose job includes keeping it current. The rest is in how to keep a process document true. Getting your people to use the new way is its own job. Rolling Out New Systems covers it.

A big change can make many processes untrue at once

Say you're planning a rebrand, a move to a new system, or a migration. Or you've redesigned the business and a long list of changes follows. Changes like these alter many routine processes on the same day. Every page that described the old way is wrong from that morning on, and nobody had to touch it.

So the affected processes belong in the plan for the change itself. While the change is being planned, go through what's written and mark each process it will touch. Put those on the same list as everything else that has to change. Next to each one, write who updates it. Usually that's the person who already owns the document. This holds whoever runs the change: you, your people, or outside help.

When the change is a new system, those updated pages help keep people using it after it goes live. That side of it is in Rolling Out New Systems.

Skip the list, and you find out afterwards, when someone follows an old page and the work comes out wrong.

Anyone you bring in to help starts from what's written down

When someone takes over a piece of work, they start from whatever is on the page. That's true of a project manager or a contractor. It's just as true of one of your own people handed a project for the first time.

Where nothing is written, the briefing comes from you, from memory. You explain it on a call, then again in answers to the questions that follow. When the next person arrives, you explain it all over again. Each time, the parts you forget to mention are the parts that come back wrong. You can't know in advance which parts those will be. Nobody did anything wrong. Nobody can work from what they were never told.

Written processes move the starting point from your memory to the page. That's what lets the work be run by whoever runs it next.

When outside help finishes, the accounts and the know-how should be yours

The same thinking applies when a contractor, a freelancer, or an agency has been doing the work. When they finish, the accounts, the documents, and the know-how should all be in your hands.

How the work ends changes that list. The provider can finish it and hand it over, run it until your people are ready to take it in-house, or keep running it for good. For what to ask for, whichever way your work ends, use the project handover checklist.

Who runs the work is the next decision

Then there's the open question of who does the work: you, your people, or outside help. Outsourcing and Delegating helps you decide.

Your next day off could be the first one with no texts asking where the login is. When Sparkitive runs a project, we build its processes as we go, so the know-how stays in your business. We can finish it outright, run it until your team wants it back, or keep it going for good, and you don't have to pick one before we begin. Before any of that comes a free 30-minute discovery call with Christina, all about your business.

Book a discovery call