Start by listing what you did last week rather than trying to recall what you generally do, because the general version omits the awkward parts. The tasks that appear repeatedly, take more than ten minutes, and follow roughly the same steps each time are the candidates. That is usually a shorter list than expected and it is almost always administrative rather than the work customers pay for.
Write it while performing the task rather than from memory. This is the single most important instruction, because the remembered version has been smoothed. You skip the step where you check something, the moment where you decide between two options, and the small workaround you have used so long it no longer registers. Those are exactly the parts that cause somebody else to stop and ask.
Watch for the point where the honest instruction becomes that it depends. That moment is the actual value of the exercise. It depends on what, specifically? What would you look at? What would make you choose differently? Answering that converts an unconscious judgement into a rule somebody else can apply, and it is the difference between a process that works when you are not there and one that generates a phone call.
Keep the format plain. A numbered list in a shared document is sufficient, and anything more elaborate becomes a reason not to write the next one. What matters is that it exists, is findable, and is current, not that it is well designed.
Include the things that are obvious to you, because 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 does not have your context, and missing context is what stops them rather than missing steps.
The order to work through is frequency first, then anything only you can do, then anything with a consequence if done wrong. That third category matters because it includes the tasks nobody wants to attempt without instructions, and their absence is why those tasks never get handed over.
Test each one by having somebody else follow it without asking you questions. Every question they need to ask is a gap, and the document is not finished until they can complete the task from it alone. This takes one attempt per document and it is the step that separates documentation that works from documentation that exists.
Then keep them current, which is the part that usually fails. Attach the update 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 of procedures describing how the business worked eighteen months ago is worse than none, because somebody will follow it.
The wider benefit is worth naming. 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, which is a return that arrives before anybody has been handed anything.
Store them where the work happens rather than in a separate documentation system. A procedure nobody can find while performing the task is a procedure nobody uses, and the friction of opening a different tool is enough to prevent it. A shared folder alongside the working files, linked from wherever the task begins, is sufficient and considerably more likely to be consulted.