How to Document a Process So Someone Else Can Actually Run It

Most small businesses have a process document somewhere: a folder in Google Drive, a half-finished Word file, a Post-it note in someone's top drawer. Almost none of them get followed, because they were written by someone who already knew how to do the job, for an audience who doesn't. Here's how to write one that a new hire, an overseas team member, or on a stressed Tuesday-you can pick up and run with, without asking a single question.

Write it while you're doing it, not from memory

Write the steps as you go, not after, when everything looks obvious in hindsight. Open the software, work through the real screens, copy the exact field names as they appear. If you write from memory a week later, you'll skip the three fiddly bits that trip everyone up, because your brain has already smoothed them over.

Write for someone who's never seen it before

Skip nothing that feels obvious to you. "Log in and check the queue" means nothing to someone who doesn't know which login, what queue, or what "checking" involves. Name the exact screen, the exact button, the exact folder. If you wouldn't hand this to a stranger and expect them to get it right first go, it isn't finished yet.

Write down the exceptions, not just the smooth run

Every process breaks somewhere: the client who never replies, the invoice missing a reference number, the system that times out. If your document only covers the tidy version, whoever follows it will hit the first exception and come straight back to you, which defeats the whole point. Add a short "if this happens" line under each step where you already know things go sideways.

Test it on someone who's never done the job

Hand the document to someone with zero background in the task and watch them follow it without help. Every place they hesitate, guess, or ask a question is a gap in the document, not a gap in them. Fix it, then test again. A process that only makes sense to the person who wrote it isn't a process. It's a memory with extra steps.

Put it where the work actually happens

A brilliant document buried three folders deep in a shared drive might as well not exist. Link it from wherever the task starts, a project tool, a shared inbox, a note pinned to the top of the right channel. If someone has to go looking for the instructions, they'll skip them and wing it instead.

Documenting a process isn't paperwork. It's the difference between a business that runs when you're not in the room and one that doesn't. Start with the one task you get asked about most, the one you'd hand off tomorrow if you could. Write it while you do it, test it on someone who's never touched it, and fix whatever trips them up. If you'd like support putting this into practice, visit simkul.au.