Most advice on this topic is about templates and formatting. Neither is why documentation fails. It fails because the wrong things got documented, the steps were too vague to act on, or it went stale and nobody noticed.
These are the practices that actually change the outcome.
Document by cost of loss, not by complexity
The instinct is to start with the most complicated process. The better rank is what happens if nobody knows how to do this. That ordering usually puts something mundane at the top: a payroll deadline, a renewal date, a recovery procedure for something that rarely breaks.
Rare plus undocumented is the worst combination, because nobody discovers the gap until they are already in the incident.
Be specific enough to act on
The most common defect is a step that is clear to its author and ambiguous to everyone else. Three rules fix most of it: start each step with the role that performs it, keep it to one action, and name the actual tool and the actual place.
"Log the request" fails all three. "Support Lead creates a ticket in the Zendesk Onboarding view" passes.
Document the exceptions, not just the happy path
Real processes fork, and a linear list that assumes everything goes well stops being useful at exactly the point someone needed help. Every place where the answer changes what happens next needs the question and both consequences.
Attach exceptions to the step they affect rather than collecting them at the bottom. Nobody reads a notes section while executing step three.
Write down the prohibitions
If your team knows never to do something, write it down. Documenting only the correct action assumes the reader will not think of the wrong one, and the wrong one is often the more obvious move. This is one of the highest-value additions to any procedure and one of the most commonly skipped, because whoever is writing stopped considering the wrong option years ago.
Let the newest person write it
Someone who just learned a task writes better instructions for it than the expert, because they still remember what was confusing. The expert has forgotten which parts are non-obvious, which is why expert-written documentation skips exactly the steps beginners get stuck on.
The pattern: the experienced person demonstrates, the newer person writes it up, the experienced person corrects the factual errors. Accuracy from one, clarity from the other.
Give every document a review date and an owner
Documentation that is quietly wrong is worse than none, because people follow it. A review cadence turns going stale into a visible event instead of something discovered by someone confidently doing the wrong thing.
Quarterly for anything touching a system that changes often, annually for stable procedures. And record "reviewed, no change required" with a date and a name, because a blank review field reads as a document nobody has looked at in three years.
Track what people looked for and did not find
The best signal for what to document next is not a planning exercise, it is a search log. A search that returns nothing is direct evidence that a procedure people need does not exist, and it is much cheaper to collect than to guess.
Reduce the cost of writing, or none of this happens
Every practice above assumes the documentation gets written. The reason it usually does not is that writing is slow and the person who knows the process is the busiest on the team.
So attack that directly: work from a finished template for anything standard, and for anything specific to you, click through the process once or explain it out loud and have the first draft produced from that. Correcting a draft is faster than facing a blank page, which is the difference between documentation that exists and documentation that is permanently next week's job.