How to write a process document someone else can actually follow

Most process documents fail the same way. They read fine to the person who wrote them, and useless to everyone else. That is because they are written from memory of doing the task, not for a reader who has never seen it done. The result is a document that looks complete but quietly assumes a dozen things the reader does not know.

The classic failure: steps that only make sense if you already know them

“Process the request” or “handle it appropriately” are not steps, they are labels for a step. A new hire reading them still does not know what to open, what to check, or what to decide. A real step names the concrete action: which screen to look at, what to compare it against, what to click, who to tell, and what counts as done. If a step in your draft could be replaced with “do the thing” and lose no meaning, it needs to be rewritten.

The test that catches this: would someone new actually be able to follow this with nobody in the room to explain it? Not “would it remind someone who already knows the process what to do”, but could a genuine stranger execute it cold. Hand the document to a new hire, or imagine handing it to one, and check whether each step gives them enough to act without guessing or asking you.

Why the “obvious” steps are the ones that go missing

The steps you are most likely to leave out are not the hard ones, they are the automatic ones. After doing a task hundreds of times, checking the account balance or glancing at the delivery date stops feeling like a step at all, it just feels like part of looking at the request. That is exactly why it needs writing down: the person reading your SOP has not built that automatic habit yet, and skipping it is precisely the kind of gap that leaves them stuck or guessing. When you draft a process, treat any step you are tempted to skip as “too obvious to mention” as a signal to write it down, not leave it out.

Folding in exceptions without building a flowchart

Real processes have edge cases: the client who already has an account, the order that arrived damaged, the request that comes in after hours. The temptation is to branch the document into if/then paths, but that turns a simple numbered list into something nobody wants to read. The fix is to attach the exception to the step it affects, as a short trailing note: “confirm the delivery address, unless it is a reorder, in which case use the address on file.” The list stays a straight sequence, and the exception sits exactly where someone would need it, right when they reach that step.

Example

Overview: This process covers how to handle a customer refund request for a standard order. Use it whenever a customer asks for money back within 30 days of purchase. It is for anyone on the support team, not just the person who normally handles refunds. 1. Check the order date against today's date. If it is more than 30 days old, the standard refund window has passed; escalate to a manager instead of proceeding. 2. Confirm what was ordered and whether it has already been delivered or downloaded. 3. Check whether the order qualifies for a full or partial refund based on its condition, unless the customer reports a fault, in which case a full refund applies regardless of usage. 4. Reply to the customer confirming the refund amount and how long it will take to appear. 5. Log the refund in the shared tracker so finance has a record of it.

Common mistakes

Vague steps like “handle appropriately” that describe an outcome instead of an action.
Leaving out steps that feel too obvious to the person who already knows the process, which are often exactly the ones a newcomer needs.
Burying an important exception in a wall of text instead of noting it against the step it actually affects.
Skipping the overview, so a reader has no way to tell what the process is for or when to use it before they are three steps in.