Here's a question to answer before you document business processes. Can you list the processes that keep your business going, and name every person involved in each, from the first step to the last?
Name them as people, with what each one does, in order.
If the answer gets vague somewhere in the middle, that part of the process lives in someone's head. Often it's yours.
It can come out while the work is happening, written down by the people doing it. Nobody has to find a free afternoon.
Your processes already run the business, written down or not
Every business already has processes. New work gets quoted somehow. Customer questions get answered somehow. Writing a process down doesn't create it. It moves it out of one person's memory and onto a page other people can use.
That's why I think of processes as the operating system of a business. It runs underneath everything, whether anyone has written it down or not. Written down, it can run without you in the room.
The practical payoff is that you can hand work to someone else and the quality holds. The work stays consistent when the person doing it changes, for a week of vacation or for good. And the page becomes the training. A new hire has something to learn from besides the memory of whoever did the job last.
The longer case for writing processes down is in the Processes and SOPs overview.
Write each process down during the work, while the details are in front of you
"I'll write it all up once things slow down." It's a reasonable plan. It rarely happens, and when it does, the details have gone.
What's left after the fact is the summary version. You remember the five big steps. You lose the small ones that make them work. Which field gets filled in first. Who needs a heads-up before the client hears anything. The check you always do and never think about. Those details are only in front of you while the task is open.
So the document gets written during the work, by whoever is doing it. They know it best because they did it this morning. When a process passes through several people, ask them to write it as a group. Each person knows their own stretch, and writing it together puts the handovers between them on the page too. It also decides whether anyone uses it. A page people built together is theirs. A page handed to them is someone else's idea.
I'm autistic and ADHD, diagnosed in my late 30s. In my own businesses, I write each process down while I'm doing the work, not afterward from memory. Maybe you can see the whole process at once, and the separate steps slip away once you're done. Either way, the middle of the task is when you have all of them. That's the time to write.
Start with the processes that stall when one person is out
Which process should you write down first? Not all of them at once.
Make a list of the processes your business actually runs on, the ones that would hurt if they stopped. Rank them by how much they matter, and start at the top.
If ranking is hard, ask a narrower question. What grinds to a halt, or gets redone, when one particular person takes a day off? Those processes depend on a single head. That makes them the most at risk, and the most worth writing first.
For each process on the list, name what it produces. The main output might be a signed proposal, a paid invoice, or a client who can log in. Knowing the output tells you where the process ends. Then the document has a last step, and you know when the job is finished.
How to capture a process as you work
Take the top process on your list and wait for the next time it actually runs. Then work through these four steps.
- The person doing it writes the steps as they go. Short steps, in order, in plain words. Start each one with the action: send, check, add, approve. Where words aren't enough, take a screenshot or record the screen. A rough draft is fine. It only has to be right.
- Write for someone who knows the basics but has never done this job. They should be able to follow it alone, without stopping to ask anyone. If a step needs a particular skill or some training, say so.
- Have someone else try it from the page. This is the step that finds the gaps. The person who wrote it can't see them, because they fill each one in without noticing. Whatever the tester gets stuck on goes back into the document. Then it's done.
- Keep it where the work happens. If the people doing the job can't find the document while they're doing it, they'll work from memory. Then you're back where you started.
What each process document needs, and what can wait
The US Environmental Protection Agency publishes guidance on preparing standard operating procedures. Most of it is written for labs. Its section on administrative procedures, the kind an office runs, comes down to eight things:
- What it's for. Why this process exists.
- When it applies. The situations where someone should follow it.
- A one-line summary, so a reader can tell at a glance whether this is the document they need.
- Any words a newcomer won't know, like internal names and abbreviations.
- Who is responsible for it, and any skill or training the job needs.
- The steps, in order.
- What done right looks like: the checklist or standard the work gets checked against.
- Where to find the forms and records it uses.
To the first of those, I'd add a question of my own: what would go wrong without this process?
A checklist is part of the document, not a replacement for it. A checklist reminds someone who already knows the job. The steps teach someone who doesn't.
What can wait is any detail a process doesn't need yet. The guidance is clear that there isn't one correct format, and the right amount of detail depends on the process. It gives four examples of what can decide it: how critical the process is, how often it runs, how many people use it, and whether anyone is around to train them. A process five people run every day, with someone nearby to ask, can be a short page. One that runs twice a year, when nobody remembers how it went last time, needs every step spelled out.
A process document is only useful while it's true
A process document starts going out of date the first time someone does the job differently and doesn't tell the page.
That moment is the trigger for an update. Whoever changes how the job is done updates the document that day, or tells the person who owns it. A review on the calendar catches what slipped through, but it can't be the only thing keeping the page honest.
Give each document one owner. That's a named person who answers for whether it's still right. When a document belongs to everyone, nobody checks it.
Every so often, the owner reads it through and asks two questions. Does anyone still do it this way? Do we still need it? If nobody does that work anymore, take the document out of the place people look. A page describing a dead process isn't harmless. Someone new will follow it.
Writing a process down and getting people to use it are two different jobs. For the second one, read how to introduce a new system to your team.
When the work is a whole project, document it as part of the project
Say outside help is running a big body of work for you. That's where documenting is easiest to skip, because everyone is busy finishing. The same rule applies: the documents should be written during the work, so whoever runs it next can pick it up. The project handover checklist covers what you should get back when that help finishes. On a Sparkitive project, your plan says what we hand back to you.
With Sparkitive, we finish the work, run it until you take it in-house, or keep it running for good, and you can decide up front or along the way. Whichever it is, the documentation is yours.
Start with the one process that stalls when one person is out, and write that one down first. If a whole body of work is waiting behind it, bring it to a free 30-minute discovery call with me.
Just need a website or blog content, and nothing else? FableForge and its Tech Team handle that.
