How to Write a Procedure Someone Else Can Actually Follow

If you are the only person who knows how a recurring task gets done, that task will keep coming back to you. Not because nobody else is capable of it, but because the steps live in your head. Writing the procedure down moves it out of your head and into a document someone else can run without asking you questions at every step.

A procedure is not a manual. It is one task, written so a capable newcomer can do it once, correctly, without you in the room. Keep it short. If it runs past two pages, it will not get read.

1. Pick one task, not your whole business

Start with a task that interrupts you often. Invoicing at the end of the month. Onboarding a new client. Preparing a weekly report. Pick one.

Write the task name at the top, then one sentence for its purpose: what "done right" looks like. For example: "Invoice every finished job once, correctly, and on time, so no month ends with unbilled work."

If you cannot write that sentence, you do not yet know the task well enough to document it. That is useful information. Talk through the task once, out loud, before you write anything.

2. Map the task in 15 minutes

Before writing sentences, map the task in four parts:

• Trigger: what starts it? A date, a client message, a job marked complete.
• Inputs: what do you need before you start? Access, a list, an agreed amount.
• Steps: what happens, in order, one action per step?
• Output check: how do you know the result is right?

Do this on paper or in a blank document. Fifteen minutes is enough for one task. If it takes longer, the task is probably two tasks. Split it and map the first half.

3. Write steps as actions, not descriptions

Each step starts with a verb: list, check, create, send, record. Not "invoicing happens at month end." Instead: "List the month's completed jobs. Exclude anything still open."

A step that describes a situation instead of telling the reader what to do is a step the reader will have to guess at. Guessing is where errors come from.

Under each step, add only the detail a newcomer needs: where to find the list, what to compare, what to do when the numbers do not match. Leave out background, history, and explanations of why the business works this way. The reader needs to finish the task, not understand your company.

4. Add the three sections people skip

Most procedures fail in the same three places, and all three are easy to add:

Quality check. Two or three checks at the end: every completed job has exactly one invoice, each amount matches the quote or a written revised agreement, no open job invoiced early. The check catches the error before the client sees it.

Exceptions. Write down when not to follow the procedure, and who decides. If a client disputes the delivered work, do not invoice until the dispute is resolved. If the invoicing tool is down on the last working day, send a plain payment request the same day and create the formal invoice within two working days. Exceptions written in advance stop panicked improvisation.

Owner and review date. Every procedure needs a named owner and a review interval. Ninety days works for most tasks. Without an owner, nobody updates the document when the process changes, and within a year it describes a job that no longer exists.

5. Test it by handing it to someone

A procedure is finished only when someone else has followed it without you. Give the draft to the person who will actually do the task. Ask them to follow it exactly, and to write down every place they had to stop and ask a question.

Every question is a gap in the document. Fill the gap, not by adding a paragraph of explanation, but by fixing the step that caused the question. Then hand it back and test again. One test round usually finds the gaps that matter: a missing login, a list nobody told the reader about, a step in the wrong order.

When you hand a task over, also state two things plainly: what counts as done, and what the person should not decide alone. "Done" means the invoices are sent and each job is marked invoiced with its invoice number and date. A disputed amount is not decided alone; it goes to the owner. Clear boundaries are what make delegation safe for both sides.

6. Review it every quarter

Processes change: tools change, clients change, rates change. A quarterly review takes ten minutes. Read the procedure, check each step against how the task is actually done now, and update what drifted. Log the date and the change at the bottom, so the next reader can see the document is current.

A procedure with a review date from two years ago will be ignored, and rightly so. Nobody should trust a document its own owner stopped maintaining.

The short version

One task per document, under two pages. Trigger, inputs, steps that start with verbs, a quality check, written exceptions, a named owner, and a review date. Test it by having someone else follow it, fix the gaps they find, and review it every quarter.

That is the whole system. It does not require special software. A plain document works, and the document you maintain beats the polished manual nobody opens.

---

I put this method into a kit I sell — the SOP Builder Kit ($19 one-time): an SOP master template, a 15-minute process-mapping worksheet, a delegation handoff template, a quarterly audit checklist, and a filled sample procedure: https://www.getly.store/product/sop-builder-kit-document-delegate-scale

Disclosure: I made it. Use it or build your own document from the sections above — the system matters more than the tool.

— Daniel Reed