The name puts people off, which is unfortunate because it implies a formal document with version control and approvals. What is actually required is a numbered list in a shared folder that somebody else could follow. Anything more elaborate becomes a reason not to write the next one, and a folder of plain lists that exist beats a template nobody filled in.

Write it while performing the task rather than from memory, which is the single instruction that determines whether it works. The remembered version has been smoothed: you skip the step where you check something, the moment where you choose between two options, and the workaround you have used so long it no longer registers. Those omissions are exactly what stops somebody else.

Watch for the point where the honest instruction becomes that it depends, because that is the actual value of the exercise. It depends on what, specifically? What would you look at? Answering that converts an unconscious judgement into a rule somebody else can apply, and it is the difference between a process that runs without you and one that generates a phone call.

Include the context that is obvious to you, since obviousness is a symptom of expertise rather than a reason to omit something. Where the file lives, which account to use, what the thing is called internally, and who to contact. Somebody following the document lacks your context, and missing context is what stops them rather than missing steps.

Start with frequency rather than importance. The task performed weekly returns considerably more from being documented than the quarterly one that feels weightier, because the return compounds. After that, anything only you can do, then anything with a consequence if performed wrong, which is the category people avoid attempting without instructions.

Test each one by having somebody follow it without asking you questions. Every question they need to ask is a gap, and the document is not finished until the task can be completed from it alone. This takes one attempt and it is the step that separates documentation that works from documentation that exists.

Store them where the work happens rather than in a separate system, because a procedure nobody can find while performing the task is a procedure nobody uses. A shared folder alongside the working files, linked from wherever the task begins, is sufficient.

Keep them current by attaching updates to the moment things change rather than to a review schedule. When you alter how something is done, edit the document in the same sitting. A folder describing how the business worked eighteen months ago is worse than nothing, because somebody will follow it.

The benefit that arrives first is not delegation. Writing down how you work reliably reveals steps that exist for no current reason, decisions nobody remembers making, and duplicated effort between two processes. Most businesses that document a handful of tasks end up simplifying several of them before anybody has been handed anything.

Record a screen capture alongside the written version for anything visual, since watching somebody perform a task in software conveys in two minutes what a page of instructions conveys badly. Keep the written version as the reference and the recording as the demonstration, because a recording alone cannot be searched or corrected when one step changes.

Number them and keep an index, because a folder of two dozen documents with descriptive names becomes difficult to navigate exactly when somebody needs it under pressure.